JWT (Json 웹 토큰) 대상 "aud"대 Client_Id-차이점은 무엇입니까?

JWT (Json 웹 토큰) 대상 "aud"대 Client_Id-차이점은 무엇입니까?

---

내 인증 서버에서 OAuth 2.0 JWT access_token을 구현하는 중입니다. 그러나 JWT aud클레임과 client_idHTTP 헤더 값 의 차이점이 무엇인지 명확하지 않습니다 . 동일합니까? 그렇지 않다면 둘의 차이점을 설명해 주시겠습니까?

내 의심은 aud리소스 서버 client_id를 참조해야하고는 인증 서버 (예 : 웹 앱 또는 iOS 앱)에서 인식하는 클라이언트 응용 프로그램 중 하나를 참조해야한다는 것입니다.

내 현재의 경우 내 리소스 서버도 내 웹 앱 클라이언트입니다.

---

결과적으로 내 의심은 옳았다. 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가 해당되지 않음을 인식하므로 액세스가 거부됩니다.

---

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

OAuth 클라이언트 ID와 JWT aud클레임

OAuth 클라이언트 ID는 완전히 관련이 없으며 JWT aud클레임 과 직접적인 관련이 없습니다 . OAuth의 관점에서 토큰은 불투명 한 개체입니다.

이러한 토큰을 허용하는 응용 프로그램은 이러한 토큰의 의미를 구문 분석하고 유효성을 검사 할 책임이 있습니다. JWT aud클레임 내에서 OAuth 클라이언트 ID를 지정하는 데 많은 가치가 없습니다 .

참고 URL : https://stackoverflow.com/questions/28418360/jwt-json-web-token-audience-aud-versus-client-id-whats-the-difference