JSON 웹 토큰

JSON Web Token
JSON 웹 토큰
줄임말JWT
상황제안된 표준
초판2010년 12월 28일(2010-12-28)
최신 버전 RFC7519
2015년 5월
조직IETF
위원회.IEGS
작가들
기본 규격
도메인data 교환
웹 사이트datatracker.ietf.org/doc/html/rfc7519

JSON Web Token(JWT, /dʒ/t/, 단어 "jot"[1]와 동일)은 옵션 서명 및/또는 옵션 암호화를 사용하여 데이터를 작성하기 위한 제안된 인터넷 표준으로, 페이로드가 일정 수의 클레임을 단언하는 JSON을 보유하고 있습니다.토큰은 개인 비밀 키 또는 공용/개인 키를 사용하여 서명됩니다.

예를 들어, 서버는 "관리자로서 로그인"이라는 클레임을 가진 토큰을 생성하여 클라이언트에 제공할 수 있습니다.클라이언트는 이 토큰을 사용하여 admin으로 로그인하고 있음을 증명할 수 있습니다.토큰은 한 당사자의 개인 키(일반적으로 서버의 개인 키)로 서명할 수 있으므로, 모든 당사자가 나중에 토큰이 합법적인지 확인할 수 있습니다.상대방이 적절하고 신뢰할 수 있는 수단으로 대응하는 공개키를 소유하고 있는 경우, 토큰의 정당성을 확인할 수 있습니다.토큰은 특히 [2]웹 브라우저 Single Sign-On(SSO; 싱글사인온) 컨텍스트에서 사용할 수 있도록 작고 URL [3]안전하도록 설계되었습니다.JWT 클레임은 일반적으로 ID 제공자와 서비스 제공자 간에 인증된 사용자의 ID를 전달하거나 비즈니스 [4][5]프로세스에서 요구하는 기타 유형의 클레임을 전달하기 위해 사용할 수 있습니다.

JWT는 JSON Web Signature 및 JSON Web [1][6][7]Encryption과 같은 다른 JSON 기반 표준을 사용합니다.

구조.

헤더
시그니처 생성에 사용되는 알고리즘을 지정합니다.
HS256는 이 토큰이 HMAC-SHA256을 사용하여 서명되었음을 나타냅니다.
사용되는 일반적인 암호화 알고리즘은 SHA-256(HS256)을 사용하는 HMAC와 SHA-256(RS256)을 사용하는 RSA 시그니처입니다.JWA(JSON Web Algorithms) RFC 7518에서는 인증과 암호화 [8]양쪽에 더 많은 기능이 도입되어 있습니다.
{   "실패": "HS256",   "표준": 'JWT' }
페이로드
클레임 세트를 포함합니다.JWT 사양은 [1]토큰에 일반적으로 포함되는 표준 필드인 7개의 등록 클레임 이름을 정의합니다.보통 토큰의 목적에 따라 커스텀 클레임도 포함됩니다.
이 예에서는 표준 Issued At Time 클레임이 있습니다(iat및 커스텀 클레임(loggedInAs).
{   "logged InAs": "admin",   「iat」: 1422779638 }
서명
토큰을 안전하게 검증합니다.시그니처는 Base64url Encoding RFC 4648을 사용하여 헤더와 payload를 부호화하고 이 둘을 마침표 구분 기호와 함께 연결함으로써 계산됩니다.이 문자열은 헤더에 지정된 암호화 알고리즘(이 경우 HMAC-SHA256)을 통해 실행됩니다.Base64url 인코딩은 Base64와 비슷하지만 영숫자가 아닌 다른 문자를 사용하며 패딩은 생략합니다.
HMAC_SHA256(   시크릿,   base64url Encoding(머리글자) + '.' +   base64url Encoding(페이로드) )

3개의 부분은 Base64url Encoding RFC 4648을 사용하여 개별적으로 부호화되어 마침표를 사용하여 JWT를 생성합니다.

컨스턴트 상품권 = base64url Encoding(머리글자) + '.' + base64url Encoding(페이로드) + '.' + base64url Encoding(서명)

위의 데이터와 "secretkey"의 비밀에 의해 토큰이 생성됩니다.

eyJhbGciOiJIUZI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCYPYXXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBXLN_oWnFSRgCzcmJmjiU5MjiUCSPIHI

이 토큰은 HTML 및 HTTP로 [3]쉽게 전달할 수 있습니다.

사용하다

인증에서는 사용자가 credential을 사용하여 정상적으로 로그인하면 JSON Web 토큰이 반환되며 서버에서 세션을 만들고 쿠키를 반환하는 기존 접근 방식이 아닌 로컬(일반적으로 로컬 또는 세션스토리지에 저장되지만 cookie를 사용할 수도 있습니다)에 저장해야 합니다.무인 프로세스의 경우 클라이언트는 JWT를 생성하여 사전 공유 비밀 정보로 서명하여 다음과 같이 OAuth 준거 서비스에 직접 인증할 수도 있습니다.

POST /oauth2/token? 콘텐츠 유형: 어플/x-www-form-urlencoded  grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=eyJhb...

클라이언트가 유효한 JWT 어설션을 전달하면 서버는 응용 프로그램에 대한 호출에 유효한access_token을 생성하여 클라이언트에 반환합니다.

{   "access_module": "에잇....",   "type_type": "비어",   "syslog_in": 3600 }

클라이언트가 보호된 루트 또는 리소스에 액세스할 경우 사용자 에이전트는 JWT를 전송해야 합니다(일반적으로Authorization 를 사용한HTTP 헤더Bearer스키마헤더의 내용은 다음과 같습니다.

인증:bearer eyJhbGci...<param>...5CSPIHI

이는 사용자 상태가 서버 메모리에 저장되지 않기 때문에 상태 비저장 인증 메커니즘입니다.서버의 보호된 경로는 Authorization 헤더에 유효한 JWT가 있는지 확인하고 JWT가 있는 경우 사용자는 보호된 리소스에 액세스할 수 있습니다.JWT는 자급식이기 때문에 필요한 모든 정보가 존재하므로 데이터베이스를 여러 번 쿼리할 필요가 줄어듭니다.

표준 필드

코드 이름. 묘사
표준 클레임 필드 인터넷 초안은 JWT 청구 집합 내에서 사용할 수 있는 다음과 같은 표준 필드("청구")를 정의합니다.
iss 발행자 JWT를 발행한 주체를 식별합니다.
sub 주제 JWT의 서브젝트를 식별합니다.
aud 관객 JWT 의 수신처를 지정합니다.JWT를 처리하고자 하는 각 주계약자는 청중의 주장에 있는 가치로 자신을 식별해야 합니다.클레임을 처리하는 주체(principle processing principled)가 자신의 가치를 특정하지 않는 경우aud청구가 있을 경우 JWT는 거절되어야 한다.
exp 유효 기간 처리를 위해 JWT를 승인하지 않을 필요가 있는 유효기간을 지정합니다.값은 [9]NumericDate여야 합니다.정수 또는 10진수 중 하나로 1970-01 00:00:00Z 이후의 초수를 나타냅니다.
nbf 이전 버전 아님 JWT가 처리를 위해 승인되기 시작하는 시간을 나타냅니다.값은 NumericDate여야 합니다.
iat 발행일 JWT가 발행된 시각을 나타냅니다.값은 NumericDate여야 합니다.
jti JWT 아이디 서로 다른 발행자 간에서도 대소문자를 구분하는 토큰 고유 식별자.
일반적으로 사용되는 헤더필드 다음 필드는 JWT 헤더에서 일반적으로 사용됩니다.
typ 토큰 타입 존재하는 경우 등록된 IANA Media Type으로 설정해야 합니다.
cty 콘텐츠 타입 네스트된 서명 또는 암호화를 사용하는 경우 다음을 설정하는 것이 좋습니다.JWT; 그렇지 않으면 이 [1]필드를 생략합니다.
alg 메시지 인증 코드 알고리즘 발행자는 토큰의 서명을 확인하는 알고리즘을 자유롭게 설정할 수 있습니다.그러나 지원되는 알고리즘 중에는 안전하지 않은 것이 있습니다.[10]
kid 키 ID 클라이언트가 토큰 시그니처를 생성하기 위해 사용한 키를 나타내는 힌트.서버는 이 값을 파일상의 키와 대조하여 시그니처가 유효하고 토큰이 인증되었는지 확인합니다.
x5c x.509 증명서 체인 토큰 시그니처 생성에 사용되는 개인 키에 대응하는 RFC 4945 형식의 증명서 체인.서버는 이 정보를 사용하여 시그니처가 유효하고 토큰이 인증되었는지 확인합니다.
x5u x.509 증명서 체인 URL 서버가 토큰 시그니처 생성에 사용되는 개인 키에 대응하는 증명서 체인을 취득할 수 있는 URL.서버는 이 정보를 취득하여 이 시그니처가 진짜인지 확인합니다.
crit 임계 토큰을 유효한 것으로 받아들이기 위해 서버가 이해할 필요가 있는 헤더 리스트
코드 이름. 묘사

실장

JWT 구현은 다음을 포함한 많은 언어와 프레임워크에 존재합니다.

취약성

JSON Web 토큰에는 세션 상태가 포함될 수 있습니다.그러나 프로젝트 요건으로 JWT 만료 전에 세션을 무효화할 수 있는 경우 서비스는 토큰만으로 토큰 어설션을 더 이상 신뢰할 수 없습니다.토큰에 저장된 세션이 취소되지 않았는지 확인하려면 토큰 어사션을 데이터 저장소에 대해 확인해야 합니다.이로 인해 토큰이 스테이트리스 상태가 되지 않게 되어 JWT의 [36]주요 이점이 저하됩니다.

보안 컨설턴트 Tim McLean은 다음과 같은 기능을 사용한 일부 JWT 라이브러리의 취약성을 보고했습니다.alg토큰을 잘못 검증하기 위한 필드입니다.대부분의 경우,alg=none토큰. 이러한 취약점이 패치되는 동안, McLean은 이 취약점을 폐지할 것을 제안했습니다.alg동일한 구현 [10]혼동을 방지하기 위해 필드를 모두 입력합니다.그래도 새롭다alg=none취약성은 여전히 야생에서 발견되고 있으며, 2018-2021년에 접수된 4건의 CVE가 이러한 [37]원인을 가지고 있습니다.

적절한 설계를 통해 개발자는 다음과 같은 예방 조치를 [38][39]취함으로써 알고리즘의 취약성에 대처할 수 있습니다.

  1. JWT 헤더만으로 검증이 이루어지도록 해서는 안 됩니다.
  2. 알고리즘을 이해합니다(필요에 따라서는 안 됩니다).alg필드만)
  3. 적절한 키 크기 사용

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c d Jones, Michael B.; Bradley, Bradley; Sakimura, Sakimura (May 2015). JSON Web Token (JWT). IETF. doi:10.17487/RFC7519. ISSN 2070-1721. RFC 7519.
  2. ^ Nickel, Jochen (2016). Mastering Identity and Access Management with Microsoft Azure. p. 84. ISBN 9781785887888. Retrieved July 20, 2018.
  3. ^ a b "JWT.IO - JSON Web Tokens Introduction". jwt.io. Retrieved July 20, 2018.
  4. ^ Sevilleja, Chris. "The Anatomy of a JSON Web Token". Retrieved May 8, 2015.
  5. ^ "Atlassian Connect Documentation". developer.atlassian.com. Retrieved May 8, 2015.
  6. ^ "draft-ietf-jose-json-web-signature-41 - JSON Web Signature (JWS)". tools.ietf.org. Retrieved May 8, 2015.
  7. ^ "draft-ietf-jose-json-web-encryption-40 - JSON Web Encryption (JWE)". tools.ietf.org. Retrieved May 8, 2015.
  8. ^ "draft-ietf-jose-json-web-algorithms-40 - JSON Web Algorithms (JWA)". tools.ietf.org. Retrieved May 8, 2015.
  9. ^ Jones, Michael B.; Bradley, Bradley; Sakimura, Sakimura (May 2015). ""exp" (Expiration Time) Claim". JSON Web Token (JWT). IETF. sec. 4.1.4. doi:10.17487/RFC7519. ISSN 2070-1721. RFC 7519.
  10. ^ a b McLean, Tim (March 31, 2015). "Critical vulnerabilities in JSON Web Token libraries". Auth0. Retrieved March 29, 2016.
  11. ^ github.com에 jwt-dotnet
  12. ^ github.com에 libjwt
  13. ^ "liquidz/clj-jwt". GitHub. Retrieved May 7, 2018.
  14. ^ github.com에 cljwt
  15. ^ JustJWTgithub.com에
  16. ^ "bryanjos/joken". GitHub. Retrieved May 7, 2018.
  17. ^ "golang-jwt/jwt". GitHub. Retrieved January 8, 2018.
  18. ^ "jwt: JSON Web Token (JWT) decoding and encoding". Hackage. Retrieved May 7, 2018.
  19. ^ github.com에 auth0/java-jwt
  20. ^ "kjur/jsrsasign". GitHub. Retrieved May 7, 2018.
  21. ^ "SkyLothar/lua-resty-jwt". GitHub. Retrieved May 7, 2018.
  22. ^ "jsonwebtoken". npm. Retrieved May 7, 2018.
  23. ^ github.com에 ocaml-jwt
  24. ^ 크립트::미국의 광고 대행사cpan.org에
  25. ^ github.com에 lcobucci/jwt
  26. ^ Egan, Morten (February 7, 2019), GitHub - morten-egan/jwt_ninja: PLSQL Implementation of JSON Web Tokens., retrieved March 14, 2019
  27. ^ "SP3269/posh-jwt". GitHub. Retrieved August 1, 2018.
  28. ^ "jpadilla/pyjwt". GitHub. Retrieved March 21, 2017.
  29. ^ pkgs.racket-lang.org에 net-jwt
  30. ^ JSON-WebTokengithub.com에
  31. ^ github.com에 ruby-jwt
  32. ^ github.com에 jsonwebtoken
  33. ^ github.com에 rust-jwt
  34. ^ github.com에 jwt-scala
  35. ^ github.com에[1]
  36. ^ Slootweg, Sven. "Stop using JWT for sessions". joepie91 Ramblings. Retrieved August 1, 2018.
  37. ^ "CVE - Search Results". cve.mitre.org.
  38. ^ "Common JWT security vulnerabilities and how to avoid them". Retrieved May 14, 2018.
  39. ^ Andreas, Happe. "JWT: Signature vs MAC attacks". snikt.net. Retrieved May 27, 2019.
  • RFC 7519
  • jwt.io – Auth0에 의해 유지보수되는 툴과 매뉴얼이 포함된 JWT에 관한 전문 웹사이트