---
title: official-doc / OpenID Connect Core 1.0 — ID Token `aud`/`iss`/`nonce` Validation (§2, §3.1.2.1, §3.1.3.7)
source_type: official-doc
url: https://openid.net/specs/openid-connect-core-1_0.html
archive_url: http://web.archive.org/web/20260713074401/https://openid.net/specs/openid-connect-core-1_0.html
related_branches: [feature-keycloak-three-leg-trust-chain, feature-keycloak-iss-claim-hostname-mismatch]
related_projects: [keycloak-patterns]
tags: [official-doc, keycloak-patterns, auth, oidc, jwt-validation]
status: raw
confidence: high
created: 2026-07-18
last_reviewed: 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`). 본 자료는 그 설정이 왜 필요한지의 표준 근거.