llm-wiki/vault/20-evidence/official-docs/openid-connect-core-id-token-validation.md

title, source_type, url, archive_url, related_branches, related_projects, tags, status, confidence, created, last_reviewed

title	source_type	url	archive_url	related_branches	related_projects	tags	status	confidence	created	last_reviewed
official-doc / OpenID Connect Core 1.0 — ID Token `aud`/`iss`/`nonce` Validation (§2, §3.1.2.1, §3.1.3.7)	official-doc	https://openid.net/specs/openid-connect-core-1_0.html	http://web.archive.org/web/20260713074401/https://openid.net/specs/openid-connect-core-1_0.html	feature-keycloak-three-leg-trust-chain feature-keycloak-iss-claim-hostname-mismatch	keycloak-patterns	official-doc keycloak-patterns auth oidc jwt-validation	raw	high	2026-07-18	2026-07-18

official-doc / OpenID Connect Core 1.0 — ID Token aud/iss/nonce Validation

Layer: raw/official-docs/ — OpenID Connect Core 1.0 (OpenID Foundation) 공식 사양의 ID Token aud semantics, Authentication Request nonce parameter, ID Token Validation (§3.1.3.7) verbatim 발췌. official-standard 등급 — RFC 급 프로토콜 표준 사양(OIDF 공식 스펙). Keycloak/Google 등 벤더 문서보다 상위 근거.

source_type 허용값

official-doc. OIDC Core 1.0 은 OpenID Foundation 이 발행한 공식 사양(spec)이며 벤더 문서가 아니다.

Parent / 활용 branch (필수, 최소 1개+)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-keycloak-three-leg-trust-chain	3-leg trust chain (Browser ↔ Keycloak ↔ Google) 의 Hop 1 (Google → Keycloak) 검증 매트릭스에서 Keycloak 이 Google ID token 의 aud(=Keycloak 이 Google 에 등록한 client_id), iss, nonce 를 검증해야 한다는 스펙 근거. D5 Hop 매트릭스가 지금까지 UNSUPPORTED_DECISION 이었던 부분(§Decision Evidence Map D5)을 본 자료의 §3.1.3.7 quote 로 corroborate.
raw/branch-notes/feature-keycloak-iss-claim-hostname-mismatch	D5("iss 검증이 신뢰의 본질") 진행 중 메모가 "RFC 7519 + OIDC Core spec 모두 iss 검증을 mandatory 로 규정" 이라 주장했으나 본 branch Sources 에 OIDC Core 원문이 없어 미증명 상태였음(§Decision Evidence Map D5 Open Risk, §Claims To Verify). 본 자료의 §3.1.3.7 item 2 (iss MUST exactly match) verbatim quote 가 그 공백을 직접 closes.

출처 / Source

• 원본 URL: https://openid.net/specs/openid-connect-core-1_0.html
• 아카이브 URL: http://web.archive.org/web/20260713074401/https://openid.net/specs/openid-connect-core-1_0.html
• 저자 / 조직: OpenID Foundation (Nat Sakimura, John Bradley, Mike Jones, Breno de Medeiros, Chuck Mortimore)
• 발행일: 2014-11-08 (errata set 1, 2014-11-08 최종 개정판 기준 rolling spec 페이지)
• 마지막 확인일: 2026-07-18

왜 저장했는지 / Why archived

3-leg trust chain(Browser ↔ Keycloak ↔ Google)에서 Keycloak 이 Google ID Token 을 검증할 때 및 backend 가 Keycloak ID/access token 을 검증할 때 공통으로 요구되는 aud(자신의 client_id 포함 여부), nonce(요청 시 발급 + replay 방지 재대조), iss(Issuer 정확 일치) 검증 규칙의 1차 표준 근거. 두 branch 모두 지금까지 이 요구사항을 자체 진술(본문 메모)로만 기록하고 UNSUPPORTED_DECISION/미증명 상태였다.

핵심 인용 / Key quotes (verbatim, 5문장)

[§2 ID Token — aud] "REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value."

[§3.1.2.1 Authentication Request — nonce] "OPTIONAL. String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token." [...] "Sufficient entropy MUST be present in the nonce values used to prevent attackers from guessing values."

[§3.1.3.7 ID Token Validation, item 2 — iss] "The Issuer Identifier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim."

[§3.1.3.7 ID Token Validation, item 3 — aud] "The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience." [...] "The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client."

[§3.1.3.7 ID Token Validation, item 9 — nonce] "If a nonce value was sent in the Authentication Request, a nonce Claim MUST be present and its value checked to verify that it is the same value as the one that was sent in the Authentication Request."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
OIDC-CORE-C1	ID Token 의 aud claim 은 REQUIRED 이며 Relying Party 의 OAuth 2.0 client_id 를 audience 값으로 반드시 포함해야 한다	[§2] "REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value."	official-standard	모든 OIDC ID Token 발급 — Keycloak 이 RP 로서 Google 에 등록한 client_id 가 Google 발급 ID Token 의 aud 에 있어야 함(3-leg 의 Hop 1)	Keycloak/Google 이 실제로 이 필드를 정확히 이렇게 채우는지의 구현 사실은 증명 안 됨 — 스펙 요구사항일 뿐, 벤더 구현 준수는 별도 확인 필요
OIDC-CORE-C2	Authentication Request 의 nonce parameter 는 (Authorization Code Flow 기준) OPTIONAL 이며, Client session 을 ID Token 과 연결하고 replay attack 을 완화하기 위한 문자열 값이고, Authentication Request 에서 ID Token 으로 그대로(unmodified) 전달되며, 공격자가 추측하지 못하도록 충분한 엔트로피가 있어야 한다	[§3.1.2.1] "OPTIONAL. String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token." [...] "Sufficient entropy MUST be present in the nonce values used to prevent attackers from guessing values."	official-standard	Authorization Code Flow 의 Authentication Request — Keycloak 이 Google 에 인증 요청을 보낼 때 nonce 동봉하는 결정의 근거	Authorization Code Flow 에서는 OPTIONAL 이라는 점에 주의 — 본 자료의 다른 플로우(§3.2.2.1 Implicit, §3.3.2.1 Hybrid)에서는 REQUIRED 로 격상됨(본 raw 문서의 self-grep 관찰에서 확인, 별도 claim 미등록). Keycloak 이 실제로 nonce 를 "자동 처리"하고 "비활성화 옵션을 끄지 않는다"는 branch 의 자체 결정은 이 claim 으로 증명되지 않음(Keycloak 벤더 문서 별도 필요)
OIDC-CORE-C3	Client 는 OpenID Provider 의 Issuer Identifier(보통 Discovery 로 획득)가 ID Token 의 iss claim 값과 정확히(exactly) 일치하는지 검증해야 한다	[§3.1.3.7 item 2] "The Issuer Identifier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim."	official-standard	모든 Client(RP)의 ID Token Validation 절차 — Keycloak 이 Google ID Token 을, backend 가 Keycloak ID/access token 을 검증할 때 공통 적용	iss 불일치 시 정확히 어떤 에러/예외를 던져야 하는지는 본 문장이 규정하지 않음 — 구현체(Keycloak, Spring Security 등)별 예외 클래스는 별도 확인 필요
OIDC-CORE-C4	Client 는 aud claim 이 자신의 iss 로 식별된 Issuer 에 등록한 client_id 값을 audience 로 포함하는지 검증해야 하며, Client 를 유효한 audience 로 나열하지 않거나 Client 가 신뢰하지 않는 추가 audience 를 포함하면 ID Token 을 반드시 거부(REJECT)해야 한다	[§3.1.3.7 item 3] "The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience." [...] "The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client."	official-standard	모든 Client 의 ID Token Validation — Keycloak 이 Google ID Token 검증 시 자신의 Google client_id 가 aud 에 있는지, backend 가 Keycloak 발급 token 검증 시 자신의 client_id 가 aud 에 있는지	"신뢰하지 않는 추가 audience"를 어떻게 판별하는지(신뢰 목록 관리 방식)는 본 문장이 규정하지 않음 — Client 구현 정책 사항
OIDC-CORE-C5	Authentication Request 에 nonce 값을 보냈다면, 반환된 ID Token 에 nonce claim 이 반드시 존재해야 하며 그 값이 보낸 값과 동일한지 확인해야 한다(replay attack 검사는 SHOULD)	[§3.1.3.7 item 9] "If a nonce value was sent in the Authentication Request, a nonce Claim MUST be present and its value checked to verify that it is the same value as the one that was sent in the Authentication Request."	official-standard	Keycloak 이 Google 에 nonce 를 보냈다면 Google ID Token 의 nonce 일치 검증이 MUST — 3-leg D3 결정("nonce 사용 의무화")의 검증(validation) 측 근거	Keycloak 이 이 MUST 규정을 실제로 자동 구현하는지는 이 claim 으로 증명되지 않음(스펙 요구사항일 뿐, Keycloak broker 구현 검증은 별도)

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • OIDC-CORE-C1: ID Token aud 는 REQUIRED 이고 RP 의 client_id 를 포함해야 한다는 스펙 규정 자체.
  • OIDC-CORE-C2: Authorization Code Flow 의 nonce request parameter 가 OPTIONAL 이며 replay 완화 목적이라는 스펙 규정 자체.
  • OIDC-CORE-C3: iss 정확 일치 검증이 Client 의 MUST 의무라는 스펙 규정 자체.
  • OIDC-CORE-C4: aud 에 자신의 client_id 가 없거나 신뢰 안 하는 audience 가 있으면 반드시 거부해야 한다는 스펙 규정 자체.
  • OIDC-CORE-C5: 요청에 nonce 를 보냈다면 응답 ID Token 의 nonce 일치 검증이 MUST 라는 스펙 규정 자체.
• 이 자료가 증명하지 않는 것:
  • Keycloak 또는 Google 이 이 MUST/REQUIRED 규정을 실제로 소스코드에서 어떻게 구현하는지(벤더 구현 사실).
  • Keycloak 의 First Broker Login Flow 가 Google nonce/iss/aud 검증 실패 시 정확히 어떤 에러를 던지고 어떻게 SPA/backend 에 노출되는지.
  • KC_HOSTNAME 미설정 시 Keycloak 자체 startup 동작(이는 Keycloak 벤더 문서의 영역).
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • Keycloak Identity Brokering 공식 문서에서 Google IdP 연동 시 위 5개 MUST 규정이 실제로 어느 코드 경로(OIDCIdentityProvider 등)에서 수행되는지.
  • backend(Spring Security Resource Server) 가 Keycloak 발급 access token 에 대해 동일한 aud/iss 검증을 수행하는 정확한 설정값(raw/official-docs/spring-security-resource-server-jwt 와 교차 확인).

메모 / Notes

나중에 wiki로 옮길 때 참고할 짧은 메모. 검증되지 않은 내 추론은 여기에 두지 말 것.

• nonce 는 Authorization Code Flow(§3.1.2.1)에서는 OPTIONAL 이지만, self-grep 중 관찰된 §3.2.2.1(Implicit)/§3.3.2.1(Hybrid) 동일 문구는 REQUIRED 로 격상되어 있었다 (본 raw 문서에는 Authorization Code Flow 분만 claim 화 — 다른 플로우 인용이 필요하면 별도 claim 추가).
• Self-Issued OP 관련 절(§3.1.3.7 근방, "self-issued.me" 문구)은 본 3-leg 시나리오(Keycloak/Google 은 self-issued 아님)와 무관하므로 인용 대상에서 제외했다.
• 추가로 봐야 할 동일 출처 페이지: §3.1.3.6 (Token Response Validation), §16 (Security Considerations) — signature/JWKS rotation 관련 추가 MUST 항목이 있을 수 있음(현재 raw 문서엔 미포함, 별도 조사 필요).

Related / 관련

• raw/official-docs/keycloak-first-broker-login-flow — 같은 3-leg branch 의 기존 Source. First Broker Login Flow(account linking) 범위이며 본 자료(OIDC Core 토큰 검증)와 상호 보완.
• raw/official-docs/google-openid-connect-oidc — Google 측 OIDC 벤더 문서(endpoint, claim 매핑). 본 자료는 프로토콜 표준 자체이고 그 문서는 Google 의 벤더별 구현 세부사항.
• raw/official-docs/spring-security-resource-server-jwt — backend 측 JWT iss/aud 검증 실제 설정(issuer-uri/jwk-set-uri). 본 자료는 그 설정이 왜 필요한지의 표준 근거.