답변:
결과적으로 내 의심은 옳았다. audJWT 의 대상 클레임은 토큰을 수락해야하는 리소스 서버를 참조하기위한 것입니다.
마찬가지로 이 게시물 단순히 그것을두고 :
토큰의 대상은 토큰의 의도 된 수신자입니다.
대상 값은 문자열입니다. 일반적으로 액세스되는 리소스의 기본 주소 (예 :
https://contoso.com.
client_id의 OAuth에서이 자원 서버 자원을 요청합니다 클라이언트 응용 프로그램을 의미합니다.
클라이언트 앱 (예 : iOS 앱)은 인증 서버에서 JWT를 요청합니다. 이렇게하면 필요한 모든 사용자 자격 증명 client_id과 client_secret함께 전달됩니다 . 권한 부여 서버는 사용하여 클라이언트의 유효성을 확인 client_id하고 client_secret와 리턴한다 JWT를.
JWT에는 audJWT가 유효한 리소스 서버를 지정 하는 클레임 이 포함 됩니다. 에 aud포함되어 www.myfunwebapp.com있지만 클라이언트 앱이에서 JWT를 사용하려고하면 www.supersecretwebapp.com리소스 서버에서 JWT가 해당되지 않음을 인식하므로 액세스가 거부됩니다.
aud(Audience) 주장RFC 7519 에 따르면 :
"aud"(청중) 클레임은 JWT가 대상으로하는 수신자를 식별합니다. JWT를 처리하려는 각 주체는 청중 클레임의 값으로 자신을 식별해야합니다. 클레임을 처리하는 주체가이 클레임이있을 때 "aud"클레임의 값으로 자신을 식별하지 않는 경우 JWT를 거부해야합니다. 일반적으로 "aud"값은 각각 StringOrURI 값을 포함하는 대소 문자를 구분하는 문자열의 배열입니다. JWT에 하나의 대상이있는 특수한 경우에 "aud"값은 StringOrURI 값을 포함하는 단일 대소 문자 구분 문자열 일 수 있습니다. 청중 가치의 해석은 일반적으로 응용 프로그램에 따라 다릅니다. 이 주장의 사용은 선택 사항입니다.
aud사양에 정의 된 대상 ( ) 클레임은 일반적이며 응용 프로그램에 따라 다릅니다. 의도 된 용도는 토큰의 의도 된 수신자를 식별하는 것입니다. 수신자가 의미하는 것은 애플리케이션에 따라 다릅니다. 대상 값은 문자열 목록이거나 aud클레임 이 하나 뿐인 경우 단일 문자열 일 수 있습니다 . 토큰의 생성자는 aud올바르게 검증 된 것을 시행하지 않으며, 토큰 의 사용 여부를 결정하는 책임은 수신자에게 있습니다.
값이 무엇이든, 수신자가 JWT의 유효성을 검사하고 토큰이 목적에 사용되도록 의도 된 것인지 aud확인하려는 경우, 자신 을 식별 하는 값을 결정해야 하며 토큰은 수신자의 선언 된 ID가 다음과 같은 경우에만 유효성을 검사해야합니다. aud주장에 존재합니다 . 이것이 URL인지 다른 애플리케이션 특정 문자열인지는 중요하지 않습니다. 예를 들어 내 시스템 aud이 문자열로 자신을 식별한다고 결정 api3.app.com하면 aud클레임 api3.app.com이 대상 값 목록에 포함 된 경우에만 JWT를 수락해야 합니다.
물론 수신자는 무시하도록 선택할 수 aud있으므로 수신자가 토큰이 특별히 생성되었다는 긍정적 인 검증을 원하는 경우에만 유용합니다.
사양을 기반으로 한 내 해석은 aud주장이 특정 목적에만 유효한 특수 목적 JWT를 만드는 데 유용하다는 것입니다. 한 시스템의 경우 토큰이 일부 기능에는 유효하지만 다른 기능에는 유효하지 않기를 원할 수 있습니다. 동일한 키와 유효성 검사 알고리즘을 사용하면서 특정 "대상"으로 만 제한된 토큰을 발급 할 수 있습니다.
일반적인 경우 JWT는 신뢰할 수있는 서비스에 의해 생성되고 다른 신뢰할 수있는 시스템 (잘못된 토큰을 사용하지 않는 시스템)에서 사용되기 때문에 이러한 시스템은 사용할 값을 조정하기 만하면됩니다.
물론, aud완전히 선택 사항이며 사용 사례가이를 보증하지 않는 경우 무시할 수 있습니다. 특정 대상이 토큰을 사용하도록 제한하지 않거나 시스템에서 실제로 aud토큰의 유효성을 검사하지 않으면 쓸모가 없습니다.
내가 생각할 수있는 하나의 인위적인 (아직 간단한) 예는 아마도 우리는 별도의 암호화 키와 알고리즘을 구현하지 않고도 액세스 및 토큰 새로 고침에 JWT를 사용하고 싶을 것입니다. -반대.
를 사용 하면 새로 고침 토큰에 대한 클레임과 이러한 토큰을 만들 때 액세스 토큰에 대한 aud클레임을 지정할 수 있습니다 . 새로 고침 토큰에서 새 액세스 토큰을 가져 오도록 요청하면 새로 고침 토큰이 진짜 새로 고침 토큰인지 확인해야합니다. 토큰이 사실의 주장을 위해 특별히보고 토큰을 유효한 재생 여부 상기 한 바와 같이 검증은 우리에게 말할 것이다 에서 .refreshaccessaudrefreshaud
aud클레임OAuth 클라이언트 ID는 완전히 관련이 없으며 JWT aud클레임 과 직접적인 관련이 없습니다 . OAuth의 관점에서 토큰은 불투명 한 개체입니다.
이러한 토큰을 허용하는 응용 프로그램은 이러한 토큰의 의미를 구문 분석하고 유효성을 검사 할 책임이 있습니다. JWT aud클레임 내에서 OAuth 클라이언트 ID를 지정하는 데 많은 가치가 없습니다 .
나는 이것이 OIDC가 아닌 oauth 2.0에 대해 태그되어 있음을 알고 있지만 두 표준 모두 JWT와 주장을 사용할 수 있기 때문에 두 표준 사이에 종종 충돌이 있습니다aud . 그리고 하나 (OIDC)는 기본적으로 다른 하나 (OAUTH 2.0)의 확장입니다. (나는 OIDC를 찾는이 질문을 우연히 발견했습니다.)
OAuth 2.0 액세스 토큰의 경우 기존 답변이이를 잘 다루고 있습니다. 또한 다음은 OAuth 2.0 프레임 워크 (RFC 6749)의 관련 섹션입니다.
암시 적 흐름을 사용하는 공용 클라이언트의 경우이 사양은 클라이언트가 액세스 토큰이 발급 된 클라이언트를 확인하는 방법을 제공하지 않습니다.
...
클라이언트에 대한 리소스 소유자 인증은이 사양의 범위를 벗어납니다. 권한 부여 프로세스를 클라이언트에 위임 된 최종 사용자 인증 형식으로 사용하는 모든 사양 (예 : 타사 로그인 서비스)은 클라이언트가 액세스 권한을 결정할 수있는 추가 보안 메커니즘없이 암시 적 흐름을 사용해서는 안됩니다. 토큰이 사용을 위해 발행되었습니다 (예 : 대상-액세스 토큰 제한).
OIDC에는 액세스 토큰 외에 ID 토큰 이 있습니다. OIDC 사양은 audID 토큰 의 클레임 사용에 대해 명시 적입니다 . ( openid-connect-core-1.0 )
aud가
필요합니다. 이 ID 토큰의 대상입니다. 잠재 고객 값으로 신뢰 당사자의 OAuth 2.0 client_id를 포함해야합니다. 다른 청중을위한 식별자도 포함 할 수 있습니다. 일반적으로 aud 값은 대소 문자를 구분하는 문자열의 배열입니다. 하나의 청중이있는 일반적인 특수한 경우에 aud 값은 대소 문자를 구분하는 단일 문자열 일 수 있습니다.
또한 OIDC 는 둘 이상의 값이 있을 때 azp와 함께 사용되는 클레임을 지정합니다 .audaud
azp
선택 사항. 승인 된 당사자-ID 토큰이 발행 된 당사자입니다. 존재하는 경우이 당사자의 OAuth 2.0 클라이언트 ID를 포함해야합니다. 이 클레임은 ID 토큰에 단일 대상 값이 있고 해당 대상이 승인 된 당사자와 다른 경우에만 필요합니다. 승인 된 당사자가 단독 청중과 동일한 경우에도 포함될 수 있습니다. azp 값은 StringOrURI 값을 포함하는 대소 문자를 구분하는 문자열입니다.
낡았지만 질문은 오늘도 유효하다고 생각합니다
내 의심은 aud가 리소스 서버를 참조하고 client_id는 인증 서버가 인식하는 클라이언트 응용 프로그램 중 하나를 참조해야한다는 것입니다.
예, aud 는 토큰 소비 당사자를 참조해야합니다. 그리고 client_id 는 토큰 획득 당사자를 나타냅니다.
내 현재의 경우 내 리소스 서버도 내 웹 앱 클라이언트입니다.
OP의 시나리오에서 웹 앱과 리소스 서버는 모두 동일한 당사자에 속합니다. 따라서 이것은 고객과 청중이 동일하다는 것을 의미합니다. 그러나 이것이 사실이 아닌 상황이있을 수 있습니다.
OAuth 보호 리소스를 사용하는 SPA에 대해 생각해보십시오. 이 시나리오에서 SPA는 클라이언트입니다. 보호 된 리소스는 액세스 토큰의 대상입니다.
이 두 번째 시나리오는 흥미 롭습니다. 승인 요청에서 의도 한 대상을 정의 할 수있는 위치를 설명하는 " OAuth 2.0 용 자원 표시기 "라는 작업 초안 이 있습니다. 따라서 결과 토큰은 지정된 대상으로 제한됩니다. 또한 Azure OIDC는 리소스 등록을 허용하고 인증 요청에 리소스 매개 변수를 포함하여 액세스 토큰 대상 대상을 정의하는 유사한 접근 방식을 사용합니다. 이러한 메커니즘을 통해 OAuth 광고는 클라이언트와 토큰 소비 (대상) 당사자를 분리 할 수 있습니다.
aud REQUIRED for session_token. Contains the client_id of the client receiving the assertion.