신원 공급자(IdP) 아키텍처 분석: 디렉터리와 인증의 분리, SAML과 OIDC의 프로토콜 차이

양준호2026.11.03수정 2026.11.03

들어가며

기업 환경에서 싱글사인온(SSO)을 설계하다 보면 IdP, SAML, OIDC, IAM Identity Center와 같은 용어가 혼용되며, 이로 인해 “어느 구성 요소가 실제로 인증을 수행하는가”라는 근본적인 질문이 모호해지는 경우가 많습니다.

해당 블로그는 신원 공급자의 역할을 디렉터리(directory) 와 인증(authentication) 이라는 두 축으로 구분 하고, 이를 구현하는 두 표준 프로토콜인 SAML 2.0과 OpenID Connect(OIDC)의 기술적 차이에 대하여 작성 하려고 합니다.

마지막으로 Amazon Quick 데스크톱 애플리케이션 연동 사례를 통해 이러한 개념적 구분이 실제 아키텍처 구성에 어떻게 사용 되는지 확인해 보겠습니다.

** 부록으로 인증과 관련된 이야기에 기본적으로 나오는 Authentication, Authorization, Authority 에 대하여 간단히 설명 하였습니다. 먼저 읽고 시작 하면 이해 하기에 더 좋습니다.

1. 신원 공급자(Identity Provider)의 정의와 범위

신원 공급자(IdP) 는 사용자의 신원을 검증하고, 그 검증 결과를 신뢰 관계에 있는 서비스 공급자(Service Provider, SP)에게 보증하는 시스템 입니다.

SSO 아키텍처에서 IdP는 신뢰의 단일 지점(single point of trust)으로 기능하며, SP는 사용자의 자격 증명(credential)을 직접 처리하지 않고 IdP가 발급·서명한 신원 증명물 만을 신뢰합니다. 이 증명물의 구체적 형태는 프로토콜에 따라 다르며, SAML에서는 XML 형식의 Assertion 이, OIDC에서는 JWT 형식의 토큰(ID Token 등) 이 그 역할을 합니다(상세는 3절 참조).

대표적인 IdP 를 제공하는 서비스는 다음과 같습니다.

Okta
Microsoft Entra ID (구 Azure Active Directory)
Google Workspace
Ping Identity (PingFederate, PingOne)
AWS IAM Identity Center (구 AWS Single Sign-On)

SP 관점에서 IdP와의 관계는 신뢰 위임(trust delegation) 으로 요약됩니다. SP는 인증 책임을 IdP에 위임하고, IdP가 서명한 보증(SAML Assertion 또는 OIDC ID Token)의 서명 유효성과 클레임(claim) 만을 검증합니다.

2. 핵심 구분: 디렉터리(명부)와 인증(authentication)은 별개의 책임이다

IdP를 구현 시, 가장 빈번하게 혼동되는 지점이 IdP가 수행하는 역할이 사실상 두 개의 독립적인 책임으로 구성된다는 사실 입니다.

책임	기능	보유 데이터/동작
디렉터리 (Identity Store)	사용자·그룹·속성의 저장 및 수명주기 관리	사용자 레코드, 그룹 멤버십, 속성(attribute)
인증 (Authentication)	자격 증명 검증 및 신원 보증 발급	비밀번호·MFA 검증, 세션 수립, 토큰/Assertion 서명

이 두 책임은 단일 제품이 모두 수행할 수도 있고, 서로 다른 시스템이 분담할 수도 있습니다.

Okta나 Entra ID는 일반적으로 디렉터리와 인증을 단일 플랫폼 내에서 통합 제공합니다.
반면 페더레이션(federation) 구성에서는 디렉터리는 한 시스템이, 실제 인증은 상위 IdP가 담당하는 분리 구조가 나타납니다. 예를 들어 사용자 명부는 디렉터리 서비스에 두되, 실제 로그인 검증은 외부 IdP에 위임하는 형태입니다.

2.1 실제 서비스에서의 역할 매핑

추상적인 두 책임을 실제 서비스에 대응시키면 구분이 보다 명확해집니다.

제품/구성 요소	디렉터리	인증	비고
Active Directory / LDAP	●	△	명부 중심. 인증은 Kerberos/LDAP bind 등 저수준
Okta / Entra ID	●	●	디렉터리와 인증을 통합 제공하는 범용 IdP
AWS IAM Identity Center	●	● / 위임	자체 디렉터리 보유. 외부 IdP를 연결하면 인증을 위임
Amazon Cognito	●	●	자체 User Pool(디렉터리) + OIDC 인증
SAML/OIDC IdP 엔드포인트	✕	●	인증·토큰 발급 담당(명부는 별도)

특히 주목할 구성은 “디렉터리와 인증을 서로 다른 시스템이 나눠 갖는” 경우입니다.

예를 들어 AWS IAM Identity Center가 사용자 명부(디렉터리) 를 보유하면서, 실제 로그인 인증은 외부 기업 SSO(SAML)에 위임하는 형태가 대표적입니다. 이 경우 “누가 사용자인가”는 IdC가, “로그인이 유효한가”는 외부 SSO가 책임집니다.

2.2 진실의 원천(Source of Truth)과 복제본

명부가 여러 시스템에 동시에 존재할 때는, 어느 쪽이 원본(source of truth) 이고 어느 쪽이 복제본(replica) 인지를 명확히 해야 합니다. 복제본은 원본으로부터 단방향으로 동기화되는 것이 일반적이며, 원본에서 발생한 사용자 추가·삭제가 복제본에 반영되기 전까지는 두 시스템의 상태가 불일치 합니다.

예를 들어 “디렉터리는 IAM Identity Center가 원본으로 관리하고, 특정 애플리케이션 인증을 위해 그 사용자를 Amazon Cognito로 동기화”하는 구성에서는, IdC가 진실의 원천이고 Cognito는 인증 처리를 위한 복제본 입니다. 이때 원본(IdC)에 사용자를 추가해도 동기화가 수행되기 전에는 복제본(Cognito)에 해당 사용자가 존재하지 않으며, 따라서 그 사용자는 복제본을 통한 로그인이 불가능합니다. 이 동기화는 수동 스크립트, 또는 이벤트 기반 자동화(예: 디렉터리 변경 이벤트 → 동기화 함수) 등으로 구현됩니다.

2.3 디렉터리와 인증을 분리하는 이유

두 책임을 분리하는 설계는 다음과 같은 이점을 제공합니다.

인증 방식의 독립적 교체 — 명부는 그대로 두고 인증 프로토콜(SAML ↔ OIDC)이나 IdP만 교체할 수 있습니다. 사용자 데이터를 재구축할 필요가 없습니다.
단일 명부, 다중 인증 경로 — 하나의 명부를 여러 인증 수단(웹 SSO, 네이티브 앱용 OIDC 등)이 공유할 수 있습니다. 사용자의 신원은 하나지만, 접근 방법별로 인증 경로가 다를 수 있습니다.
책임 경계의 명확화 — 장애 발생 시 “명부 문제인가, 인증 문제인가”를 분리해 진단할 수 있습니다.

설계상의 시사점은 특정 시스템이 “사용자를 보관만 하는가(디렉터리)” 아니면 “자격 증명 검증까지 수행하는가(인증)”를 명확히 구분하면, 인증 트래픽이 특정 경로로 흐르는 이유와 장애 발생 시 조치 지점을 정확히 특정할 수 있습니다. 토큰 수명, 세션 정책, 재인증 빈도와 같은 문제는 대부분 인증을 담당하는 주체 측에 원인이 있으며, 사용자 존재·그룹 소속 문제는 디렉터리(원본) 측에 원인이 있습니다.

3. 인증 프로토콜: SAML 2.0과 OpenID Connect

IdP가 인증을 수행할 때, SP와 어떤 프로토콜로 보증을 교환하는가가 SAML과 OIDC의 분기점입니다. 두 표준 모두 SSO를 구현하지만, 설계 세대와 전송 모델, 토큰 구조가 근본적으로 다릅니다.

3.1 SAML 2.0 (Security Assertion Markup Language)

XML 기반의 인증·인가 표준으로, OASIS에 의해 2005년 표준화되었습니다.
인증 결과를 SAML Assertion 이라는 XML 문서로 전달하며, Assertion은 IdP의 개인키로 XML 서명(XML-DSig) 됩니다.
전형적인 바인딩은 HTTP-POST / HTTP-Redirect 로, 브라우저를 매개로 Assertion이 전달됩니다. 즉 브라우저 프론트채널(front-channel) 중심입니다.
웹 브라우저 기반 엔터프라이즈 SSO에 최적화되어 있으나, 네이티브·모바일 애플리케이션 환경에는 구조적으로 부적합합니다.

SAML 인증 흐름 (SP-initiated, 요약)

사용자가 SP에 접근 → SP가 AuthnRequest를 생성하여 IdP로 리다이렉트
IdP가 사용자 자격 증명 검증 → 서명된 SAML Assertion 생성
브라우저가 Assertion을 SP의 ACS(Assertion Consumer Service) URL로 POST
SP가 서명을 검증하고 세션 수립

3.2 OpenID Connect (OIDC)

OAuth 2.0 인가 프레임워크 위에 구축된 인증 계층으로, 2014년 OpenID Foundation에 의해 표준화되었습니다.
토큰은 JSON Web Token(JWT) 형식이며, ID Token / Access Token / Refresh Token 세 종류로 구분됩니다.
토큰 서명은 비대칭 키로 수행되며, 검증자는 IdP의 JWKS(JSON Web Key Set) URI 에 게시된 공개키로 서명을 확인 합니다.
REST/JSON 기반의 백채널(back-channel) 토큰 교환을 사용하므로, 웹뿐 아니라 네이티브 애플리케이션·모바일·API·SPA 등 폭넓은 클라이언트 유형을 지원합니다.

OIDC Authorization Code Flow (요약)

클라이언트가 사용자를 IdP의 authorization endpoint 로 리다이렉트
사용자 인증 후 IdP가 authorization code 발급
클라이언트가 code를 token endpoint 로 전송하여 ID Token + Access Token (+ Refresh Token) 교환
클라이언트가 ID Token의 서명(JWKS 기반)과 클레임을 검증하여 세션 수립

아래 다이어그램은 네이티브/공개 클라이언트에서 권장되는 PKCE(Proof Key for Code Exchange) 적용 흐름을 함께 표시합니다. 클라이언트는 요청마다 임의의 code_verifier 를 생성하고 그 해시(code_challenge, S256)를 인가 요청에 실어 보내며, 토큰 교환 시 원본 code_verifier 를 제시하여 인가 코드 가로채기를 방지합니다.

3.3 프로토콜 비교

항목	SAML 2.0	OpenID Connect
표준화	OASIS (2005)	OpenID Foundation (2014)
기반	독립 프로토콜	OAuth 2.0
데이터 포맷	XML (Assertion)	JSON (JWT)
서명 검증	XML-DSig, 메타데이터 교환	JWKS URI 기반 공개키 검증
토큰 종류	SAML Assertion	ID / Access / Refresh Token
전송 모델	브라우저 프론트채널(POST/Redirect)	프론트채널 + 백채널 토큰 교환
세션 갱신	표준 재인증 (Refresh 개념 없음)	Refresh Token 기반 무중단 갱신
클라이언트 적합성	웹 브라우저 중심	웹 + 네이티브/모바일/API

3.4 Refresh Token: OIDC 고유의 세션 유지 메커니즘

세션이 빈번하게 만료되어 재로그인을 유발하는 문제는 대부분 Refresh Token 과 직결됩니다.

Access Token은 보안상 짧은 수명(통상 수십 분~수 시간)을 갖습니다.
OIDC는 Refresh Token 을 통해 사용자 재인증 없이 Access Token을 재발급받습니다.
이를 위해서는 클라이언트가 offline_access 스코프를 요청하고, IdP가 해당 스코프에 대해 Refresh Token을 발급하도록 구성되어야 합니다.
SAML에는 Refresh Token에 대응하는 개념이 존재하지 않습니다. SAML 세션은 IdP/SP의 세션 수명 정책에 전적으로 의존합니다.

따라서 “애플리케이션이 재로그인을 과도하게 요구한다”는 증상은, OIDC 환경에서 offline_access 미허용 또는 Refresh Token 미발급 구성이 원인인 경우가 많습니다. 이는 프로토콜 선택의 문제가 아니라 IdP 클라이언트 구성의 문제입니다.

3.5 인접 표준: OAuth 2.0과 SCIM

SAML과 OIDC가 인증 프로토콜의 두 축이지만, 이 둘만으로 신원 아키텍처가 완성되는 것은 아닙니다. 혼동하기 쉬운 두 인접 표준을 명확히 구분해 둡니다.

OAuth 2.0 — 인증이 아니라 인가(authorization)

OAuth 2.0은 자주 인증 프로토콜로 오해되지만, 본질은 인가(authorization) 위임 표준입니다. 즉 “이 사용자가 누구인가”가 아니라 “이 클라이언트가 특정 리소스에 접근할 권한을 위임받았는가”를 다룹니다. 발급물은 Access Token 이며, 그 자체로는 사용자의 신원을 보증하지 않습니다.

OIDC는 바로 이 OAuth 2.0 위에 “인증 계층”을 추가한 것입니다. OIDC는 OAuth 2.0의 인가 흐름을 재사용하되, 사용자 신원을 담은 ID Token(JWT) 을 추가로 발급하여 인증 기능을 제공합니다. 따라서 다음 구분이 핵심입니다.

OAuth 2.0 = 인가 (무엇에 접근 가능한가)
OIDC = 인증 (누구인가) — OAuth 2.0을 기반으로 구축

이 구분을 혼동하면 “OAuth로 로그인을 구현했다”는 흔한 오설계(ID Token 없이 Access Token만으로 사용자를 식별하는 안티패턴)로 이어집니다.

SCIM — 인증이 아니라 프로비저닝(provisioning)

SCIM(System for Cross-domain Identity Management) 은 인증이 아니라 사용자·그룹의 생성·갱신·삭제를 자동화하는 프로비저닝 표준입니다. SAML/OIDC가 “로그인 시점에 누구인지 보증”하는 런타임 프로토콜이라면, SCIM은 “로그인 이전에 누구를 명부에 등록/해지할지”를 다루는 수명주기(lifecycle) 프로토콜입니다.

이는 2절에서 구분한 디렉터리(명부) 책임 과 정확히 대응합니다. IdP의 사용자 변경(입사·퇴사·그룹 이동)을 하위 애플리케이션의 디렉터리에 자동 반영하는 역할을 SCIM이 담당합니다.

정리: SAML·OIDC는 인증(runtime), SCIM은 프로비저닝(lifecycle), OAuth 2.0은 인가(authorization) 를 담당합니다. 세 가지는 상호 보완적이며 대체 관계가 아닙니다. 실제 엔터프라이즈 구성에서는 흔히 “OIDC/SAML로 인증 + SCIM으로 프로비저닝”이 함께 쓰입니다.

4. 모든 IdP가 모든 프로토콜·흐름을 지원하지는 않는다 — AWS IAM Identity Center

실무에서 반복되는 오해는 “IdP이므로 모든 인증 방식을 지원할 것”이라는 가정입니다. 그러나 IdP마다 지원 프로토콜의 범위, 지원하는 OAuth/OIDC grant 유형, 설계 목적이 상이합니다. AWS IAM Identity Center(IdC) 를 예로 이를 설명 합니다.

4.1 IdC는 자체 인증을 수행한다

IdC의 identity source를 Identity Center directory 로 구성하면, IdC가 사용자·비밀번호·MFA를 직접 관리하고 인증을 수행하는 완결적 IdP 로 동작합니다. 반대로 identity source를 외부 IdP(SAML federation) 로 지정하면, 인증을 외부 SSO에 위임하고 IdC는 페더레이션 중계 및 디렉터리 역할에 집중합니다.

즉 “IdC가 자체 인증을 하지 못한다”는 명제는 성립하지 않습니다. 이는 구성상의 선택이지 기능적 한계가 아닙니다.

4.2 범용 IdP와의 결정적 차이: 지원하는 grant 유형

항목	Okta / Entra ID (범용 IdP)	AWS IAM Identity Center
SAML 2.0 IdP	지원	지원
OIDC — 임의의 서드파티 클라이언트	지원	범용 제공하지 않음
OIDC Authorization Code + PKCE	지원	AWS 관리형 앱에 한해 지원(2024-05~)
OIDC Device Authorization Grant (RFC 8628)	지원	지원
SAML 2.0 customer managed app 호스팅	지원	인스턴스 유형에 따라 다름 (※)
설계 목적	임의의 서드파티 애플리케이션을 위한 범용 IdP	AWS 계정 및 AWS 관리형 애플리케이션 접근에 특화

※ IdC는 인스턴스 유형이 두 가지입니다. SAML 2.0 customer managed application은 organization instance에 연결되며, permission set 또한 organization instance를 전제로 합니다. 반면 Account instance(단일 AWS 계정에 바인딩되는 인스턴스)는 샌드박스 성격의 AWS 관리형 애플리케이션을 위한 것으로, permission set을 지원하지 않고 SAML 2.0 customer managed application 호스팅 대상도 아닙니다. 따라서 멤버 계정의 account instance에 외부 IdP를 SAML로 페더레이션하는 구성은 권한(SCP·티켓) 문제가 아니라 인스턴스 유형 자체의 구조적 제약에 가깝습니다. 위 표의 “지원” 표기는 organization instance 기준입니다. (인스턴스 유형별 지원 범위는 변경될 수 있으므로 적용 전 최신 공식 문서 확인을 권장합니다.)

핵심 분석: IdC는 자체 인증 능력을 보유하되, 그 설계 목적이 AWS 리소스 접근 통제에 특화되어 있습니다. 여기서 주의할 점은, IdC가 2024년 5월부터 PKCE 기반 Authorization Code flow를 지원한다는 사실입니다. 다만 이 PKCE 지원은 AWS 관리형 애플리케이션(예: Amazon Q Developer Pro) 이 IdC를 통해 사용자를 인증하도록 하기 위한 것으로, 임의의 서드파티 OIDC 클라이언트가 IdC를 범용 OIDC 공급자로 사용할 수 있게 개방된 것은 아닙니다.

즉 “IdC가 PKCE를 전혀 지원하지 않는다”는 서술은 정확하지 않으며, 정확한 표현은 “IdC는 AWS 관리형 앱 범위에서 PKCE를 지원하되, 외부의 범용 OIDC 클라이언트를 위한 공개 OIDC 공급자(authorization server)로서는 제공되지 않는다” 입니다. 역사적으로 IdC의 OIDC 엔드포인트는 CLI SSO를 위한 Device Authorization Grant(RFC 8628) 구현에서 출발했으며, 서드파티 네이티브 애플리케이션이 IdC를 직접 OIDC IdP로 지정하는 용도로는 설계되지 않았습니다. 이 구분이 네이티브 애플리케이션(예: Quick 데스크톱) 연동 시 결정적 제약으로 작용합니다.

5. 사례 분석: Amazon Quick 데스크톱 애플리케이션 연동

위 개념들이 실제 아키텍처에서 어떻게 연결 되는지를 Amazon Quick 데스크톱 연동 사례로 검증합니다.

5.1 현상

Amazon Quick 웹은 IdC(및 그 상위의 기업 SSO)를 통해 정상적으로 인증됩니다.
그러나 Amazon Quick 데스크톱(네이티브) 애플리케이션 의 엔터프라이즈 로그인에서 제약이 발생합니다.

5.2 원인 분석

Quick 데스크톱은 네이티브 애플리케이션이므로, 공개 클라이언트(public client)에 안전한 OIDC Authorization Code Flow with PKCE(Proof Key for Code Exchange, RFC 7636) 를 요구합니다. PKCE는 클라이언트 시크릿을 안전하게 보관할 수 없는 네이티브/모바일 환경에서 인가 코드 가로채기(authorization code interception) 공격을 방지하기 위한 표준 확장입니다.
해당 환경은 기업 자체 SSO를 SAML 2.0 으로 IdC에 페더레이션한 구성이었습니다. SAML은 네이티브 앱의 OIDC Auth Code + PKCE 요구를 직접 충족할 수 없습니다.
IdC 자체의 OIDC 지원 역시 Device Authorization Grant 중심이어서, 데스크톱이 요구하는 Authorization Code + PKCE 흐름을 직접 제공하지 못합니다.

5.3 귀결되는 아키텍처

구분	인증 경로
Quick 웹	IdC → (상위) SAML 기업 SSO. 정상 동작
Quick 데스크톱	OIDC(Authorization Code + PKCE) IdP 필수. SAML/IdC 단독으로는 불가

따라서 데스크톱용으로 OIDC 호환 IdP(Entra ID, Okta, Ping 등) 를 별도 연결하거나, 그러한 IdP가 부재한 경우 Amazon Cognito를 OIDC 공급자(브릿지) 로 구성하는 별도 인증 경로가 요구됩니다. 이 구성에서 디렉터리(사용자 명부)는 IdC가 유지하되, 데스크톱의 런타임 인증은 Cognito가 담당하는 책임 분리 구조가 성립합니다.

5.4 세션 수명 및 Refresh Token 관점

외부 IdP가 IdC에 페더레이션된 구성에서, AWS access portal 세션의 실제 수명은 IdC 콘솔 설정값과 외부 IdP 설정값 중 더 짧은 값으로 적용됩니다. 또한 데스크톱(OIDC) 세션은 Refresh Token을 통해 유지되므로, 재인증이 빈번하다면 다음을 우선 점검해야 합니다.

OIDC 클라이언트가 offline_access 스코프를 요청/허용받는가
IdP가 해당 클라이언트에 대해 Refresh Token을 발급하는가 (grant_types_supported에 refresh_token 포함 여부)
Access Token 및 IdP 세션의 수명 정책

6. 요약

IdP 는 신원을 검증하고 그 결과를 SP에 보증하는 SSO의 신뢰 중심점입니다.
IdP의 책임은 디렉터리(명부) 와 인증(authentication) 으로 분리되며, 단일 제품이 통합하거나 페더레이션으로 분담할 수 있습니다. 세션·토큰 문제의 원인은 대개 인증 주체 측에 있습니다.
인증 프로토콜은 SAML 2.0(XML, 브라우저 프론트채널, 웹 중심)과 OIDC(JWT, OAuth 2.0 기반, 네이티브/모바일 포함)로 대별됩니다.
Refresh Token은 OIDC 고유의 메커니즘 이며, 재인증 빈도 문제는 offline_access 및 Refresh Token 발급 구성과 직결됩니다.
IdP의 프로토콜 지원 범위는 균일하지 않습니다. AWS IdC는 자체 인증을 수행하되 OIDC Authorization Code + PKCE를 범용 지원하지 않아, 네이티브 애플리케이션(예: Quick 데스크톱) 연동 시 별도 OIDC 경로(외부 IdP 또는 Cognito 브릿지)가 요구됩니다.

설계 원칙: 애플리케이션을 SSO에 통합할 때는 (1) 해당 애플리케이션이 요구하는 인증 방식과 흐름(SAML/OIDC, Authorization Code + PKCE 등)과 (2) 보유 IdP의 해당 흐름 지원 여부 를 먼저 정합(alignment)시켜야 합니다. 양자가 불일치하면 브릿지 컴포넌트(예: Amazon Cognito)를 통한 프로토콜 중계가 필요합니다.

부록: Authentication, Authorization, Authority — 혼동하기 쉬운 세 개념

세 용어 모두 auth-로 시작하여 혼용되기 쉬우나, 신원 아키텍처에서는 명확히 구분되는 서로 다른 개념입니다.

개념	질문	다루는 것	대표 프로토콜/구성 요소
Authentication (인증)	“당신은 누구인가?”	신원의 검증	SAML, OIDC
Authorization (인가)	“당신은 무엇을 할 수 있는가?”	권한의 부여·위임	OAuth 2.0, 역할/정책
Authority (권위/신뢰 주체)	“누가 그것을 보증하는가?”	신뢰의 원천	IdP, Authorization Server, CA

Authentication (인증)

사용자가 주장하는 신원이 사실인지 검증하는 과정입니다. 비밀번호, MFA, 생체 정보 등으로 “이 요청자가 정말 그 사람인가”를 확인합니다. 결과물은 신원을 보증하는 증명(OIDC의 ID Token, SAML의 Assertion)입니다.

핵심 질문: “Who are you?”
예: 사용자가 IdP 로그인 화면에서 자격 증명과 MFA를 제출하여 신원을 증명

Authorization (인가)

인증이 끝난(또는 위임받은) 주체가 특정 리소스나 작업에 대한 권한을 가지는지 결정하는 과정입니다. “이 사람이 누구인가”와 별개로, “이 사람/클라이언트가 무엇에 접근할 수 있는가”를 다룹니다.

핵심 질문: “What are you allowed to do?”
예: OAuth 2.0 Access Token이 특정 스코프(scope)에 한해 리소스 접근을 허용, 또는 역할(role)·정책(policy)에 따라 권한을 제한

흔한 혼동: 인증과 인가는 순차적이지만 별개입니다. “로그인에 성공했다(인증)”는 것이 “모든 리소스에 접근 가능하다(인가)”를 의미하지 않습니다. OAuth 2.0은 인가 전용이며, 그 위에 인증 계층을 더한 것이 OIDC입니다.

Authority (권위 / 신뢰 주체)

인증과 인가의 결과를 보증하는 신뢰의 원천(source of trust) 입니다. “누가 이 신원·권한을 책임지고 서명했는가”에 대한 답이며, 서비스 공급자(SP)는 이 Authority가 발급·서명한 증명만을 신뢰합니다.

핵심 질문: “Who vouches for it?”
예: IdP 는 인증 결과를 서명하는 Authority이고, OAuth 2.0 Authorization Server 는 토큰을 발급하는 Authority이며, TLS 인증서 세계에서는 CA(Certificate Authority) 가 이에 해당합니다.

세 개념의 연결: 사용자가 Authority(IdP) 에 의해 Authentication(인증) 되고, 그 결과를 바탕으로 리소스에 대한 Authorization(인가) 을 획득합니다. 본문에서 반복된 “IdC가 디렉터리인가 인증 주체인가”라는 질문은 결국 “IdC가 어떤 Authority 역할을 맡는가” 를 묻는 것이며, 세션·토큰 문제는 Authentication, 접근 권한 문제는 Authorization, 신뢰 관계 문제는 Authority 계층에서 각각 원인을 찾아야 합니다.

용어 정리

약어	정식 명칭
IdP	Identity Provider (신원 공급자)
SP	Service Provider (서비스 공급자)
SSO	Single Sign-On
SAML	Security Assertion Markup Language
OIDC	OpenID Connect
JWT	JSON Web Token
JWKS	JSON Web Key Set
PKCE	Proof Key for Code Exchange (RFC 7636)
MFA	Multi-Factor Authentication
IdC	AWS IAM Identity Center
CA	Certificate Authority (인증 기관)