OIDC편집자 확인

OIDC는 OAuth 2.0 프레임워크 위에 구축된 인증 계층이다. OAuth 2.0은 권한 부여를 위한 표준 프로토콜로, 클라이언트 애플리케이션이 사용자의 동의 하에 제한된 범위의 리소스에 접근할 수 있도록 액세스 토큰을 발급하는 데 중점을 둔다. 그러나 OAuth 2.0 자체는 사용자가 누구인지 확인하는 표준화된 방법을 제공하지 않는다. 이로 인해 애플리케이션은 종종 액세스 토큰을 받은 후 별도의 API 호출을 통해 사용자 정보를 조회해야 했다.

OIDC는 이러한 OAuth 2.0의 한계를 해결하기 위해 설계되었다. OIDC는 OAuth 2.0의 인가 코드 흐름 같은 기존 흐름을 그대로 사용하면서, ID 토큰이라는 새로운 개념을 도입한다. ID 토큰은 JWT 형식으로 인코딩되며, 사용자의 신원을 직접적으로 증명하는 정보를 담고 있다. 따라서 OIDC는 OAuth 2.0이 제공하는 '리소스 접근 권한 부여' 기능에 '사용자 인증 정보 제공' 기능을 추가한 확장판으로 볼 수 있다.

두 프로토콜의 관계를 표로 정리하면 다음과 같다.

요약하면, OIDC는 OAuth 2.0을 기반으로 하여 호환성을 유지하면서 인증이라는 명확한 목적을 위해 필요한 구성 요소를 표준화한 프로토콜이다. 현대 애플리케이션은 OAuth 2.0을 통해 API 접근 권한을 관리하고, OIDC를 통해 사용자 로그인 상태를 확인하는 방식으로 두 기술을 함께 사용한다.

ID 토큰은 JSON Web Token 형식으로 인코딩된 문자열이다. 이 토큰은 클레임의 집합으로 구성되며, 사용자의 인증 이벤트에 대한 정보를 담고 있다. ID 토큰의 주요 목적은 Relying Party에게 사용자가 OpenID Provider에 의해 성공적으로 인증되었음을 안전하게 전달하는 것이다. 따라서 ID 토큰은 권한 부여를 위한 액세스 토큰과는 그 역할이 명확히 구분된다.

토큰의 구조는 헤더, 페이로드, 서명의 세 부분으로 나뉜다. 헤더에는 서명 알고리즘과 토큰 유형 같은 메타데이터가 포함된다. 페이로드는 사용자에 대한 클레임을 담는 핵심 부분이다. 필수 클레임으로는 토큰 발행자(iss), 대상 수신자(aud), 만료 시간(exp), 발행 시간(iat), 그리고 주체 식별자(sub)가 있다. 선택적 클레임으로는 인증 시간(auth_time)이나 인증 방법 참조(amr) 등이 포함될 수 있다.

표준화된 클레임 집합은 상호운용성을 보장한다. 예를 들어, sub 클레임은 해당 발행자(iss) 내에서 사용자를 고유하게 식별하는 값을 가지며, 이 조합은 서로 다른 시스템 간에 동일한 사용자를 안정적으로 참조하는 데 사용된다. nonce 클레임은 재전송 공격을 방지하기 위해 중요한 역할을 한다. RP가 인증 요청 시 전달한 임의의 문자열이 토큰에 포함되어, 응답이 원래 요청에 대한 것임을 검증할 수 있게 한다.

ID 토큰은 항상 JWS 서명되거나 JWE 암호화되어 전달된다. 이를 통해 토큰의 무결성과 출처를 검증할 수 있으며, 민감한 클레임 정보를 보호할 수 있다. RP는 공개된 JWK 세트를 사용하여 서명을 검증하고, 토큰의 iss와 aud 클레임이 예상된 값과 일치하는지 반드시 확인해야 한다. 이 과정을 통해 RP는 토큰이 신뢰할 수 있는 OP로부터 의도된 자신에게 발행되었음을 확신할 수 있다.

OpenID Provider는 OIDC 프로토콜의 핵심 구성 요소로, 인증 서비스를 제공하고 ID 토큰을 발급하는 신뢰할 수 있는 서버이다. 사용자의 신원을 확인하고, Relying Party에게 해당 사용자의 인증 상태와 기본적인 프로필 정보를 안전하게 전달하는 역할을 담당한다. OP는 종종 인증 서버 또는 신원 공급자라고도 불린다.

OP의 주요 기능은 다음과 같다.

OP는 OAuth 2.0의 Authorization Server 역할을 확장하여 구축된다. 따라서 OAuth 2.0의 모든 기능을 지원하면서, 추가적으로 JWT 형식의 서명된 ID 토큰을 생성하고 검증하는 능력을 갖춘다. OP의 정확한 설정과 공개 키 정보는 일반적으로 .well-known/openid-configuration 엔드포인트를 통해 자동으로 발견될 수 있다[1]. Google, Microsoft, Naver, Kakao 등의 주요 플랫폼이 대표적인 OP의 사례이다.

Relying Party (RP)는 OIDC 프로토콜에서 인증을 의뢰하는 애플리케이션 또는 서비스를 의미한다. 신뢰 당사자라고도 불리며, 최종 목표는 사용자의 신원을 확인하고 그 정보를 바탕으로 접근을 제어하거나 맞춤형 서비스를 제공하는 것이다. RP는 OpenID Provider (OP)에게 사용자 인증을 위임하고, 그 결과로 받은 ID 토큰을 검증하여 신원 정보를 확보한다.

RP의 주요 역할은 OAuth 2.0의 클라이언트 역할을 확장한 것으로, 인증 과정을 시작하고 완료하는 주체이다. 구체적인 임무는 다음과 같다.

* 사용자를 OP의 인증 엔드포인트로 리디렉션하여 인증 요청을 시작한다.

* OP로부터 발급받은 인증 코드 또는 ID 토큰을 정해진 규칙에 따라 수신한다.

* 수신한 ID 토큰의 서명을 검증하고, 발급자(iss), 대상자(aud), 만료 시간(exp) 등의 클레임을 확인하여 토큰의 유효성을 판단한다.

* 검증이 완료된 토큰에서 사용자 식별자(sub)나 프로필 정보(이름, 이메일 등)를 추출하여 애플리케이션 내부 세션을 생성하거나 자원 접근을 허가한다.

RP는 사전에 OP에 클라이언트로 등록되어야 하며, 이 과정에서 고유한 client_id와 client_secret을 발급받는다. 또한, 토큰을 수신할 리디렉션 URI(Redirect URI)를 등록하여 보안을 강화한다. RP의 종류는 OAuth 2.0 클라이언트 유형에 따라 퍼블릭 클라이언트(모바일 앱, 단일 페이지 애플리케이션)와 컨피덴셜 클라이언트(서버 기반 웹 애플리케이션)로 구분되며, 각 유형에 맞는 인증 흐름을 선택하여 구현해야 한다.

사용자는 OIDC 프로토콜에서 자신의 신원 정보(인증)를 제공받고자 하는 주체이다. 일반적으로 최종 사용자(End-User)를 지칭하며, Relying Party가 제공하는 서비스나 애플리케이션을 이용하는 개인이다. 사용자의 주요 역할은 OpenID Provider에게 자신의 신원을 인증받고, 그 결과인 ID 토큰을 Relying Party에게 안전하게 전달하는 동의를 제공하는 것이다.

인증 과정에서 사용자는 OpenID Provider의 로그인 페이지로 리디렉션되어 자격 증명(예: 아이디, 비밀번호, 다중 인자 인증)을 입력한다. 성공적으로 인증된 후, 사용자는 Relying Party가 요청한 사용자 정보(예: 이메일, 이름, 프로필 사진)에 대한 접근 권한을 허용하거나 거부할 수 있다. 이 동의 단계는 OAuth 2.0의 권한 부여 프레임워크를 기반으로 한다.

사용자 경험과 프라이버시는 중요한 고려 사항이다. OIDC는 선택적 클레임과 범위(scope)를 통해 사용자가 제공하는 정보의 양을 제어할 수 있게 한다. 예를 들어, openid 범위는 필수이지만, profile이나 email 범위는 애플리케이션이 요청하고 사용자가 동의해야만 제공된다.

Authorization Code Flow는 OIDC와 그 기반이 되는 OAuth 2.0에서 가장 일반적이고 안전한 권한 부여 방식으로 권장된다. 이 흐름은 클라이언트가 사용자 에이전트(일반적으로 웹 브라우저)를 통해 OpenID Provider (OP)의 인증 엔드포인트로 리디렉션하여 인증을 시작한다. 사용자가 로그인하고 필요한 권한에 동의하면, OP는 인가 코드를 클라이언트로 다시 전송한다. 이 코드는 백채널(서버 대 서버 통신)을 통해 액세스 토큰과 ID 토큰을 교환하는 데 사용된다.

이 흐름의 주요 단계는 다음과 같다.

이 흐름의 핵심 보안 장점은 민감한 토큰(특히 액세스 토큰과 ID 토큰)이 사용자 에이전트를 직접 통과하지 않는다는 점이다. 토큰은 오직 백채널을 통해 RP와 OP 사이에서만 교환된다. 이는 토큰이 브라우저 히스토리나 로그 파일에 노출될 위험을 크게 줄여준다. 또한, 클라이언트 비밀키를 사용한 인가 코드 교환 단계는 요청이 인가된 RP에서 왔음을 OP가 확인할 수 있게 한다.

따라서 이 흐름은 서버 기반의 전통적인 웹 애플리케이션에 가장 적합하며, 모바일 애플리케이션이나 싱글 페이지 애플리케이션에서도 추가적인 보안 조치(예: PKCE 확장 사용)와 함께 널리 채택된다. OAuth 2.0 보안 모범 사례와 OIDC 코어 명세서는 클라이언트가 백채널을 안전하게 유지할 수 있을 때 이 흐름의 사용을 권장한다.

Implicit Flow는 OIDC와 OAuth 2.0에서 정의된 인증 및 권한 부여 흐름 중 하나이다. 이 흐름은 주로 클라이언트 측 자바스크립트 애플리케이션과 같이 클라이언트 시크릿을 안전하게 저장할 수 없는 공개 클라이언트를 위해 설계되었다. Implicit Flow의 가장 큰 특징은 인증 코드를 교환하는 단계 없이, 인증 서버로부터 직접 액세스 토큰과 ID 토큰을 리디렉션 URI를 통해 전달받는다는 점이다.

이 흐름의 단계는 다음과 같이 요약할 수 있다.

1. Relying Party (RP)는 사용자를 OpenID Provider (OP)의 인증 엔드포인트로 리디렉션한다. 이때 response_type 매개변수에 id_token token 또는 token을 지정하여 토큰을 직접 요청한다.

2. 사용자는 OP에서 인증을 완료하고 권한을 부여한다.

3. OP는 요청된 토큰(액세스 토큰 및/또는 ID 토큰)을 URL 프래그먼트(#)에 담아 RP의 리디렉션 URI로 사용자를 돌려보낸다.

4. RP의 클라이언트 측 코드(예: 자바스크립트)는 URL 프래그먼트에서 토큰을 추출하여 사용한다.

현대의 보안 권고사항에서는 Implicit Flow의 사용을 점차 권장하지 않는 추세이다. 특히 액세스 토큰이 브라우저 환경에 직접 노출되어 재전송 공격 등에 취약할 수 있다는 점이 주요 문제로 지적된다. 이를 대체하기 위해 Authorization Code Flow에 PKCE(Proof Key for Code Exchange) 확장을 적용하는 방식이 공개 클라이언트를 위한 더 안전한 대안으로 제시된다. OAuth 2.1 명세 초안에서는 보안상의 이유로 Implicit Flow를 완전히 제외하기도 했다[2].

Hybrid Flow는 Authorization Code Flow의 보안성과 Implicit Flow의 즉시성(토큰이 프론트채널을 통해 즉시 반환됨)을 결합한 인증 방식이다. 이 흐름은 ID 토큰과 인가 코드를 동시에 또는 선택적으로 반환받아, 클라이언트 유형과 요구 보안 수준에 따라 유연하게 사용할 수 있다.

주요 응답 유형(response_type)으로는 code id_token, code token, code id_token token 등이 있다. 예를 들어, code id_token을 사용하면 인가 코드와 ID 토큰이 인증 응답으로 함께 반환된다. 이때 ID 토큰은 사용자 정보를 즉시 확인하는 데 사용되고, 인가 코드는 백채널을 통해 액세스 토큰을 안전하게 교환하는 데 사용된다.

이 방식은 특히 SPA나 모바일 앱과 같이 클라이언트가 공개된 환경에서 유용하다. ID 토큰을 통해 프론트엔드에서 즉시 사용자 인증 상태를 확인할 수 있으면서도, 민감한 액세스 토큰은 백채널 요청을 통해 안전하게 획득할 수 있기 때문이다. 또한, 인가 코드를 ID 토큰에 포함시켜 전달함으로써 재전송 공격을 방지하는 추가적인 보안 이점을 제공한다[3].

다음은 Hybrid Flow의 일반적인 단계를 요약한 표이다.

OIDC의 핵심 보안 요소는 ID 토큰과 액세스 토큰을 안전하게 관리하는 것이다. ID 토큰은 JWT 형식으로 구성되며, 서명을 통해 변조를 방지한다. 서명 알고리즘으로는 RS256과 같은 비대칭 키 방식을 권장하며, 토큰 수신 측(Relying Party)은 반드시 OpenID Provider의 공개 키를 사용하여 서명을 검증해야 한다. 액세스 토큰은 민감한 사용자 데이터에 접근하는 데 사용되므로, 전송 및 저장 시 HTTPS를 통한 암호화가 필수적이다.

토큰의 수명을 최소화하는 것이 중요하다. 짧은 유효 기간을 설정하고, 리프레시 토큰을 사용하여 새로운 액세스 토큰을 발급받는 방식을 적용한다. 리프레시 토큰은 더 높은 보안 수준으로 보호되어야 하며, 클라이언트 자격 증명과 함께 안전하게 저장된다. 토큰이 예상치 못한 경로나 클라이언트로 전송되는 것을 방지하기 위해, 토큰 발급 시 aud(대상자) 클레임을 명시적으로 지정하고 수신 측에서 이를 검증해야 한다.

클라이언트 애플리케이션은 발급받은 토큰을 안전하게 저장해야 한다. 웹 애플리케이션의 경우 HttpOnly 및 Secure 플래그가 설정된 쿠키에 저장하는 것이 일반적이며, 모바일 앱은 운영체제가 제공하는 안전한 저장소를 활용해야 한다. 토큰이 더 이상 필요하지 않을 경우, OpenID Provider에 제공된 토큰 철회 엔드포인트를 통해 명시적으로 토큰을 무효화하는 것이 좋다.

재전송 공격은 인증 요청을 공격자가 가로채어 다른 세션에서 재사용하는 공격 방식이다. OIDC는 이러한 공격을 방지하기 위해 nonce와 state 매개변수를 핵심적인 수단으로 활용한다.

nonce는 ID 토큰에 포함되는 임의의 문자열 값이다. Relying Party는 인증 요청 시 nonce 값을 생성하여 OpenID Provider에 전달한다. Provider는 이 값을 ID 토큰의 nonce 클레임에 그대로 포함시켜 발급한다. RP는 수신한 ID 토큰의 nonce 값이 자신이 보낸 원본 요청의 값과 일치하는지 반드시 검증해야 한다. 이 과정을 통해 토큰이 특정 인증 요청에 대해 정상적으로 발급된 것임을 보장하고, 중간에서 가로채인 토큰의 재사용을 효과적으로 차단한다.

state 매개변수는 주로 교차 사이트 요청 위조 공격을 방지하고 사용자 세션 상태를 유지하는 데 사용된다. RP는 인증 요청을 시작할 때 임의의 state 값을 생성하여 Provider로 보낸다. Provider는 인증 응답(보통 인가 코드와 함께)에 이 state 값을 그대로 담아 돌려보낸다. RP는 응답에 포함된 state 값이 자신이 생성하여 보낸 값과 일치하는지 검증해야 한다. 이 검증이 실패하면 해당 응답을 처리하지 않고 버린다. 아래 표는 두 매개변수의 주요 목적과 역할을 비교한 것이다.

이러한 매커니즘은 표준화된 필수 보안 조치로 간주된다. 모든 OIDC 호환 RP 구현체는 nonce와 state를 적절히 생성, 전달, 검증하는 로직을 포함해야 한다. 특히 암시적 흐름이나 하이브리드 흐름과 같이 ID 토큰이 프론트채널을 통해 직접 전달되는 경우, nonce 검증은 재전송 공격에 대한 가장 기본적이고 필수적인 방어 수단이 된다.

Discovery는 OpenID Connect에서 OpenID Provider의 구성 정보와 지원하는 기능을 동적으로 조회하기 위한 표준화된 메커니즘이다. 이는 클라이언트 애플리케이션이 서버의 엔드포인트 URL, 지원하는 인증 방식, 서명 알고리즘 등 필수 정보를 하드코딩하지 않고도 자동으로 획득할 수 있게 한다. Discovery의 핵심은 Well-Known URI 경로(/.well-known/openid-configuration)를 통해 제공되는 JSON 형식의 구성 문서이다. 이 문서는 OIDC 인증 요청을 구성하는 데 필요한 모든 메타데이터를 포함한다.

구성 문서에는 다음과 같은 주요 정보가 명시된다.

이 메커니즘은 배포와 유지보수를 단순화한다. 예를 들어, OpenID Provider가 새로운 서명 알고리즘을 추가하거나 엔드포인트 URL을 변경할 때, 모든 Relying Party가 클라이언트 구성을 수동으로 업데이트할 필요가 없다. 각 클라이언트는 인증 흐름을 시작할 때 구성 문서를 조회하여 최신 정보를 사용한다. 이는 분산 환경과 다중 테넌트 시스템에서 특히 유용하다.

Discovery는 OIDC의 상호운용성을 보장하는 기반이 된다. 서로 다른 벤더의 OP와 RP가 사전 합의 없이도 표준화된 방식으로 연결 정보를 교환할 수 있게 한다. 이는 싱글 사인온과 연합 인증 시나리오에서 광범위한 채택을 가능하게 한 핵심 기능 중 하나이다.

Dynamic Client Registration은 OIDC와 OAuth 2.0에서 클라이언트 애플리케이션이 OpenID Provider에 자신의 구성 정보를 자동으로 등록할 수 있도록 하는 프로토콜 확장이다. 이 메커니즘은 클라이언트의 사전 등록 단계를 간소화하여 배포와 관리를 용이하게 한다. 전통적인 방식에서는 개발자가 OpenID Provider의 관리 콘솔에 수동으로 접속해 client_id, redirect_uri 등을 등록해야 했지만, Dynamic Client Registration을 통해 이 과정을 자동화된 API 호출로 대체할 수 있다.

등록 프로세스는 일반적으로 Relying Party가 OP의 등록 엔드포인트(/register)에 HTTP POST 요청을 보내는 것으로 시작한다. 요청에는 클라이언트의 메타데이터가 JSON 형식으로 포함된다. OP는 이 요청을 검증한 후 고유한 client_id와 종종 client_secret을 발급하여 응답한다. 등록 요청에 포함될 수 있는 주요 메타데이터는 다음과 같다.

이 방식은 특히 다중 테넌트 SaaS 애플리케이션이나 새로운 클라이언트 인스턴스가 빈번하게 생성되는 환경에서 유용하다. 각 테넌트나 인스턴스가 별도의 클라이언트 등록을 필요로 할 때, 수동 개입 없이 프로그래밍 방식으로 구성이 가능해진다. 또한, 등록 시점에 클라이언트의 기능(지원하는 승인 타입, 암호화 알고리즘 등)을 명시적으로 선언함으로써 보안 정책을 더 세밀하게 적용할 수 있다.

보안을 위해 등록 프로세스는 인증 없이도 수행될 수 있지만, 이는 등록된 클라이언트의 권한을 제한하는 경우가 많다. 일부 OP는 등록 요청에 초기 액세스 토큰을 요구하거나, 등록 후 클라이언트 구성 정보를 안전하게 업데이트하거나 회수할 수 있는 기능을 제공한다. 이 표준은 클라이언트 구성 정보의 유효성을 지속적으로 관리하고, 필요시 등록을 취소할 수 있는 메커니즘도 포함한다[5].

OIDC는 싱글 사인온 구현을 위한 현대적인 표준 프로토콜로 널리 채택된다. OIDC 기반 SSO는 사용자가 한 번의 로그인으로 여러 애플리케이션 또는 웹사이트에 접근할 수 있도록 한다. 이는 중앙 집중식 OpenID Provider가 사용자의 신원을 인증하고, 그 증거를 ID 토큰 형태로 각 애플리케이션(Relying Party)에 제공하는 방식으로 작동한다. 사용자는 복잡한 비밀번호를 여러 개 관리할 필요가 없어지고, 조직은 사용자 계정과 인증 정책을 통합적으로 관리할 수 있어 보안과 편의성을 동시에 향상시킨다.

기업 환경이나 교육 포털, 정부 서비스와 같이 여러 내부 시스템을 운영하는 곳에서 OIDC SSO는 특히 효과적이다. 예를 들어, 직원이 회사의 인증 포털에 로그인하면, 별도의 로그인 없도 CRM 시스템, 메일, 문서 저장소 등에 자동으로 접근 권한을 부여받을 수 있다. 이 과정에서 각 애플리케이션은 사용자의 개인 데이터 전체를 받는 대신, 필요한 최소한의 정보(예: 이메일, 이름)만 클레임 형태로 ID 토큰을 통해 안전하게 전달받는다.

OIDC SSO의 주요 이점은 다음과 같이 정리할 수 있다.

SAML 같은 이전 SSO 프로토콜에 비해, OIDC는 JSON과 RESTful API를 기반으로 하여 모바일 애플리케이션, SPA와 같은 현대적인 아키텍처에 더 가볍고 쉽게 통합될 수 있다. 또한 OAuth 2.0 인가 프레임워크를 그대로 사용하기 때문에, 인증과 더불어 API에 대한 접근 권한 위임도 동일한 흐름 내에서 처리할 수 있다는 장점이 있다.

모바일 애플리케이션은 네이티브 앱과 모바일 웹의 형태로 존재하며, OIDC는 이러한 환경에 적합한 인증 및 사용자 정보 제공 메커니즘을 정의합니다. OAuth 2.0만으로는 사용자 신원 확인이 명시적이지 않다는 한계가 있었으나, OIDC의 ID 토큰은 JWT 형식으로 표준화된 사용자 클레임을 포함하여 이를 해결합니다. 모바일 앱은 종종 외부 인증 서버(OP)를 통해 로그인을 위임하는 구조를 가지므로, OIDC의 표준화된 엔드포인트와 프로토콜이 광범위한 호환성을 보장합니다.

모바일 환경에서는 보안과 사용자 경험이 중요한 요소입니다. OIDC는 모바일 클라이언트에 적합한 여러 인증 흐름을 지원합니다. 특히, Authorization Code Flow with PKCE(Proof Key for Code Exchange)는 공용 클라이언트(모바일 앱)에 대한 보안 강화를 위해 설계된 표준 방식으로, 권한 부여 코드를 가로채는 공격을 방지합니다. 네이티브 앱은 내장 웹뷰나 시스템 브라우저를 통해 인증을 수행할 수 있으며, OIDC Discovery를 통해 OP의 설정을 동적으로 얻어 안정적으로 연결할 수 있습니다.

아래 표는 모바일 애플리케이션 유형별 OIDC 구현 특징을 요약한 것입니다.

이러한 구현을 통해 모바일 앱은 사용자에게 별도의 비밀번호 입력 부담을 줄이면서도, Google, Facebook, 기업 IdP 등 다양한 OpenID Provider를 통한 편리한 싱글 사인온 경험을 제공할 수 있습니다. 또한, 표준화된 사용자 정보(프로필 클레임)는 앱 내 개인화된 서비스를 구성하는 데 활용됩니다.

SAML과 OIDC는 모두 인증과 권한 부여를 위한 표준 프로토콜이지만, 설계 철학과 기술적 접근 방식에서 뚜렷한 차이를 보인다. SAML은 주로 엔터프라이즈 환경과 페더레이션 싱글 사인온을 위해 설계된 XML 기반의 오래된 표준이다. 반면, OIDC는 모바일 애플리케이션, 단일 페이지 애플리케이션 및 현대적인 웹 API와 같은 현대적 사용 사례에 맞춰 설계된 JSON과 REST API를 중심으로 한 더 간단하고 경량화된 프로토콜이다.

두 프로토콜의 주요 차이점은 다음과 같이 표로 정리할 수 있다.

SAML은 강력한 보안과 복잡한 페더레이션 신뢰 관계를 수립하는 데 강점이 있지만, 구현과 디버깅이 복잡하다는 단점이 있다. OIDC는 개발자 친화적인 API와 간단한 통합 과정을 제공하며, JWT의 경량성 덕분에 성능상 이점을 가진다. 결과적으로, 새로운 클라우드 기반 애플리케이션과 마이크로서비스 아키텍처에서는 OIDC가 선호되는 경향이 있다. 그러나 많은 기업 내부 시스템과 레거시 애플리케이션은 여전히 SAML을 기반으로 한 인프라를 유지하고 있어, 두 표준이 공존하는 경우가 많다.

OIDC의 핵심 구성 요소인 ID 토큰은 JWT 형식으로 인코딩되어 전달된다. JWT는 JSON 객체를 URL 안전 문자열로 표현하는 개방형 표준(RFC 7519)으로, 헤더, 페이로드, 서명의 세 부분으로 구성된다. OIDC는 이 JWT 구조를 채택하여 ID 토큰을 표준화함으로써 상호 운용성을 보장한다. ID 토큰의 페이로드에는 iss(발급자), sub(주체 식별자), aud(대상자), exp(만료 시간)와 같은 표준 클레임과 사용자 프로필 정보를 담은 추가 클레임이 포함된다.

JWT는 자체 포함적(self-contained) 특성을 가지며, 서명을 통해 토큰의 무결성과 발행자를 검증할 수 있다. 이는 OIDC Relying Party (RP)가 토큰의 유효성을 확인하기 위해 매번 OpenID Provider (OP)에 문의할 필요 없이, 사전에 교환된 공개 키를 이용해 로컬에서 검증할 수 있음을 의미한다. 이 방식은 검증 과정의 효율성을 높이고, OP에 대한 의존성을 줄인다.

다음은 ID 토큰이 JWT로서 가지는 주요 클레임의 예시이다.

OIDC는 JWT를 ID 토큰의 표준 포맷으로 규정하지만, 모든 JWT가 OIDC ID 토큰은 아니다. JWT는 더 넓은 범위의 인가(OAuth 2.0 액세스 토큰)나 정보 교환에 사용될 수 있는 범용 포맷이다. 반면, OIDC ID 토큰은 반드시 특정 표준 클레임 집합을 포함하고 인증 이벤트를 증명하는 데 사용되는 특수한 형태의 JWT이다. 따라서 OIDC 구현에서는 JWT 라이브러리를 활용하지만, 추가로 ID 토큰의 필수 클레임 검증 및 서명 검증을 철저히 수행해야 한다.