JSON Web Tokens(이하 jwt)는 웹 표준 RFC 7519에등록 되어있고 표준으로 쓰인다.
- RFC(Request For Comments) - 인터넷을 개발하는 데에 있어서 필요한 절차나 기술을 적어놓은 문서
- 7519 JSON Web Token (JWT). M. Jones, J. Bradley, N. Sakimura. May 2015.
(Format: TXT=63039 bytes) (Updated by RFC7797) (Status: PROPOSED
STANDARD) (DOI: 10.17487/RFC7519)
jWT 형식
jwt의 형식은 다음과 같은데 Header, Payload, Signature로 나뉘고 (.)으로 구분된다.
xxxxx.yyyyy.zzzzz
Header.Payload.Signature
Header
해더는 alg, typ 두가지로 되어있는데 typ은 토큰의 타입을 지정한다. 아래 예시에서는 JWT 타입.
alg에서는 해싱하는 알고리즘을 지정하는데 HMAC, SHA256 또는 RSA 같은것이 사용된다.
이 Header Json은 Base64Url로 인코딩되어 JWT의 첫 부분이 된다.
{
"alg": "HS256",
"typ": "JWT"
}
Payload
두번째 부분은 claim이 포함된 payload 부분이다. claim은 entity에 대한 추가 정보가 들어가 있고 3가지 타입(registered, public, and private claims)의 claim이 포함되어 있다.
Registered claims: registered claim은 강제적인것은 아니지만 유용하게 사용될 수 있도록 권장되는 부분이다. iss (issuer), exp (expiration time), sub (subject), aud(audience)등 이다.
Public claims: public claims은 jwt를 사용하는 사람에 의해 마음대로 정의될수 있다. 그러나 충돌을 피하기 위해서 ANA JSON Web Token Registry에서 정의하거나 충돌 방지 네임스페이스를 포함하는 URI로 정의해야 한다. Private claims: registered 나 public claim도 아닌 claim 이다. 이미 사전에 정의된 claim이다.
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
이 payload Json은 Base64Url로 인코딩되어 JWT의 두번째 부분이 된다.
이 토큰은 무단 변경으로 부터 보호는 되지만 누구나 읽을 수 있다. payload나 header에 중요한 정보를 암호화하지 않고 넣으면 안된다.
Signature
signature part를 만들기 위해서는 인코딩된 header, 인코딩된 payload, header에 명시된 알고리즘으로 sign 한다.
예를들어 다음 알고리즘을 사용한다면 HMAC SHA256 algorithm, signature 는 다음과 같이 생성된다.
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
signature는 메세지가 변하지 않았다는것을 증명하기 위해 쓰인다. private key로 sign된 토큰일 경우 jwt를 누가 보냈는지 확인 할 수 있다.
Putting all together
출력은 HTML 및 HTTP 환경에서 쉽게 전달할 수 있는 점으로 구분되는 Base64-URL 문자열 3개이며, SAML과 같은 XML 기반 표준에 비해 더 작다.
다음은 이전 헤더와 페이로드가 인코딩된 JWT이며, 비밀으로 서명된 JWT이다.
JWT를 사용하여 이러한 개념을 실제로 적용하려는 경우 jwt.io 디버거를 사용하여 JWT를 디코딩, 검증 및 생성할 수 있다.
How do JSON Web Tokens work?
인증에서 사용자가 성공적으로 로그인하면 JSON 웹 토큰이 반환된다. 토큰은 자격 증명이므로 보안 문제를 방지하기 위해 주의를 기울여야 하고 일반적으로 토큰을 필요한 시간보다 오래 보관해서는 안 된다.
사용자가 보호된 경로 또는 리소스에 액세스하고자 할 때마다 사용자 에이전트는 일반적으로 Bearer 스키마를 사용하여 Authorization header에 JWT를 전송해야 한다. 헤더의 내용은 다음과 같아야 한다.
Authorization: Bearer <token>
이는 경우에 따라 stateless 인증 메커니즘이 될 수 있습니다. 서버의 보호된 경로는 권한 부여 헤더에서 유효한 JWT를 확인하고, 이 경로가 있으면 사용자가 보호된 리소스에 액세스할 수 있습니다.
다음 다이어그램은 API 또는 리소스에 액세스하는 데 JWT를 얻고 사용하는 방법을 보여 준다.
1. 응용 프로그램 또는 클라이언트가 인증 서버에 권한을 요청한다. 이 작업은 서로 다른 권한 흐름 중 하나를 통해 수행된. 예를 들어 일반적인 OpenID Connect 호환 웹 애플리케이션은 권한 부여 코드 흐름을 사용하여 /oauth/authorate endpoint를 통과한다.
2. 권한이 부여되면 인증 서버는 응용프로그램에 대한 액세스 토큰을 반환한다.
3. 응용 프로그램은 액세스 토큰을 사용하여 보호된 리소스(예: API)에 액세스한다.
서명된 토큰을 사용하면 토큰을 변경할 수 없더라도 토큰에 포함된 모든 정보가 사용자 또는 다른 당사자에게 노출된다 토큰 안에는 비밀 정보를 넣지 말아야 한다.(비밀번호, 개인정보 등)
Why should we use JSON Web Tokens?
JSON Web Tokens (JWT)
Simple Web Tokens (SWT)
Security Assertion Markup Language Tokens (SAML).
json은 xml과 비교해봤을때 간단하다. 인코딩된 크기가 SAML보다 JWT가 더 작다. HTML, HTTP 환경에서 jwt는 좋은 선택이다.
JSON Web token on multiple platforms, especially mobile.
JWT and SAML 비교모습
