Keycloak Identity Brokering — 소셜 로그인부터 외부 IdP 연동까지

들어가며
Identity Brokering 아키텍처
소셜 로그인 설정 — Google, GitHub, Apple
외부 SAML / OIDC IdP 브로커링
Account Linking 전략 — 이메일 중복 처리
Attribute와 Claim 매핑
브로커 토큰 저장과 Stored Tokens API
Keycloak 26의 Identity Brokering API v2 (Preview)
기업 시나리오 — 고객사 IdP 연동 B2B SSO
커스텀 First Broker Login Flow
트러블슈팅
운영 베스트 프랙티스
마치며
참고 자료

들어가며

"우리 서비스에 구글 로그인을 붙여 주세요"라는 요구와 "고객사 Azure AD로 SSO 해 주세요"라는 요구는 전혀 다른 일처럼 보이지만, Keycloak에서는 둘 다 Identity Brokering이라는 하나의 메커니즘으로 해결됩니다. Keycloak이 애플리케이션에게는 IdP 역할을 하면서, 동시에 외부 IdP에게는 클라이언트(SP/RP)가 되어 인증을 중개하는 구조입니다.

2026년의 인증 환경은 이 기능의 가치를 더 키우고 있습니다. passkey가 기본값이 되어 가는 흐름 속에서도 B2B SaaS의 표준 요구사항은 여전히 "고객사 IdP 연동"이고, Keycloak 26 계열은 조직(Organizations) 기능과 Identity Brokering 개선을 거듭하며 이 시나리오를 1급 시민으로 다루고 있습니다. 특히 26.x에서 preview로 등장한 Identity Brokering API v2는 오랫동안 커스텀 SPI로 우회하던 브로커 확장 지점을 표준화하는 변화입니다.

이 글에서는 brokering 아키텍처와 first login flow의 동작 원리, 소셜 3사(Google/GitHub/Apple) 설정, 외부 SAML/OIDC IdP 연동, account linking 전략, 토큰 저장, B2B 시나리오, 트러블슈팅을 순서대로 다룹니다.

Identity Brokering 아키텍처

전체 흐름을 먼저 그림으로 보겠습니다.

+-----------+        +---------------------------+        +-------------+
|  Browser  |        |   Keycloak (Broker)       |        | External IdP|
|           |        |   realm: myrealm          |        | Google/SAML |
+-----+-----+        +------------+--------------+        +------+------+
      |  1. app 접근, 로그인 필요  |                              |
      |--------------------------->|                              |
      |  2. 로그인 페이지           |                              |
      |     (IdP 버튼 목록 표시)    |                              |
      |<---------------------------|                              |
      |  3. "Sign in with Google"  |                              |
      |--------------------------->|                              |
      |  4. AuthN request로 리다이렉트 (OIDC/SAML)                 |
      |------------------------------------------------------------>
      |  5. 외부 IdP에서 인증 완료                                  |
      <------------------------------------------------------------|
      |  6. callback (code/assertion) 전달                          |
      |--------------------------->|                              |
      |                            | 7. 토큰 교환, 외부 identity   |
      |                            |    검증 및 사용자 매핑        |
      |                            | 8. First Login Flow 실행     |
      |  9. myrealm의 토큰 발급     |    (신규/기존 사용자 처리)    |
      |<---------------------------|                              |

핵심 개념을 정리하면 이렇습니다.

외부 IdP에서 인증된 신원은 Keycloak 내부에서 federated identity로 표현되며, realm의 로컬 사용자와 연결(link)됩니다.
처음 보는 federated identity가 들어오면 First Broker Login Flow가 실행되어 로컬 사용자 생성 또는 기존 계정과의 연결을 결정합니다.
애플리케이션은 외부 IdP의 존재를 전혀 모릅니다. 항상 Keycloak이 발급한 토큰만 받습니다. IdP를 늘리거나 바꿔도 앱 코드는 무변경이라는 것이 brokering의 최대 장점입니다.

소셜 로그인 설정 — Google, GitHub, Apple

세 공급자 모두 어드민 콘솔의 Identity Providers 메뉴에서 추가하지만, 코드형 관리를 위해 kcadm 기준으로 정리합니다. 공통 준비물은 각 개발자 콘솔에서 발급받는 client id와 secret, 그리고 Keycloak의 redirect URI입니다. redirect URI는 항상 다음 형식입니다.

https://kc.example.com/realms/myrealm/broker/IDP-ALIAS/endpoint

Google

Google Cloud Console에서 OAuth client를 만들고 위 redirect URI를 등록한 뒤 생성합니다.

kcadm.sh create identity-provider/instances -r myrealm \
  -s alias=google \
  -s providerId=google \
  -s enabled=true \
  -s 'config.clientId=GOOGLE_CLIENT_ID' \
  -s 'config.clientSecret=GOOGLE_CLIENT_SECRET' \
  -s 'config.defaultScope=openid profile email' \
  -s 'config.hostedDomain=example.com'

hostedDomain은 Google Workspace 조직 도메인으로 로그인 가능 계정을 제한하는 옵션입니다. 사내 서비스라면 반드시 설정해야 합니다. 다만 이 값은 클라이언트 측 힌트이기도 하므로, Keycloak이 ID token의 hd 클레임을 검증하도록 Validate hosted domain까지 켜는 것이 안전합니다.

GitHub

GitHub은 OIDC가 아닌 순수 OAuth2 공급자라서 ID token이 없고, Keycloak이 user API를 호출해 프로필을 가져옵니다.

kcadm.sh create identity-provider/instances -r myrealm \
  -s alias=github \
  -s providerId=github \
  -s enabled=true \
  -s 'config.clientId=GITHUB_CLIENT_ID' \
  -s 'config.clientSecret=GITHUB_CLIENT_SECRET' \
  -s 'config.defaultScope=read:user user:email'

주의할 점은 이메일 비공개 설정 사용자입니다. scope에 user:email이 없으면 이메일이 null로 들어와 first login flow가 이메일 입력 화면에서 멈춥니다. 또 GitHub 이메일은 검증 여부 정보가 함께 오므로, 검증되지 않은 이메일로 account linking을 허용하면 계정 탈취 벡터가 됩니다. 뒤의 linking 절에서 자세히 다룹니다.

Apple

Sign in with Apple은 셋 중 가장 까다롭습니다. 고정 client secret 대신 p8 개인키로 서명한 JWT를 client secret으로 사용하며, 유효기간이 최대 6개월이라 주기적 갱신이 필요합니다.

kcadm.sh create identity-provider/instances -r myrealm \
  -s alias=apple \
  -s providerId=apple \
  -s enabled=true \
  -s 'config.clientId=com.example.service' \
  -s 'config.teamId=APPLE_TEAM_ID' \
  -s 'config.keyId=APPLE_KEY_ID' \
  -s 'config.p8Content=P8_PRIVATE_KEY_CONTENT'

Apple 특유의 함정 두 가지입니다. 첫째, 사용자 이름과 이메일은 최초 인가 시 한 번만 전달됩니다. first login flow가 실패해 재시도하면 이름이 영영 비어 있게 되므로, Apple 개발자 콘솔에서 앱의 Sign in with Apple 사용 권한을 초기화하고 다시 테스트해야 합니다. 둘째, 사용자가 이메일 가리기(Hide My Email)를 선택하면 privaterelay.appleid.com 도메인의 릴레이 주소가 들어옵니다. 이메일 기반 account linking이 의미를 잃는 경우이므로 정책적으로 고려해야 합니다.

외부 SAML / OIDC IdP 브로커링

기업 고객의 IdP를 연동하는 경우입니다. OIDC IdP는 discovery URL만 있으면 가장 간단합니다.

# OIDC IdP (예: 고객사 Entra ID)
kcadm.sh create identity-provider/instances -r myrealm \
  -s alias=customer-a-oidc \
  -s providerId=oidc \
  -s enabled=true \
  -s 'config.useJwksUrl=true' \
  -s 'config.issuer=https://login.microsoftonline.com/TENANT_ID/v2.0' \
  -s 'config.authorizationUrl=https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/authorize' \
  -s 'config.tokenUrl=https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token' \
  -s 'config.clientId=ENTRA_APP_ID' \
  -s 'config.clientSecret=ENTRA_SECRET' \
  -s 'config.defaultScope=openid profile email' \
  -s 'config.validateSignature=true'

SAML IdP는 메타데이터 XML을 임포트하는 것이 정석입니다. 수동 설정 시 핵심 항목은 다음과 같습니다.

kcadm.sh create identity-provider/instances -r myrealm \
  -s alias=customer-b-saml \
  -s providerId=saml \
  -s enabled=true \
  -s 'config.entityId=https://kc.example.com/realms/myrealm' \
  -s 'config.singleSignOnServiceUrl=https://idp.customer-b.com/sso/saml' \
  -s 'config.nameIDPolicyFormat=urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress' \
  -s 'config.validateSignature=true' \
  -s 'config.wantAssertionsSigned=true' \
  -s 'config.signatureAlgorithm=RSA_SHA256' \
  -s 'config.postBindingResponse=true'

SAML 연동에서 보안상 타협 불가 항목은 validateSignature와 wantAssertionsSigned입니다. 서명 검증 없는 SAML은 assertion 위조에 무방비입니다. 인증서 만료도 단골 장애 원인이므로, IdP 인증서의 만료일을 모니터링 대상에 넣어야 합니다.

Account Linking 전략 — 이메일 중복 처리

brokering 운영에서 가장 정책 결정이 어려운 지점입니다. 기본 First Broker Login Flow는 다음 순서로 동작합니다.

federated identity 최초 유입
        |
        v
+-------------------------------+
| Review Profile (기본: 항상)    |  사용자가 프로필 확인/수정
+-------------------------------+
        |
        v
+-------------------------------+
| Create User If Unique         |  이메일/username 중복 없으면
+-------------------------------+  로컬 사용자 신규 생성
        | (중복 발견 시)
        v
+-------------------------------+
| Handle Existing Account       |
|  - Confirm link existing      |  "기존 계정과 연결할까요?"
|  - Verify via email           |  이메일 검증 링크 발송
|  - 또는 re-authenticate       |  기존 비밀번호로 재인증
+-------------------------------+

정책 선택지는 크게 셋입니다.

전략	동작	적합한 경우
자동 연결	이메일 일치 시 무조건 link	사내 전용, IdP가 모두 신뢰 가능
검증 후 연결	이메일 인증 또는 재인증 후 link	일반 B2C 기본값
연결 금지	중복 시 오류, 수동 처리	규제 산업, 고보안

여기서 절대 잊으면 안 되는 보안 원칙이 있습니다. 검증되지 않은 이메일을 근거로 자동 linking을 하면 안 됩니다. 공격자가 피해자의 이메일로 가입한 외부 IdP 계정(이메일 검증을 강제하지 않는 IdP)을 만들어 로그인하면, 피해자의 기존 계정에 연결되어 계정을 탈취할 수 있습니다. Trust Email 옵션은 해당 IdP가 이메일 검증을 보장한다고 확신할 때만 켜야 합니다.

기존 사용자가 설정 화면에서 스스로 소셜 계정을 연결하는 시나리오는 first login flow가 아니라 Account Console의 Linked Accounts 기능 또는 AIA(Application Initiated Action)와 유사한 idp_link 흐름으로 처리합니다. 애플리케이션에서 직접 연결 URL을 만들 때는 client-initiated account linking 스펙에 따라 nonce, hash를 포함한 URL을 구성합니다.

Attribute와 Claim 매핑

외부 IdP가 보낸 클레임·attribute를 로컬 사용자에 반영하는 것은 Identity Provider Mappers의 역할입니다. 첫 글에서 다룬 Protocol Mapper가 "나가는 토큰"을 만든다면, IdP mapper는 "들어오는 신원"을 변환합니다.

# OIDC IdP의 department 클레임을 사용자 attribute로
kcadm.sh create identity-provider/instances/customer-a-oidc/mappers -r myrealm \
  -s name=dept-import \
  -s identityProviderAlias=customer-a-oidc \
  -s identityProviderMapper=oidc-user-attribute-idp-mapper \
  -s 'config.claim=department' \
  -s 'config."user.attribute"=department' \
  -s 'config.syncMode=FORCE'

# SAML attribute를 realm role로
kcadm.sh create identity-provider/instances/customer-b-saml/mappers -r myrealm \
  -s name=admin-role-mapper \
  -s identityProviderAlias=customer-b-saml \
  -s identityProviderMapper=saml-role-idp-mapper \
  -s 'config."attribute.name"=memberOf' \
  -s 'config."attribute.value"=CN=ServiceAdmins' \
  -s 'config.role=platform-admin' \
  -s 'config.syncMode=FORCE'

가장 중요한 설정은 syncMode입니다.

IMPORT: 최초 로그인 시 한 번만 반영. 이후 IdP 쪽 변경은 무시.
FORCE: 로그인할 때마다 IdP 값으로 덮어씀.
LEGACY: 과거 호환 동작 (사용 비권장).

조직 정보나 롤처럼 IdP가 진실 공급원인 데이터는 FORCE로, 사용자가 Keycloak에서 직접 수정할 수 있는 프로필은 IMPORT로 두는 것이 일반적인 분리 기준입니다. FORCE 매핑으로 롤을 부여하는 경우, IdP에서 권한이 회수된 사용자의 롤도 다음 로그인 시 함께 회수되는지를 반드시 테스트해야 합니다.

브로커 토큰 저장과 Stored Tokens API

IdP 설정의 Store Tokens 옵션을 켜면 Keycloak이 외부 IdP의 access/refresh token을 저장합니다. 용도는 명확합니다. 외부 IdP의 API를 사용자 대신 호출하는 경우입니다. 예를 들어 GitHub 로그인 사용자의 저장소 목록을 읽는 기능이라면, 애플리케이션은 broker token retrieval 엔드포인트로 GitHub access token을 받아옵니다.

GET /realms/myrealm/broker/github/token HTTP/1.1
Host: kc.example.com
Authorization: Bearer KEYCLOAK_ACCESS_TOKEN

이 호출이 성공하려면 두 가지 조건이 필요합니다.

IdP 설정에서 Store Tokens 및 Stored Tokens Readable 활성화
호출 사용자에게 broker 클라이언트의 read-token 롤 부여

kcadm.sh add-roles -r myrealm \
  --uusername alice \
  --cclientid broker \
  --rolename read-token

운영 관점의 주의점은 저장된 외부 토큰의 수명입니다. Keycloak은 외부 refresh token으로 자동 갱신을 시도하지만, 외부 IdP가 토큰을 폐기하면 401이 그대로 전파됩니다. 애플리케이션은 stored token 호출 실패 시 재인가 유도(해당 IdP로 re-login) 경로를 반드시 구현해 두어야 합니다.

Keycloak 26의 Identity Brokering API v2 (Preview)

Keycloak 26.x에서는 Identity Brokering의 내부 SPI를 재설계한 v2 API가 preview로 도입되었습니다. 기존 brokering 확장은 AbstractIdentityProvider 상속과 흩어진 콜백 조합으로 구현해야 해서, 커스텀 IdP(예: 국내 본인인증 사업자, 레거시 사내 인증 게이트웨이) 연동 코드가 버전 업그레이드마다 깨지기 쉬웠습니다. v2는 인증 요청 생성, 응답 처리, identity 변환, linking 판단의 확장 지점을 더 명시적인 계약으로 분리하는 방향입니다. preview 단계이므로 프로덕션 적용은 이르지만, 커스텀 brokering 코드를 보유한 팀이라면 마이그레이션 계획을 지금부터 검토할 가치가 있습니다. 상세는 공식 릴리스 노트를 참고하시기 바랍니다.

기업 시나리오 — 고객사 IdP 연동 B2B SSO

B2B SaaS에서 "고객사마다 자기네 IdP로 SSO" 요구를 brokering으로 풀 때의 설계 포인트입니다.

                       +--------------------------------------+
                       |        Keycloak realm: saas          |
  Customer A users --> |  IdP: customer-a-oidc (Entra ID)     |
  Customer B users --> |  IdP: customer-b-saml (Okta)         |
  Direct users     --> |  Local username/password + passkey   |
                       |                                      |
                       |  Organizations 기능으로 도메인 매핑    |
                       |  a-corp.com -> customer-a-oidc       |
                       |  b-inc.com  -> customer-b-saml       |
                       +------------------+-------------------+
                                          |
                                          v
                                 SaaS Application (단일 클라이언트)

Home IdP Discovery: 로그인 화면에 IdP 버튼을 수십 개 나열할 수는 없으므로, 이메일 도메인으로 IdP를 자동 라우팅합니다. Keycloak의 Organizations 기능이 도메인-IdP 매핑과 멤버십 관리를 제공하므로 26.x 기준에서는 이 기능을 우선 검토하는 것이 좋습니다.
kc_idp_hint: 고객사 전용 진입 URL에서 로그인 화면을 건너뛰고 특정 IdP로 바로 보낼 때 사용합니다.

https://kc.example.com/realms/saas/protocol/openid-connect/auth
  ?client_id=saas-app
  &response_type=code
  &scope=openid
  &redirect_uri=https://app.example.com/callback
  &kc_idp_hint=customer-a-oidc

테넌트 격리 vs 단일 realm: 고객마다 realm을 분리하면 격리는 완벽하지만 realm 수가 늘수록 운영·메모리 비용이 커집니다. 단일 realm + IdP 다수 + Organizations 조합이 2026년 기준의 주류 패턴이고, 규제로 격리가 강제되는 고객만 별도 realm으로 빼는 하이브리드가 현실적입니다.
온보딩 자동화: 고객사 IdP 추가는 반복 작업이므로 Admin REST API나 Terraform으로 템플릿화합니다. 신규 고객 온보딩이 "티켓 처리"가 아니라 "셀프서비스 설정"이 되는 것이 목표입니다.

기본 flow를 복제해 요구사항에 맞게 변형하는 것이 정석입니다. 자주 쓰는 변형 세 가지를 소개합니다.

Review Profile 끄기: IdP 데이터가 신뢰 가능하면 사용자 확인 화면을 생략해 마찰을 줄입니다. Review Profile 실행을 OFF로 바꾸면 됩니다.
신뢰 IdP 자동 연결: 사내 IdP처럼 이메일 검증이 보장되는 경우, Handle Existing Account 아래에 Automatically Set Existing User 류의 executor를 배치해 확인 절차 없이 연결합니다. 외부 소셜 IdP에는 절대 적용하지 않습니다.
추가 정보 수집: 약관 동의, 부서 선택 같은 단계를 커스텀 Required Action 또는 커스텀 authenticator로 삽입합니다.

# 기본 flow 복제 후 IdP에 지정
kcadm.sh create authentication/flows/first%20broker%20login/copy -r myrealm \
  -s newName=corp-first-login

kcadm.sh update identity-provider/instances/customer-a-oidc -r myrealm \
  -s 'config.firstBrokerLoginFlowAlias=corp-first-login'

flow 변경은 반드시 시크릿 브라우저 창에서 신규 사용자/기존 사용자/이메일 중복의 세 케이스를 모두 회귀 테스트해야 합니다. flow 설정 실수는 전 사용자 로그인 불가로 직결되는 영역입니다.

트러블슈팅

현장에서 자주 만나는 brokering 장애를 증상별로 정리합니다.

증상	원인	해결
invalid_redirect_uri	외부 IdP에 broker endpoint 미등록	redirect URI를 IdP 콘솔에 정확히 등록
Page Expired	first login flow 중 뒤로가기/재시도	flow 재진입, Apple은 권한 초기화 후 재시도
이메일 없는 사용자 생성 멈춤	GitHub 비공개 이메일, scope 누락	user:email scope 추가
로그인 루프	broker와 IdP의 세션/프롬프트 설정 충돌	prompt 파라미터, IdP 세션 정책 확인
SAML Invalid signature	IdP 인증서 교체, 메타데이터 불일치	메타데이터 재임포트, 인증서 만료 모니터링
같은 사람이 계정 2개	linking 정책 부재로 신규 생성됨	중복 계정 병합 후 linking flow 정비
로그아웃해도 IdP 세션 유지	외부 IdP로 logout 전파 안 됨	IdP 설정의 backchannel/front-channel logout 지원 확인

디버깅 도구는 두 가지가 핵심입니다. 첫째, 어드민 콘솔의 Events (Login Events에서 IDENTITY_PROVIDER_LOGIN, FIRST_BROKER_LOGIN 등 이벤트 타입 필터링). 둘째, 서버 로그 레벨 조정입니다.

kc.sh start --log-level=INFO,org.keycloak.broker:DEBUG,org.keycloak.saml:DEBUG

SAML 문제는 브라우저 확장(SAML-tracer)으로 assertion 원문을 떠서 NameID 형식과 attribute 이름을 직접 확인하는 것이 가장 빠릅니다.

운영 베스트 프랙티스

brokering 구성은 만드는 것보다 유지하는 것이 어렵습니다. 운영 단계에서 챙겨야 할 항목을 정리합니다.

자격증명과 인증서의 수명 관리

외부 IdP와 주고받는 비밀 값에는 전부 만료가 있습니다. 만료 시점에 어떤 증상이 나타나는지까지 함께 외워 두면 장애 대응이 빨라집니다.

항목	일반적 수명	만료 시 증상
Apple client secret (서명 JWT)	최대 6개월	invalid_client 오류
소셜 IdP client secret	공급자 정책에 따름	unauthorized_client 오류
SAML IdP 서명 인증서	1~3년	Invalid signature 오류
외부 OIDC IdP의 JWKS 키	수시 롤테이션	일시적 토큰 검증 실패

Apple secret처럼 갱신이 예측 가능한 항목은 CI 스케줄로 자동화하는 것이 안전합니다.

# 매월 1회 CI에서 실행: p8 키로 새 client secret(JWT)을 생성해 반영
NEW_SECRET=$(python3 generate_apple_secret.py \
  --team APPLE_TEAM_ID --key-id APPLE_KEY_ID \
  --key-file AuthKey.p8 --client-id com.example.service)

kcadm.sh update identity-provider/instances/apple -r myrealm \
  -s "config.clientSecret=$NEW_SECRET"

이벤트를 SIEM으로 보내기

brokering 관련 이벤트는 보안 관제의 1차 신호입니다. 이벤트 저장을 활성화하고 IDENTITY_PROVIDER_LOGIN, FEDERATED_IDENTITY_LINK 같은 타입을 수집 대상에 포함시킵니다.

kcadm.sh update events/config -r myrealm \
  -s eventsEnabled=true \
  -s eventsExpiration=2592000 \
  -s 'enabledEventTypes=["LOGIN","LOGIN_ERROR","IDENTITY_PROVIDER_LOGIN","IDENTITY_PROVIDER_FIRST_LOGIN","IDENTITY_PROVIDER_LINK_ACCOUNT","FEDERATED_IDENTITY_LINK","REMOVE_FEDERATED_IDENTITY"]'

특히 FEDERATED_IDENTITY_LINK 이벤트의 급증은 linking 정책의 허점을 노리는 공격 시도일 수 있으므로 알림 룰을 걸어 두는 것을 권합니다. 커스텀 event listener SPI로 Kafka나 syslog에 직접 흘리는 구성도 일반적입니다.

정기 점검 체크리스트

분기마다 미사용 IdP(최근 로그인 이벤트 0건)를 비활성화 또는 제거합니다.
IdP별 로그인 성공률을 대시보드화하여 특정 고객사 IdP의 품질 저하를 조기에 감지합니다.
first broker login flow 변경 후에는 신규/기존/중복 이메일 3개 케이스의 E2E 테스트를 재실행합니다.
고객사 IdP의 메타데이터 URL을 주기적으로 폴링하여 인증서 교체를 자동 반영합니다.
realm export를 정기 백업하여 IdP 설정의 형상을 보존합니다.
Store Tokens를 켠 IdP는 저장 토큰의 유효성을 주기적으로 샘플 검사하고, 실패 시 재인가 플로우가 동작하는지 확인합니다.
Keycloak 버전 업그레이드 전에 커스텀 first broker login flow와 brokering 관련 SPI의 호환성을 스테이징에서 먼저 검증합니다.

마치며

Identity Brokering은 "소셜 로그인 붙이기"라는 작은 기능처럼 시작하지만, 결국 B2B SSO와 계정 수명주기 정책 전체를 떠받치는 기반이 됩니다. 핵심을 요약합니다.

애플리케이션은 Keycloak만 바라보고, IdP 추가·교체는 broker 설정으로 흡수합니다.
소셜 3사는 각자의 함정(Google hd 검증, GitHub 이메일 scope, Apple 1회성 프로필·시크릿 갱신)을 숙지해야 합니다.
account linking은 보안 결정입니다. 검증 안 된 이메일 기반 자동 연결은 계정 탈취 벡터입니다.
IdP mapper의 syncMode를 데이터 소유권에 따라 IMPORT/FORCE로 구분합니다.
B2B는 단일 realm + Organizations + 도메인 라우팅이 기본 패턴, 커스텀 brokering 코드는 API v2 전환을 준비합니다.