SSO & Identity 프로바이더 2026 완벽 가이드 - Keycloak 26 · Authentik · Authelia · Auth0 · Okta · AWS Cognito · Microsoft Entra ID 심층 분석

프롤로그 — 2026년, SSO는 더이상 '있으면 좋은 것'이 아니다

2010년대 SSO는 "큰 회사가 가진 사치품"이었다. 2020년대 초반에는 SaaS 폭증으로 "필요하지만 비싸다"는 회색지대였고, 2026년 현재 SSO는 모든 조직의 디폴트 인프라가 되었다.

이유는 단순하다.

• 한 사람이 평균 80개가 넘는 SaaS를 쓰고, 인증/탈퇴 관리는 사람 손으로는 불가능하다.
• NIS2(EU), DORA(EU 금융), PCI DSS 4.0.1, HIPAA Security Rule 2024, SOC 2 Type II 가 일제히 중앙집중 IAM, MFA, 세션 가시성 을 명시적으로 요구한다.
• Passkeys(WebAuthn/FIDO2)가 Apple, Google, Microsoft 세 곳에서 모두 동기화 가능한 상태가 되며 "패스워드 없는 인증"이 일반 사용자에게도 현실이 됐다.
• Auth0 Lock-in, Cognito 기능 폐기, ForgeRock → Ping 통합 같은 사건이 매니지드 IdP를 향한 신뢰를 흔들었고, Keycloak·Authentik·Ory 같은 오픈소스 대안이 다시 부상했다.

이 글은 그 전체 지형을 한 번에 정리한다. 표준에서 시작해, 오픈소스 IdP, 매니지드 SaaS, 라이브러리 진영, 인가(Authorization) 분리 흐름, 한국·일본의 현실까지.

한 줄 요약: "누가 인증하고, 누가 인가하고, 그 결정의 증거는 어디에 남고, 사람이 떠날 때 어떻게 정리되는가." 이 네 질문에 답하지 못하면 어떤 IdP를 깔아도 무용지물이다.

1장 · SSO가 풀려는 진짜 문제 — 사람·계정·세션·감사

SSO를 "로그인을 한 번만 하게 해주는 것"으로만 이해하면 본질을 놓친다. 진짜 문제는 네 겹이다.

여기에 provisioning/deprovisioning(SCIM), 권한 결정(Authorization), MFA 강제, 이상행위 탐지(Adaptive Auth)가 더해진다.

좋은 SSO는 단순히 "로그인 통합"이 아니라 "사람의 라이프사이클을 인프라로 다루는 시스템" 이다.

2장 · 핵심 표준 — OAuth 2.1, OIDC, SAML, SCIM, WebAuthn

2026년 시점에서 알아야 할 다섯 표준.

OAuth 2.1 은 2020년대 중반 IETF가 OAuth 2.0의 모범사례를 통합·강제한 버전이다. 핵심은 다음 네 가지를 MUST 로 격상한 것.

1. PKCE(Proof Key for Code Exchange) 모든 클라이언트에 의무화.
2. Implicit flow 제거. SPA도 Authorization Code + PKCE 사용.
3. Resource Owner Password Credentials 그랜트 제거.
4. Redirect URI 정확 매칭 — 와일드카드 금지.

OIDC 는 OAuth 위에 ID Token(서명된 JWT)을 얹어 "이 토큰을 들고 온 사람은 정말 사용자 X다"라는 신원 주장을 가능하게 한다. iss, sub, aud, exp, iat, nonce 가 표준 클레임이다.

SAML 2.0 은 XML/SOAP 시대의 유물이지만 엔터프라이즈에서는 여전히 90% 이상을 차지한다. OIDC로 못 바꾸는 SaaS가 너무 많다.

SCIM 2.0 은 IdP가 SaaS의 사용자 디렉터리를 자동으로 채워주는 표준이다. "Okta에서 직원이 퇴사하면 Slack에서 자동 비활성화" 가 SCIM의 일상이다.

WebAuthn / FIDO2 는 공개키 기반 인증으로, 비밀번호 자체를 없앤다. 2024-2026 사이 Apple iCloud Keychain, Google Password Manager, 1Password, Bitwarden이 모두 Passkey 동기화를 지원하면서 사실상 일반 사용자용 표준이 됐다.

3장 · OAuth 2.1 — PKCE, PAR, JAR, DPoP

OAuth 2.1 위에 보안 강화를 위한 네 가지 확장이 표준이 됐다.

PKCE(RFC 7636) — Authorization Code 가로채기를 막는다. 클라이언트가 code_verifier 라는 난수를 만들고, 그 SHA-256 해시(code_challenge)를 인가 요청에 실어 보낸다. 토큰 교환 시 다시 code_verifier 를 제출해서 같은 클라이언트임을 증명한다.

PAR(Pushed Authorization Requests, RFC 9126) — 인가 요청 파라미터를 브라우저 URL에 노출하지 않고 백채널로 IdP에 미리 푸시한다. 그 결과 받은 request_uri 만 브라우저로 보낸다.

JAR(JWT-Secured Authorization Request, RFC 9101) — 인가 요청 자체를 서명된 JWT로 보낸다. 파라미터 변조를 막는다.

DPoP(Demonstrating Proof-of-Possession, RFC 9449) — Bearer 토큰의 약점(가지고만 있으면 쓸 수 있음)을 보완한다. 클라이언트가 매 요청마다 자기 키로 서명된 DPoP 헤더를 첨부해 "이 토큰은 내 키에 묶여있다"는 증거를 보낸다.

2026년의 OAuth 가이드라인(IETF OAuth 2.0 Security BCP draft-ietf-oauth-security-topics-29)은 사실상 이 네 가지를 권장 또는 요구 한다.

# 의사 흐름 — Authorization Code + PKCE + PAR + DPoP
# 1) 클라이언트가 PAR로 인가 파라미터 푸시
POST /as/par
   client_id, redirect_uri, scope, state, code_challenge, code_challenge_method=S256
# 2) IdP가 request_uri 반환
# 3) 사용자 브라우저는 request_uri 만 들고 IdP로 이동
GET /as/authorize?client_id=...&request_uri=urn:ietf:params:oauth:request_uri:abc
# 4) 사용자 로그인 후 redirect_uri 로 code 전달
# 5) 클라이언트가 token endpoint 로 code + code_verifier 교환
# 6) 이후 모든 리소스 요청에 DPoP 헤더 첨부

4장 · OIDC — ID Token, Userinfo, Discovery, Logout

OIDC가 OAuth와 다른 점은 세 가지다.

1. ID Token — 사용자 정보를 담은 JWT가 access token과 함께 발급된다.
2. /userinfo 엔드포인트 — access token으로 사용자 프로필을 조회한다.
3. Discovery 문서 — /.well-known/openid-configuration 에서 모든 엔드포인트와 키 위치를 발견할 수 있다.

표준 ID Token JWT의 페이로드는 이런 모양이다.

{
  "iss": "https://idp.example.com/realms/main",
  "sub": "8af2a1b8-f1a0-4d5c-a3a0-d10a3b9c9e22",
  "aud": "my-app",
  "exp": 1747459200,
  "iat": 1747455600,
  "nonce": "c6f3b1e2c0f7",
  "auth_time": 1747455600,
  "acr": "urn:mace:incommon:iap:silver",
  "email": "alice@example.com",
  "email_verified": true,
  "preferred_username": "alice"
}

검증 시 반드시 확인해야 할 클레임:

• iss — 신뢰하는 IdP 인가
• aud — 내 클라이언트 ID 인가
• exp / iat — 만료/발급 시각이 유효한가
• nonce — 인가 요청에 보낸 값과 일치하는가
• 서명 — JWKS(jwks_uri)에서 키를 가져와 검증했는가

Single Logout 은 OIDC가 끝까지 잘 못 푼 문제다. 백채널/프런트채널 로그아웃 두 방식이 있고, 둘 다 한계가 있다. 그래서 2026년 추세는 "짧은 access token + refresh token rotation + IdP 세션 무효화 시 즉시 만료" 라는 운영 패턴으로 옮겨가고 있다.

5장 · SAML 2.0 — 죽지 않는 XML

엔터프라이즈에서 SAML이 사라지지 않는 이유는 두 가지다. 첫째, 이미 깔린 SaaS의 상당수가 SAML만 지원한다. 둘째, IT/감사 부서 사람들이 SAML 어설션 모양에 익숙하다.

SAML SSO의 흐름은 OIDC보다 복잡하다.

1. 사용자가 SP(Service Provider, 예: Salesforce)에 접근
2. SP가 SAMLRequest를 만들어 IdP(예: Okta)로 리다이렉트
3. IdP가 로그인 후 SAMLResponse(XML, 서명됨)를 SP의 ACS URL로 POST
4. SP가 어설션을 검증하고 세션을 만든다

<!-- 단순화한 SAML Response 발췌 -->
<samlp:Response>
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
  <saml:Assertion>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
        alice@example.com
      </saml:NameID>
    </saml:Subject>
    <saml:Conditions NotBefore="..." NotOnOrAfter="..."/>
    <saml:AttributeStatement>
      <saml:Attribute Name="memberOf">
        <saml:AttributeValue>engineering</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

SAML의 약점은 명확하다. 시그너처 우회(XML Signature Wrapping), 어설션 재생, 메타데이터 파일 변조 등 공격면이 넓다. 2026년에는 "신규 통합은 OIDC, 기존 SaaS는 SAML 유지" 라는 이중 운용이 표준이다.

6장 · SCIM 2.0 — 프로비저닝 표준

SCIM(System for Cross-domain Identity Management, RFC 7643/7644)은 IdP가 SaaS의 사용자 디렉터리에 사용자/그룹을 푸시하기 위한 REST API 표준이다.

핵심 엔드포인트:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "alice@example.com",
  "name": { "givenName": "Alice", "familyName": "Kim" },
  "emails": [{ "value": "alice@example.com", "primary": true }],
  "active": true,
  "externalId": "8af2a1b8-f1a0-4d5c-a3a0-d10a3b9c9e22"
}

직원이 HR 시스템에서 퇴사 처리되면, IdP는 SCIM PUT으로 active=false 를 모든 연결된 SaaS에 푸시한다. 이게 작동하지 않는 SaaS가 곧 보안 부채다.

2026년 현재 SCIM을 안 받는 SaaS는 엔터프라이즈 시장에서 거의 살아남지 못한다. Slack, Notion, Figma, Linear, Datadog, GitHub Enterprise 모두 지원한다.

7장 · WebAuthn / FIDO2 / Passkeys — 비밀번호의 종말

WebAuthn(W3C)과 FIDO2 CTAP2(FIDO Alliance)는 같은 문제를 푼다. 사용자 디바이스에 비공개키를 저장하고, 인증할 때 챌린지에 서명한다. 비밀번호는 아예 없다.

핵심 흐름:

1. 등록(Registration) — 사용자가 디바이스에서 키쌍을 만들고, 공개키만 서버에 등록.
2. 인증(Authentication) — 서버가 챌린지를 보내고, 디바이스가 비공개키로 서명. 서버는 공개키로 검증.

Passkeys 는 WebAuthn 인증자(authenticator)가 동기화 가능한 형태로 진화한 것이다. Apple iCloud Keychain, Google Password Manager, 1Password, Bitwarden이 모두 디바이스 간 동기화를 지원한다.

// WebAuthn 등록 - 단순화한 의사 코드
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,
    rp: { name: "Example App", id: "example.com" },
    user: { id: userIdBuffer, name: "alice", displayName: "Alice" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],
    authenticatorSelection: {
      authenticatorAttachment: "platform",
      residentKey: "required",
      userVerification: "required"
    }
  }
})
// credential.response.attestationObject 를 서버로 전송 -> 검증 -> 공개키 저장

2026년 현재 Google, Microsoft, Apple, GitHub, Shopify, PayPal, Amazon이 모두 Passkey 로그인을 지원한다. 한국에서는 카카오, 네이버, 토스가 부분 지원 단계에 있다.

8장 · Keycloak 26 / 26.1 — 오픈소스 IdP의 사실상 표준

Keycloak 은 2014년 Red Hat이 시작한 오픈소스 IdP다. 2024년 26.0이 LTS로 풀린 뒤 26.1까지 점진적 개선이 이어졌다. 2026년 시점에서 자체 호스팅 IdP의 사실상 표준이다.

26 라인의 변화는 크다.

• Quarkus 기반 재작성 — 19.x 까지의 WildFly 기반이 완전히 정리되고 Quarkus 단일 배포로 통일.
• Account Console v3 — 사용자가 자기 계정을 관리하는 새 UI(React + i18n).
• Organizations — 한 Realm 안에 여러 조직을 두는 멀티테넌시 모델(26.0 GA).
• Fine-Grained Admin Permissions v2 — 관리자 권한을 리얼름/리소스 단위로 잘게 자르는 모델 재설계.
• mTLS Client Authentication — 클라이언트가 mTLS로 인증.
• DPoP 지원 — 토큰 sender-constraining.
• OAuth 2.0 Step-Up Authentication Challenge — 민감 작업 시 추가 인증 요구.

Red Hat build of Keycloak(RHBK)은 같은 Keycloak에 Red Hat의 라이프사이클·CVE 패치 보증을 입힌 상업 버전이다. 라이선스는 여전히 Apache 2.0.

9장 · Keycloak의 핵심 개념 — Realm, Client, IdP Brokering, User Federation

Keycloak을 처음 만질 때 헷갈리는 것은 단어다.

Identity Brokering 은 "외부 Google/GitHub/Microsoft 로그인을 Keycloak이 받아, 내부 사용자로 매핑"하는 기능. 사용자는 외부 IdP로 인증하지만 우리 앱은 항상 Keycloak만 본다.

User Federation 은 반대로 "기존 LDAP/AD를 사용자 소스로 쓰되, Keycloak이 인증을 책임"지는 모델. 마이그레이션 없이 점진적 전환이 가능하다.

SPI(Service Provider Interface)는 거의 모든 영역에 확장 포인트를 제공한다. 사용자 저장, 인증 흐름, 이벤트 리스너, 토큰 매퍼, 이메일 템플릿 등. Java로 작성된 jar을 providers/ 디렉터리에 넣고 빌드하면 등록된다.

10장 · Keycloak 운영 — Docker Compose, Helm, PostgreSQL, HA

자체 호스팅의 정직한 모양은 이렇다.

# 단순 운영 - 단일 노드 - Postgres 외부
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: keycloak
      POSTGRES_USER: keycloak
      POSTGRES_PASSWORD: changeme
    volumes:
      - kc_pg:/var/lib/postgresql/data

  keycloak:
    image: quay.io/keycloak/keycloak:26.1
    command: start --optimized
    environment:
      KC_DB: postgres
      KC_DB_URL: jdbc:postgresql://postgres:5432/keycloak
      KC_DB_USERNAME: keycloak
      KC_DB_PASSWORD: changeme
      KC_HOSTNAME: id.example.com
      KC_PROXY_HEADERS: xforwarded
      KC_HTTP_ENABLED: "true"
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: changeme
    ports:
      - "8080:8080"
    depends_on:
      - postgres

volumes:
  kc_pg:

운영에 가까워질수록 신경 쓸 것들.

• HA — Infinispan 분산 캐시 + Postgres 읽기복제. Kubernetes Operator(keycloak.org/keycloak)가 표준.
• TLS 종단 — nginx/HAProxy/Traefik 앞단에서 종단하고 Keycloak에는 proxy header 신뢰.
• 백업 — 모든 상태는 Postgres에 있다. Realm export/import 보조.
• 모니터링 — Prometheus 메트릭(/metrics), 이벤트 리스너로 Kafka/SIEM 송출.
• 테마 — login/account/admin 세 종에 회사 디자인 시스템 입히기.

가장 흔한 운영 실수: 관리자 비밀번호를 환경변수로 영구 노출하기, Realm export에 비밀까지 같이 백업하기, Postgres 백업 정책 없음, JVM 메모리 디폴트 그대로 두기.

11장 · Authentik 2025 — Beryju가 만든 현대적 대안

Authentik(beryju.io)은 Python/Django로 작성된 비교적 새로운 오픈소스 IdP다. 2025년 라인이 안정화되며 Keycloak 다음 자리를 굳혔다.

특징:

• Flow 기반 인증 — 로그인을 노드 그래프로 구성. 단계 추가/조건분기/외부 호출이 모두 GUI로.
• 현대적 UI — Lit + TypeScript로 만든 어드민 콘솔. Keycloak 어드민 UI의 답답함을 노골적으로 의식한 설계.
• 프로토콜 — OAuth 2.0/OIDC, SAML 2.0, LDAP(서버 노출), Proxy, RADIUS 모두 지원.
• Outpost — 프록시·LDAP·RADIUS 같은 보조 서비스를 컨테이너로 배포.
• Enterprise — 2024년부터 유료 플랜(GeoIP, Audit, RAC, Wizard)이 추가됨.

자체 호스팅 IdP를 새로 시작한다면 2026년에는 "Keycloak vs Authentik" 둘 사이의 선택이 디폴트 질문이다. 거대 LDAP/AD 자산이 있다면 Keycloak, 처음부터 OIDC만 한다면 Authentik이 흔한 답.

12장 · Authelia 4.39 — 리버스 프록시와 결합하는 자기호스팅 2FA

Authelia(authelia.com)는 Go로 작성된 자기호스팅 인증 포털이다. 다른 IdP들과 결합 방식이 다르다.

핵심 모델: nginx/Traefik/Caddy 같은 리버스 프록시 앞단에서 ForwardAuth로 인증을 강제한다. 즉 Authelia는 IdP라기보다 보호 게이트웨이 다.

# nginx ForwardAuth - Authelia
location /api/verify {
  proxy_pass http://authelia:9091/api/verify;
}

location / {
  auth_request /api/verify;
  auth_request_set $user $upstream_http_remote_user;
  proxy_set_header Remote-User $user;
  proxy_pass http://upstream-app:3000;
}

이 모델은 두 가지 시나리오에서 강력하다.

1. OIDC 없는 레거시 앱에 통일된 2FA를 강제하고 싶을 때.
2. 자기호스팅 홈랩에서 nextcloud, jellyfin, paperless-ngx, sonarr 같은 도구들에 한꺼번에 인증을 씌우고 싶을 때.

OIDC 발급도 부분적으로 지원하지만, Authelia의 본업은 ForwardAuth 게이트웨이다. Keycloak/Authentik의 대체재라기보다 보완재다.

13장 · Casdoor, Ory Stack, Logto — 오픈소스 신진 세력

Casdoor(casbin.org)는 Go로 작성된 모듈형 IAM이다. OAuth 2.0/OIDC, SAML, CAS, LDAP, RADIUS 다 지원하고 멀티테넌시가 자연스럽다. Casbin(RBAC/ABAC 정책 엔진)과 같은 조직이라 인가가 강하다.

Ory Stack 은 Go 기반의 모듈 합본이다.

Ory는 "헤드리스" 를 자처한다. UI를 안 주고 API만 준다. 그래서 Next.js나 Flutter 같은 자기 UI에 맞게 통합하기 좋다.

Logto(logto.io)는 2022년 출범한 비교적 새로운 오픈소스 IdP. 개발자 경험을 최우선으로 잡고 SDK, 콘솔, 다크모드, M2M, RBAC, Organization을 잘 정돈해 두었다. Cloud 매니지드 옵션도 있다.

SuperTokens 와 FusionAuth(상용·자체호스팅 둘 다) 도 같은 슬롯의 경쟁자다. 라이선스와 가격, UI 품질이 선택의 결정 요소다.

14장 · Auth0 — 매니지드의 클래식

Auth0(2013년 창업, 2021년 Okta 인수)은 매니지드 IdP의 사실상 원조다. 2026년에도 SaaS 스타트업의 디폴트 선택지로 남아있다.

특장점:

• Universal Login — 호스팅된 로그인 페이지. 보안 패치를 Auth0가 책임.
• Actions / Rules(Actions로 통합 중) — 인증 흐름의 훅에 사용자 JS를 끼워 클레임 추가, 외부 API 호출, MFA 강제 등.
• Adaptive MFA / Bot Detection — 위험 점수 기반 MFA 강제.
• Branding & i18n — 거의 모든 화면이 테마/언어로 커스터마이즈.
• Connections — Database, Social(Google/GitHub/Apple), Enterprise(SAML/AD/LDAP), Passwordless.

가장 큰 약점은 가격과 락인이다. Tenant migration이 가능하긴 하나 Actions·Hooks·Custom DB 액션·Lock JS 위젯에 모두 의존성이 깊어 빠져나오기 힘들다는 후기가 흔하다. 그래서 2024-2026년 사이 Auth0 → Keycloak, Auth0 → Clerk 마이그레이션 사례가 다수 공개됐다.

15장 · Okta Workforce & Customer Identity Cloud

Okta 는 매니지드 IdP의 다른 한 축이다. 2022년 8월의 LAPSUS$ 침해, 2023년 10월의 지원 시스템 침해를 거치면서 보안 운영을 대대적으로 강화했다.

Workforce Identity Cloud(WIC) 는 직원용 IdP다.

• SAML/OIDC SSO, MFA, Adaptive Auth
• Lifecycle Management — HR/HRIS → Okta → SaaS 자동 프로비저닝
• Workflows — 노코드 자동화(BambooHR 이벤트로 Slack/GitHub 계정 자동 생성)
• Identity Governance — Access Certification, SoD, Access Requests

Customer Identity Cloud(CIC) 는 Auth0 인수 후 통합된 고객용 IdP다. 본질적으로는 Auth0를 Okta 브랜드로 묶은 것.

기업의 90%가 Okta를 쓰는 슬롯은 Workforce + SaaS 통합 영역이다. 직원 100명 이하라면 가격이 부담이지만, 수백 명 이상이면 SCIM·Workflow의 가치가 가격을 정당화한다.

16장 · AWS Cognito — User Pools, Identity Pools, 그리고 기능 폐기 소동

AWS Cognito 는 AWS 네이티브 IdP다. 두 가지 슬롯이 있다.

장점은 명확하다. AWS 안에서 운영비가 거의 무료에 가까우며, AWS SDK·IAM과의 통합이 매끄럽다.

단점도 명확하다. 2024-2025년 사이 Cognito가 일부 기능을 폐기·재구성하며 큰 논란이 일었다. 대표 사례 둘.

1. Custom Email Sender Lambda 의 SMS·MFA 흐름 일부 변경.
2. Hosted UI 의 OIDC 표준 적합성 한계 — nonce 검증, refresh token 회전 등에서 표준과 어긋나는 동작이 다수 보고됨.

또 다른 약점은 데이터 익스포트 다. User Pool 사용자를 비밀번호 해시까지 통째로 옮기는 표준 경로가 없다(가능은 하지만 자체 Lambda 트리거 + 마이그레이션 흐름이 필요). 그래서 "쉽게 들어가서 나가기 어려운" IdP라는 평이 굳어졌다.

새 프로젝트에 Cognito를 고르려면 다음 두 질문에 분명하게 답해야 한다. (1) 우리는 AWS 안에서만 살 것인가, (2) Hosted UI 한계를 우리가 감당할 수 있는가.

17장 · Microsoft Entra ID — 옛 Azure AD, 그리고 External ID

Microsoft Entra ID(2023년 Azure AD에서 리브랜드)는 사실상 세계에서 가장 큰 IdP다. Office 365·Microsoft 365·Windows 도메인이 모두 Entra ID로 묶인다.

핵심 기능:

• Conditional Access — 조건부 접근 정책. 사용자/디바이스/네트워크/리스크 기반으로 MFA·차단 결정.
• Privileged Identity Management(PIM) — 관리자 권한을 시간제한으로 활성화. Just-In-Time admin.
• Identity Protection — 위험 점수 기반 이상행위 탐지.
• Microsoft Authenticator + Passkey 지원.

Entra External ID 는 2024년 출범한 CIAM(고객용 IAM) 서비스다. 이전의 Azure AD B2C가 사실상 별도 라인으로 분리된 것이고, External ID가 그 자리를 잇는다.

엔터프라이즈에서 Entra가 디폴트인 이유: 라이선스가 Microsoft 365에 사실상 묶여있다. 추가 비용 없이 SSO 기본세트가 따라온다. 단점은 멀티클라우드/멀티벤더 환경에서 Microsoft 종속이 깊어진다는 것.

18장 · Google Cloud Identity, Workspace SSO, 그리고 신진 SaaS IdP들

Google Cloud Identity / Workspace SSO — Google이 IdP로 직장 도메인을 책임진다. Workspace를 쓰는 회사는 SAML SP를 등록하면 즉시 Google 로그인을 SSO로 쓸 수 있다.

신진 SaaS IdP는 2020년대 들어 다음과 같이 분화됐다.

이 그룹의 공통점은 개발자 경험(DX)을 핵심 차별점으로 내세웠다는 것. 콘솔, SDK, 컴포넌트, 문서가 Auth0보다 가볍고 빠르게 시작된다. 대신 엔터프라이즈 거버넌스(Audit, Lifecycle, IGA)는 Okta/Entra만큼 깊지 않다.

19장 · Auth.js, Lucia, better-auth, Clerk — 라이브러리 진영

매니지드/자체호스팅 IdP 외에 "프레임워크 안에서 IdP를 코드로 짜는" 방향이 있다.

Auth.js v5(예전 NextAuth.js)는 2024-2025년 사이 Next.js App Router에 맞춰 v5로 재설계됐다. OAuth/OIDC 프로바이더 70개 이상, 데이터베이스 어댑터 다수, Edge runtime 지원.

// auth.config.ts 예시 - Auth.js v5
import NextAuth from "next-auth"
import GitHub from "next-auth/providers/github"

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [GitHub],
})

Lucia v3는 헤드리스 세션 라이브러리. 2024년 v3는 사실상 사용자가 OAuth 흐름을 직접 짜는 방향을 강화했다. 2025년 메인테이너가 "Lucia를 라이브러리가 아니라 학습 자료로 재포지셔닝"한다고 발표한 게 큰 사건이었다.

better-auth(better-auth.com)는 2024년 출범한 새 라이브러리. Lucia의 "직접 짜자" 와 Auth.js의 "프레임워크 통합" 사이를 잡았다. 플러그인 구조가 강하다.

Clerk 는 매니지드 SaaS지만 React/Next.js 친화 컴포넌트(<SignIn />, <UserButton />)를 앞세워 라이브러리처럼 쓰인다. Organizations, B2B 멀티테넌시, Passkey, Webhook 모두 잘 다듬어져 있다.

선택 가이드:

• 사용자 디렉터리·관리 콘솔이 필요 → 매니지드(Clerk, Auth0) 또는 자체호스팅(Keycloak)
• 코드 통제권을 끝까지 가져가고 싶다 → Auth.js / better-auth
• "라이브러리 학습용으로 직접 짜본다" → Lucia 문서 기반

20장 · 인가의 새 시대 — OPA, OpenFGA, SpiceDB, Permify

2026년의 큰 변화 중 하나는 인증과 인가의 분리다. IdP가 인증을 책임지고, 인가는 별도의 엔진이 가져간다.

OPA(Open Policy Agent, CNCF Graduated)는 Rego DSL로 정책을 쓴다.

package authz

default allow := false

allow if {
  input.user.role == "admin"
}

allow if {
  input.user.id == input.resource.owner
  input.action == "read"
}

OpenFGA(2022년 Auth0가 오픈소스로 공개, CNCF Sandbox)와 SpiceDB(Authzed)는 Google Zanzibar 논문에 기반한 ReBAC(Relationship-Based Access Control) 엔진이다.

Zanzibar의 직관은 단순하다. 모든 권한을 "사용자 — 관계 — 객체" 형태의 튜플로 표현한다.

# Zanzibar 튜플 예시
user:alice    member        organization:acme
group:eng     member        organization:acme
user:bob      member        group:eng
document:doc1 viewer        group:eng

user:bob 이 document:doc1 을 볼 수 있는가? → bob 이 eng 의 멤버이고 eng 가 doc1 의 viewer이므로 yes. 이런 그래프 검사를 ms 단위로 처리하는 게 Zanzibar 류 엔진의 본업이다.

Permify 는 같은 방향의 또 다른 오픈소스. Go로 작성, 직관적인 스키마 DSL, 다양한 데이터스토어 지원.

이 흐름의 본질은 권한 결정을 애플리케이션 코드에서 떼어내는 것이다. 권한 로직이 코드에 흩어져 있으면 변경할 때마다 배포가 필요하고 감사도 어렵다. 정책 엔진을 외부화하면 정책 자체가 데이터/구성이 된다.

21장 · 한국과 일본의 SSO 현실

한국.

• Naver Cloud IAM — 네이버 클라우드의 자체 IAM. SAML 2.0 IdP 역할 가능.
• Kakao i Identity — 카카오엔터프라이즈가 제공하는 기업용 IAM/SSO.
• KT Cloud SSO — KT의 SAML/OIDC IdP. 공공·금융 고객 다수.
• SK ICT-IAM — SK 그룹 내 IAM 표준화 흐름.
• 정부 GovWAY / GPKI — 공공기관용 SSO·인증서 프레임워크.
• 민간 금융 인증서, 토스 인증, PASS — 본인확인용. SSO와는 결이 다르지만 KYC 단계에 결합.

엔터프라이즈에서는 Okta·Entra ID가 대기업 중심으로 들어왔고, Keycloak·Authentik이 중견·스타트업 자체 호스팅 슬롯을 차지한다. NHN Cloud, 카카오 i 같은 국산 클라우드가 자체 SSO를 강화하는 흐름도 분명하다.

일본.

• Trust IdP(국립정보학연구소, NII) — 학술·연구 기관용 SAML federation.
• Cybozu Office / Cybozu KUNAI — Cybozu의 기업용 SSO.
• NTT Communications IDPro — NTT가 운영하는 매니지드 IdP.
• OpenAM(ForgeRock 오픈소스 포크) — 일본 OSS 커뮤니티 중심으로 유지보수 지속.
• TrustLogin(GMO) — 일본 SaaS SSO 어그리게이터.
• HENNGE One — 일본 시장의 SSO/메일 보안 솔루션. 일본 SaaS와의 통합이 두텁다.

일본 시장은 ForgeRock(OpenAM) 유산이 두텁고, Microsoft 365·Google Workspace를 그대로 IdP로 쓰는 비율이 높다. HENNGE One은 일본 로컬 SaaS와의 SAML 어댑터를 풍부하게 가지고 있어서 "직접 IdP 깔기 싫은 회사"의 디폴트가 된다.

22장 · 마이그레이션과 락인 — ForgeRock·Auth0·Cognito의 교훈

ForgeRock → Ping Identity — 2023년 8월 Thoma Bravo가 Ping Identity와 ForgeRock 인수를 완료하며 두 제품 라인이 통합 로드맵으로 들어갔다. 이후 ForgeRock의 일부 기능이 단계적으로 정리되거나 Ping의 동등 기능으로 흡수되며 기존 고객들의 마이그레이션 부담이 가시화됐다.

Auth0 락인 — 앞서 본 것처럼 Actions/Rules/Custom DB Action에 의존성이 깊은 회사일수록 빠져나오기 어렵다. 마이그레이션 전략은 일반적으로 (1) Auth0 → Keycloak/Clerk로 더블 쓰기 → 점진 컷오버, (2) 비밀번호 해시 익스포트 가능 여부에 따라 마이그레이션 흐름 달라짐.

AWS Cognito 기능 폐기 — 2024-2025년의 일부 기능 변경은 사용자 신뢰에 부정적 영향을 줬다. 새 프로젝트는 Cognito를 "AWS-only 시나리오 + 단순한 사용자 디렉터리" 슬롯으로만 좁히고, 복잡한 인증 흐름이 필요하면 다른 IdP를 고르는 패턴이 늘었다.

Keycloak 18 → 26 마이그레이션 — WildFly 기반에서 Quarkus 기반으로 옮겨가는 큰 변화가 있었다. 18.x 이하에서 26.x로 옮기려면 (1) DB 스키마 자동 마이그레이션, (2) 빌드 단계 변화(kc.sh build), (3) 일부 SPI 인터페이스 시그니처 변경 대응이 필요했다. LTS 사이클을 따라 26.0이나 26.1에 한 번 정착하는 것이 표준 권장.

마이그레이션의 일반 원칙은 다음 세 가지.

1. 표준 위에 있어라 — OIDC·SAML·SCIM 같은 표준을 IdP-네이티브 기능보다 우선 사용.
2. 비밀번호 해시 익스포트 경로가 있는 IdP를 골라라. 없는 IdP는 사실상 락인.
3. 이벤트 로그를 외부 SIEM으로 빼두어라. IdP를 갈아도 감사 트레일이 남는다.

결론 — IdP는 선택이 아니라 라이프사이클이다

이 글은 22개 챕터로 펼쳤지만, 결국 한 줄로 응축된다.

"인증·인가·프로비저닝·감사를 하나의 라이프사이클로 다루지 못하면, 어떤 IdP를 깔아도 부분 해결밖에 안 된다."

작은 팀의 권장 출발점.

• 매니지드를 빠르게 → Clerk 또는 Auth0(가격 감수)
• 자체호스팅 + 거버넌스 → Keycloak 26 단일 노드 + Postgres
• 현대적 UI 자체호스팅 → Authentik
• 리버스 프록시 게이트웨이 → Authelia
• 인가 분리 → OpenFGA 또는 SpiceDB
• 라이브러리로 시작 → Auth.js v5 또는 better-auth

엔터프라이즈의 권장 출발점.

• 직원용 → Okta WIC 또는 Entra ID(라이선스 활용)
• 고객용 → Auth0, Okta CIC, 또는 Keycloak Multi-tenant
• HR → IdP → SaaS 자동 프로비저닝 → Okta Lifecycle 또는 Workato/Tray + SCIM
• 정책 엔진 → OPA 또는 SpiceDB 외부 인가

도구는 바뀐다. 표준은 천천히 바뀌고 라이프사이클은 거의 안 바뀐다. 그러니 표준과 라이프사이클을 먼저 설계하고, 도구는 그 위에 얹어라.

참고 자료

• Keycloak Documentation
• Keycloak 26 Release Notes
• Red Hat build of Keycloak
• Authentik Documentation
• Authelia Documentation
• Casdoor Documentation
• Ory Documentation
• Logto Documentation
• Auth0 Documentation
• Okta Developer Documentation
• AWS Cognito Developer Guide
• Microsoft Entra ID Documentation
• Microsoft Entra External ID Overview
• OAuth 2.1 Draft
• OAuth Security BCP
• OpenID Connect Core 1.0
• WebAuthn Level 3 (W3C)
• FIDO Alliance Specifications
• SCIM 2.0 RFC 7644
• SAML 2.0 OASIS Standard
• Open Policy Agent
• OpenFGA Documentation
• Authzed SpiceDB
• Permify Documentation
• Auth.js v5 Documentation
• Lucia Auth
• better-auth Documentation
• Clerk Documentation
• HENNGE One
• Naver Cloud IAM