일반적으로 같은 토큰을 서로 다른 수신자 자리에 혼용하면 안 됩니다. OpenID Connect ID Token은 인증 결과를 Client에 전달하므로 ID Token의 aud에 해당 Client ID가 포함돼야 합니다. OAuth Access Token은 보호 자원 접근 권한을 나타내며, 발급된 의도된 Resource Server가 이를 검증해야 합니다.
Access Token은 opaque 문자열일 수 있고 모든 구현에서 JWT aud claim으로 표현되는 것은 아닙니다. 기존 인증·SSO 글의 큰 역할 설명을 반복하기보다, 잘못된 API 수신자에게 전달한 토큰을 거부하는 이유를 풀이합니다. 사례는 창작 교육용입니다.
토큰의 대상은 토큰을 소비하는 시스템입니다
OAuth와 OpenID Connect를 한 문장으로 나누는 방법은 이미 정보보호론 인증·SSO 글에서 볼 수 있습니다. 여기서는 그다음 질문인 ‘이 토큰을 어느 수신자가 받아야 하는가’를 좁게 연습합니다. OpenID Connect ID Token은 OpenID Provider가 인증한 End-User 정보를 Client에 전달하는 인증 주장입니다. ID Token 안의 aud claim은 그 토큰의 의도된 audience인 Client ID를 포함해야 하며, Client가 자기 ID를 audience에 찾지 못하면 token을 거부합니다. 추가 audience가 있으면 그 수신자를 신뢰하는지도 검증해야 합니다.
OAuth Access Token은 Resource Owner가 허용한 범위의 보호 자원 접근 권한을 Client가 제시하는 자격 증명입니다. RFC 6749는 Access Token이 opaque 문자열일 수도 있고, 서버가 검증 정보를 자체 포함한 형식일 수도 있다고 명시합니다. 따라서 토큰 안에 항상 읽을 수 있는 aud claim이 있다고 가정하지 않습니다. RFC 9700은 access token을 특정 Resource Server로 제한하고, 해당 서버가 의도된 audience인지 확인하도록 권고합니다. 검증 방식은 opaque/reference token이면 introspection 같은 서버 측 절차일 수 있고, self-contained token이면 형식과 정책이 정의한 claims를 확인할 수 있습니다.
| 자격 증명 | 의도된 수신자 | 토큰이 증명·허용하는 것 | 잘못 전달한 경우 |
|---|---|---|---|
| ID Token, aud=portal-app | 로그인 Client portal-app | OIDC 인증 흐름에서 사용자 신원에 관한 claims | invoices API는 로그인 ID Token을 자기 API bearer token으로 받아들이지 않음 |
| Access Token, intended resource=invoices API | invoices API Resource Server | scope 등 발급 정책에 따른 보호 자원 권한 | inventory API는 자기 audience가 아니므로 요청 거부 |
| Access Token, opaque reference | authorization server/introspection 정책과 invoices API | 토큰 문자열 자체만으로 client가 claim을 읽을 수 없을 수 있음 | API가 신뢰된 검증 경로 없이 문자열을 ID Token으로 해석하지 않음 |
유효한 서명만으로 수신자 검증을 생략할 수 없습니다
가상의 로그인 Client 이름이 portal-app이고 API가 invoices-api라고 합시다. OpenID Provider가 portal-app을 audience로 가진 ID Token을 발급합니다. 이 토큰의 서명과 만료시간이 맞더라도 invoices-api가 사용자 인증을 대신할 목적으로 그대로 받아서는 안 됩니다. ID Token의 receiver는 Client이고, API의 보호 자원은 Resource Server가 처리합니다. API에서 사용자를 인증할 별도 access token이 필요한 흐름이라면 그 access token과 ID Token을 구분해 전달해야 합니다.
이번에는 authorization server가 invoices-api용 Access Token을 발급했다고 합시다. Client가 이를 inventory-api에 보내면 signature가 올바르거나 token이 아직 만료되지 않았더라도 intended audience가 맞지 않습니다. RFC 9700의 audience restriction 목표는 한 Resource Server용 token을 다른 서버에서 잘못 받아들이는 token redirect 위험을 줄이는 것입니다. 서버는 자기 서비스가 token 수신자로 지정됐는지 확인하고, 일치하지 않으면 요청을 거부해야 합니다. 실제 access token은 opaque일 수 있으므로 소비 서비스의 검증 규칙과 발급자 간 계약을 확인해야 합니다.
수신자를 다섯 가지 질문으로 확인합니다
- 토큰이 OIDC ID Token인지 OAuth Access Token인지 먼저 식별합니다.
- ID Token이면 검증하는 OIDC Client의 등록 Client ID가 aud에 있는지 확인합니다.
- Access Token이면 요청을 받는 Resource Server가 발급 정책상 intended audience인지 확인합니다.
- Access Token 형식이 opaque인지 self-contained인지 확인하고, 정해진 검증 경로를 사용합니다.
- issuer·서명·시간·scope 등 나머지 검증도 수신자 확인과 별도로 수행합니다.
이 절차는 사용자 로그인 여부만 보고 API를 허용하지 않게 합니다. ID Token의 aud 검사는 OIDC Client가 수행하고, Access Token의 resource audience 검사는 보호 자원을 제공하는 서버가 수행합니다. 두 토큰 모두 발급자와 시간, 무결성 등 다른 조건을 통과해야 하며 audience 일치만으로 권한이 보장되지는 않습니다. 반대로 scope가 충분해 보여도 intended Resource Server가 다르면 그 token을 사용해서는 안 됩니다.
기존 인증·SSO 글은 Access Token과 ID Token의 일반 역할을 설명합니다. 이 글은 그 요약을 다시 붙이지 않고, 로그인 Client와 API Resource Server를 서로 다른 주체로 놓고 수신자 불일치 상황을 비교하는 보완 연습입니다. 실제 서비스의 토큰 구조, issuer 설정, audience 제한 및 validation library 동작은 서비스 문서에서 확인해야 합니다. 표의 claim은 가상의 설계 사례이지 특정 사업자의 token format이 아닙니다.
모든 토큰에 JWT aud가 있다고 가정하지 않습니다
대표 오해는 Access Token을 무조건 JWT라고 여기고 그 안의 aud 문자열을 직접 읽어야만 검증할 수 있다고 생각하는 것입니다. OAuth 2.0 기본 규격은 token이 opaque일 수 있다고 정의하고 내부 속성 형식은 정하지 않습니다. Resource Server가 권한 서버의 검증 결과를 받는 opaque token도 사용할 수 있습니다. 반대로 ID Token은 OIDC의 규격화된 claim을 따라 Client의 audience를 확인해야 합니다. 토큰 이름, 검증 주체, 수신자, encoding을 한 덩어리로 외우지 마세요.
포털과 API 가운데 누가 토큰을 검증할지 답해 봅니다
회상 연습: portal-app ID Token의 aud는 portal-app입니다. Client는 인증이 됐지만 invoices-api가 이 ID Token을 직접 받았습니다. API가 바로 요청을 처리해도 되나요? 안 됩니다. ID Token의 수신자는 portal-app이고 invoices-api는 Resource Server입니다. API 권한은 invoices-api용 Access Token을 받아 해당 수신자를 확인하는 별도 흐름으로 검증해야 합니다. Access Token의 구체 표현이 JWT인지 opaque인지는 단정하지 않습니다. 이 질문은 직접 만든 학습 자료로 실제 기출이나 집중 180제 수록 카드가 아닙니다. 상품 구성은 /decks/security#focus-180에서 확인하세요.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
portal-app용 ID Token의 aud가 portal-app이다. invoices-api Resource Server가 이를 bearer token으로 받았다. 요청을 처리하기 전에 무엇을 확인하고 왜 구별해야 하나?
정답과 해설 확인
ID Token의 audience는 Client portal-app을 가리키므로 API는 이를 자기 Resource Server 접근 토큰으로 혼용하지 않습니다. API용 Access Token의 의도된 수신자, 발급자·검증 상태와 scope를 따로 확인해야 합니다.OIDC Core는 ID Token의 aud에 Client ID가 있어야 하고, OAuth Access Token은 보호 자원 권한을 나타내며 opaque일 수 있다고 규정합니다. OAuth Security BCP는 Access Token의 Resource Server audience를 제한·검증하는 것을 권고합니다.