JSON 웹 토큰
RFC 7519
2015년 5월
JSON 웹 토큰(JSON Web Token, JWT, "jot”[1])은 선택적 서명 및 선택적 암호화를 사용하여 데이터를 만들기 위한 인터넷 표준으로, 페이로드는 몇몇 클레임(claim) 표명(assert)을 처리하는 JSON을 보관하고 있다. 토큰은 비공개 시크릿 키 또는 공개/비공개 키를 사용하여 서명된다. 이를테면 서버는 "관리자로 로그인됨"이라는 클레임이 있는 토큰을 생성하여 이를 클라이언트에 제공할 수 있다. 그러면 클라이언트는 해당 토큰을 사용하여 관리자로 로그인됨을 증명한다. 이 토큰들은 한쪽 당사자의 비공개 키(일반적으로 서버의 비공개 키)에 의해 서명이 가능하며 이로써 해당 당사자는 최종적으로 토큰이 적법한지를 확인할 수 있다. 일부 적절하고 신뢰할만한 수단을 통해 다른 당사자가 상응하는 공개키를 소유하는 경우 이 경우 또한 토큰의 적법성 확인이 가능하다. 토큰은 크기가 작고[2] URL 안전으로 설계되어 있으며[3] 특히 웹 브라우저 통합 인증(SSO) 컨텍스트에 유용하다. JWT 클레임은 아이덴티티 제공자와 서비스 제공자 간(또는 비즈니스 프로세스에 필요한 클레임)의 인가된 사용자의 아이덴티티를 전달하기 위해 보통 사용할 수 있다.[4][5]
JWT는 다른 JSON 기반 표준에 의존한다: JSON 웹 시그너처 및 JSON 웹 암호화.[1][6][7]
구조
헤더 | { "alg" : "HS256", "typ" : "JWT" } | 서명 생성을 위해 어느 알고리즘을 사용할지를 식별한다
일반적으로 쓰이는 암호화 알고리즘들은 SHA-2(HS256) 방식의 HMAC와 SHA-256(RS256) 방식의 RSA 서명이다. JWA(JSON 웹 알고리즘) RFC 7518은 인가 및 암호화를 위해 더 많은 것을 도입하고 있다.[8] |
---|---|---|
페이로드 | { "loggedInAs" : "admin", "iat" : 1422779638 } | 일련의 클레임을 포함한다. JWT 사양은 토큰에 일반적으로 포함되는 표준 필드인 7개의 등록 클레임 이름(Registered Claim Names)을 정의한다.[1] 토큰의 목적에 따라 사용자 지정 클레임 또한 일반적으로 포함된다. 다음 예는 표준 Issued At Time 클레임( |
서명 | HMAC-SHA256( secret, base64urlEncoding(header) + '.' + base64urlEncoding(payload) ) | 토큰을 안전하게 확인한다. 서명은 Base64url 인코딩을 이용하여 헤더와 페이로드를 인코딩하고 이 둘을 점(.) 구분자로 함께 연결시킴으로써 계산된다. 해당 문자열은 그 뒤 헤더에 규정된 암호화 알고리즘(이번 경우에는 HMAC-SHA256)에 유입된다. Base64url 인코딩은 base64와 비슷하지만 각기 다른 영숫자를 사용하며 패딩(padding)은 제외한다. |
이 세 부분은 Base64url 인코딩을 사용하여 별도로 인코딩되며 JWT 생성을 위해 점(.)을 사용하여 연결된다:
const token = base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)
위 데이터와 "secretkey" 시크릿은 토큰을 생성한다:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
이 결과가 되는 토큰은 HTML과 HTTP로 쉽게 파싱이 가능하다.[3]
이용
인증의 경우 사용자가 성공적으로 자신들의 자격 정보를 사용하여 로그인하면 서버에 세션을 만들고 쿠키를 반환하는 전통적인 접근방식 대신 JSON 웹 토큰이 반환되며 로컬(일반적으로 로컬 또는 세션 스토리지. 쿠키를 사용할 수도 있음)에 저장되어야 한다. 부재 중인 프로세스의 경우 클라이언트는 미리 공유된 시크릿으로 자신만의 JWT를 생성하고 서명하고 이를 OAuth를 준수하는 서비스에 전달함으로써 다음과 같이 직접 인증을 수행할 수도 있다.:
POST /oauth2/token? Content-type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=eyJhb...
클라이언트가 유효한 JWT 표명을 전달하면 서버는 애플리케이션의 요청을 하기 위한 access_token을 생성하고 클라이언트에 이를 전달해주게 된다:
{ "access_token": "eyJhb...", "token_type": "Bearer", "expires_in": 3600 }
클라이언트가 보호된 루트나 자원에 접근하고 싶은 경우 사용자 에이전트는 일반적으로 Bearer
스키마를 사용하여 Authorization
헤더 안에 JWT를 보내야 한다. 헤더의 내용은 다음과 같을 수 있다:
Authorization: Bearer eyJhbGci...<snip>...yu5CSpyHI
이것은 무상태 인증 매커니즘으로서, 사용자의 상태는 서버 메모리에 전혀 저장되지 않는다. 서버의 보호된 루트는 Authorization 헤더 내의 유효한 JWT를 검사하며 이것이 존재하는 경우 사용자는 보호된 자원으로의 접근이 허가된다. JWT가 자가 수용적(self-contained)이므로 필요한 모든 정보는 JWT에 있으며 데이터베이스를 여러 번 조회할 필요를 줄여준다.
구현체
JWT 구현체는 수많은 언어와 프레임워크용으로 존재한다:
취약성
JSON 웹 토큰은 세션 상태를 포함할 수 있다. 그러나 프로젝트 요건이 JWT 기간 만료 이전에 세션 무효화를 허용하는 경우 서비스는 더 이상 토큰만으로 토큰 표명(token assertion)을 신뢰할 수 없다. 토큰에 저장된 세션이 폐지되지 않음을 확인하기 위해 토큰 표명은 데이터 스토어에 대해 검사되어야 한다. 이렇게 하면 토큰이 더 이상 무상태가 아니게 됨으로써 JWT의 주된 이점이 약화되는 결과를 낳는다.[34]
보안 상담가 팀 메클레인(Tim McLean)은 alg
필드를 사용하여 토큰의 유효성을 잘못 확인하는 일부 JWT 라이브러리의 취약성을 보고하였다. 이 취약점들이 패치가 되었으나 메클레인은 비슷한 구현체 혼동을 예방하기 위해 alg
필드를 구식 처리하는 것을 제안하였다.[35]
적절히 설계할 경우 개발자는 일부 주의를 기울이면 알고리즘 취약성을 해결할 수 있다:[36][37]
- JWT 헤더만으로 유효성을 확인하지 않을 것
- 알고리즘을 인지할 것
- 적절한 키 크기를 사용할 것
소프트웨어 보안 설계자 커트 로다머(Kurt Rodarmer)는 암호화 서명 키와 관련한 JWT의 추가적인 설계적 취약성, 그리고 라이브러리의 JSON 파서가 공격에 노출되는 중대한 취약성을 지적한다.[38] 이는 토큰 헤더를 표현할 때 JSON을 선택하는데 따른 직접적인 결과이며 완화가 어렵다.
같이 보기
각주
- ↑ 가 나 다 Jones, Michael B.; Bradley, Bradley; Sakimura, Sakimura (May 2015). JSON Web Token (JWT). IETF. doi:10.17487/RFC7519. ISSN 2070-1721. RFC 7519. https://tools.ietf.org/html/rfc7519.
- ↑ Nickel, Jochen (2016). 《Mastering Identity and Access Management with Microsoft Azure》. 84쪽. ISBN 9781785887888. 2018년 7월 20일에 확인함.
- ↑ 가 나 “JWT.IO - JSON Web Tokens Introduction”. 《jwt.io》. 2018년 7월 20일에 확인함.
- ↑ Sevilleja, Chris. “The Anatomy of a JSON Web Token”. 2015년 5월 8일에 확인함.
- ↑ “Atlassian Connect Documentation”. 《developer.atlassian.com》. 2015년 5월 18일에 원본 문서에서 보존된 문서. 2015년 5월 8일에 확인함.
- ↑ “draft-ietf-jose-json-web-signature-41 - JSON Web Signature (JWS)”. 《tools.ietf.org》. 2015년 5월 8일에 확인함.
- ↑ “draft-ietf-jose-json-web-encryption-40 - JSON Web Encryption (JWE)”. 《tools.ietf.org》. 2015년 5월 8일에 확인함.
- ↑ “draft-ietf-jose-json-web-algorithms-40 - JSON Web Algorithms (JWA)”. 《tools.ietf.org》. 2015년 5월 8일에 확인함.
- ↑ jwt-dotnet on 깃허브
- ↑ libjwt on 깃허브
- ↑ “liquidz/clj-jwt”. 《GitHub》 (영어). 2018년 5월 7일에 확인함.
- ↑ cljwt on 깃허브
- ↑ [1] on 깃허브
- ↑ “bryanjos/joken”. 《GitHub》 (영어). 2018년 5월 7일에 확인함.
- ↑ “dgrijalva/jwt-go”. 《GitHub》 (영어). 2018년 1월 8일에 확인함.
- ↑ “jwt: JSON Web Token (JWT) decoding and encoding”. 《Hackage》. 2018년 5월 7일에 확인함.
- ↑ auth0/java-jwt on 깃허브
- ↑ “kjur/jsrsasign”. 《GitHub》 (영어). 2018년 5월 7일에 확인함.
- ↑ “SkyLothar/lua-resty-jwt”. 《GitHub》 (영어). 2018년 5월 7일에 확인함.
- ↑ “jsonwebtoken”. 《npm》. 2018년 5월 7일에 확인함.
- ↑ ocaml-jwt on 깃허브
- ↑ Crypt::JWT on CPAN
- ↑ lcobucci/jwt on 깃허브
- ↑ Egan, Morten (2019년 2월 7일), 《GitHub - morten-egan/jwt_ninja: PLSQL Implementation of JSON Web Tokens.》, 2019년 3월 14일에 확인함
- ↑ “SP3269/posh-jwt”. 《GitHub》. 2018년 8월 1일에 확인함.
- ↑ “jpadilla/pyjwt”. 《GitHub》 (영어). 2017년 3월 21일에 확인함.
- ↑ net-jwt on pkgs.racket-lang.org
- ↑ JSON-WebToken on 깃허브
- ↑ ruby-jwt on 깃허브
- ↑ frank_jwt on 깃허브
- ↑ [2] on 깃허브
- ↑ jwt-scala on 깃허브
- ↑ [3] on 깃허브
- ↑ Slootweg, Sven. “Stop using JWT for sessions”. 《joepie91 Ramblings》. 2018년 8월 1일에 확인함.
- ↑ McLean, Tim (2015년 3월 31일). “Critical vulnerabilities in JSON Web Token libraries”. Auth0. 2016년 3월 29일에 확인함.
- ↑ “Common JWT security vulnerabilities and how to avoid them” (영어). 2018년 5월 14일에 확인함.
- ↑ Andreas, Happe. “JWT: Signature vs MAC attacks”. 《snikt.net》. 2019년 5월 27일에 확인함.
- ↑ Rodarmer, Kurt (2019년 7월 21일). “Obscure JWT Security Vulnerabilities”. rodarmer.com. 2019년 7월 25일에 원본 문서에서 보존된 문서. 2019년 7월 25일에 확인함.
외부 링크
- RFC 7519
- jwt.io – specialized website about JWT with tools and documentation, maintained by Auth0
- Spring Boot JWT Auth – Integrating JWT authentication with Spring framework
- JWT Security – JWT Security e-Book PDF (Polish language)
- Why do we need JWT in the modern web - a detailed article on the topic with some historical considerations