JSON Web Token - MoonGyeongHyeon/Keyword_Study GitHub Wiki

JSON Web Token

JWT?

JSON Web Token(JWT)은 웹표준으로써 두 개체에서 JSON 객체를 사용하여 가볍고 자가수용적인(self-contained) 방식으로 정보를 안전성 있게 전달해준다.

자가수용적

JWT는 필요한 모든 정보를 자체적으로 지니고 있다. JWT 시스템에서 발급된 토큰은 토큰에 대한 기본 정보, 전달할 정보(유저 정보 등), 토큰이 검증됐다는 것을 증명해주는 signature 를 포함하고 있다.

수많은 프로그래밍 언어 지원

C, Java, Python, C++, C#, PHP, Ruby, Javascript 등 대부분의 주류 프로그래밍 언어에서 지원된다.

손쉬운 전달

JWT는 두 개체 사이에서 손쉽게 전달될 수 있다. 웹 서버의 경우, HTTP의 헤더에 넣어서 전달할 수도 있고 URL의 파라미터로 전달할 수도 있다.

사용하기 좋은 경우

다음과 같은 상황에서 JWT는 유용하게 사용될 수 있다.

• 회원 인증: JWT를 사용하는 가장 흔한 시나리오다. 유저가 로그인을 하면, 서버는 유저의 정보에 기반한 토큰을 발급하여 유저에게 전달한다. 그 후, 유저가 서버에 요청할 때마다 JWT를 포함하여 전달한다. 서버가 클라이언트에게서 요청을 받을 때마다 해당 토큰이 유효하고 인증됐는지를 검증하고, 유저가 요청한 작업에 권한이 있는지 확인하여 작업을 처리한다. 서버 측에서는 유저의 세션을 유지할 필요가 없다. 즉, 유저가 로그인되어있는지 안되어있는지 신경쓸 필요가 없고, 유저가 요청했을 때 토큰만 확인하면 되니, 세션을 관리할 필요가 없어 서버 자원을 아낄 수 있다.
• 정보 교류: JWT는 두 개체 사이에서 안정성있게 정보를 교환하기에 좋은 방법이다. 그 이유는, 정보가 sign이 돼있기 때문에 정보를 보낸 이가 바뀌진 않았는지, 또 정보가 도중에 조작되지는 않았는지 검증할 수 있다.

JWT 형식

JWT는 . 을 구분자로 3가지 문자열로 구성되어 있다. 구조는 다음과 같다.

헤더(header)

'헤더'는 두 가지의 정보를 지니고 있다.

• typ: 토큰의 타입을 지정한다. "JWT" 이다.
• alg: 해싱 알고리즘을 지정한다. 보통 HMAC SHA256 또는 RSA 가 사용되며, 이 알고리즘은 토큰을 검증할 때 사용되는 signature 부분에서 사용된다.

{
  "typ": "JWT",
  "alg": "HS256"	// HMAC SHA256 방식.
}

위 정보를 base64 로 인코딩하면 다음과 같은 결과가 나온다.

// node.js 환경

var Buffer = require('Buffer');

const header = {
    "typ": "JWT",
    "alg": "HS256"
};

// encode to base64
const encodedHeader = new Buffer(JSON.stringify(header))
    .toString('base64')
    .replace('=', '');

console.log('header: ',encodedHeader);
// header:  eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

• 간혹, base64로 인코딩할 때 'dA=='처럼 뒤에 '=' 문자가 하나 이상 붙을 때가 있다. 이 문자는 base64 인코딩의 'padding 문자'라고 부른다. JWT 토큰은 가끔 URL 파라미터로 전달될 때도 있는데, 이러한 padding 문자는 url-safe하지 못하기 때문에 제거해주어야 한다. padding 문자가 하나 생길떄도 있고, 두 개가 생길 때도 있는데 전부 제거해준다. (제거해도 디코딩할 때 전혀 문제가 되지 않는다.)

정보(payload)

'정보'는 토큰에 담을 정보가 들어있다. 여기에 담는 정보의 한 조각을 클레임(claim) 이라 부르고, 이는 'name / value'의 한 쌍으로 이루어져 있다. 토큰에는 여러 개의 클레임을 넣을 수 있다.

클레임의 종류는 다음과 같이 크게 세 분류로 나뉘어져 있다.

• 등록된(registered) 클레임: 등록된 클레임들은 서비스에 필요한 정보들이 아닌, 토큰에 대한 정보들을 담기 위해 이름이 이미 정해진 클레임들이다. 등록된 클레임의 사용은 모두 선택적(Optional)이며, 이에 포함된 클레임들은 다음과 같다.

  • iss: 토큰 발급자 (issuer)
  • sub: 토큰 제목 (subject)
  • aud: 토큰 대상자 (audience)
  • exp: 토큰의 만료시간 (expiration), 시간은 NumericDate 형식(예: 1480849147370)으로 되어있어야 하며, 언제나 현재 시간보다 이후로 설정되어 있어야 한다.
  • nbf: 'Not Before'를 의미하며, 토큰의 활성 날짜와 비슷한 개념이다. 여기에도 NumericDate 형식으로 날짜를 지정하며, 이 날짜가 지나기 전까지는 토큰이 처리되지 않습니다.
  • iat: 토큰이 발급된 시간(issued at), 이 값을 사용하여 토큰의 age 가 얼마나 됐는지 판단할 수 있다.
  • jti: JWT의 고유 식별자로, 주로 중복적인 처리를 방지하기 위해 사용된다. 일회용 토큰에 사용하면 유용하다.

• 공개(public) 클레임: 공개 클레임은 JWT 사용자 간 충돌을 방지하기 위해 사용한다. 그러므로 충돌이 방지된(collision-resistant) 이름을 가지고 있어야 한다. 충돌을 방지하기 위해서 URI 형식이나 네임 스페이스를 활용하여 클레임 이름을 짓는다.

  {
      "https://velopert.com/jwt_claims/is_admin": true
  }
  

• 비공개(private) 클레임: 양측 간(클라이언트 <-> 서버) 협의 하에 사용되는 클레임 이름들이다. 공개 클레임과는 달리 이름이 중복되어 충돌될 수 있으니 사용할 때 유의해야 한다. 전달하고자 하는 정보를 담는다.

  {
      "username": "velopert"
  }
  

완성된 정보는 아래와 같다.

{
    "iss": "velopert.com",		// 등록된 클레임.
    "exp": "1485270000000",		// 등록된 클레임.
    "https://velopert.com/jwt_claims/is_admin": true,		// 공개 클레임.
    "userId": "11028373727102",		// 비공개 클레임.
    "username": "velopert"			// 비공개 클레임.
}

base64 인코딩 결과는 아래와 같다.

var Buffer = require('Buffer');

const payload = {
    "iss": "velopert.com",
    "exp": "1485270000000",
    "https://velopert.com/jwt_claims/is_admin": true,
    "userId": "11028373727102",
    "username": "velopert"
};

// encode to base64
const encodedPayload = new Buffer(JSON.stringify(payload))
    .toString('base64')
    .replace('=', '');

console.log('payload: ',encodedPayload);
// payload:  eyJpc3MiOiJ2ZWxvcGVydC5jb20iLCJleHAiOiIxNDg1MjcwMDAwMDAwIiwiaHR0cHM6Ly92ZWxvcGVydC5jb20vand0X2NsYWltcy9pc19hZG1pbiI6dHJ1ZSwidXNlcklkIjoiMTEwMjgzNzM3MjcxMDIiLCJ1c2VybmFtZSI6InZlbG9wZXJ0In0

서명(signature)

JWT의 마지막 부분은 바로 '서명'이다. 서명은 헤더의 인코딩 값과 정보의 인코딩 값을 합친 후 주어진 비밀 키로 해싱하여 생성한다. 서명 부분을 만드는 흐름은 다음과 같다.

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

헤더와 정보의 인코딩 값 사이에 "."을 넣어주고 합친다.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJ2ZWxvcGVydC5jb20iLCJleHAiOiIxNDg1MjcwMDAwMDAwIiwiaHR0cHM6Ly92ZWxvcGVydC5jb20vand0X2NsYWltcy9pc19hZG1pbiI6dHJ1ZSwidXNlcklkIjoiMTEwMjgzNzM3MjcxMDIiLCJ1c2VybmFtZSI6InZlbG9wZXJ0In0

실제로 실행시켜 보도록 하자.

var Buffer = require('Buffer');
const crypto = require('crypto');

const header = {
    "typ": "JWT",
    "alg": "HS256"
};

// encode to base64
const encodedHeader = new Buffer(JSON.stringify(header))
    .toString('base64')
    .replace('=', '');

const payload = {
    "iss": "velopert.com",
    "exp": "1485270000000",
    "https://velopert.com/jwt_claims/is_admin": true,
    "userId": "11028373727102",
    "username": "velopert"
};

// encode to base64
const encodedPayload = new Buffer(JSON.stringify(payload))
    .toString('base64')
    .replace('=', '');

const signature = crypto.createHmac('sha256', 'secret')
    .update(encodedHeader + '.' + encodedPayload)
    .digest('base64')
    .replace('=', '');

console.log('signature: ',signature);
// signature:  WE5fMufM0NDSVGJ8cAolXGkyB5RmYwCto1pQwDIqo2w

최종적으로, 세 값을 "." 구분자로 합치게 되면 JWT 생성이 끝나게 된다.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJ2ZWxvcGVydC5jb20iLCJleHAiOiIxNDg1MjcwMDAwMDAwIiwiaHR0cHM6Ly92ZWxvcGVydC5jb20vand0X2NsYWltcy9pc19hZG1pbiI6dHJ1ZSwidXNlcklkIjoiMTEwMjgzNzM3MjcxMDIiLCJ1c2VybmFtZSI6InZlbG9wZXJ0In0.WE5fMufM0NDSVGJ8cAolXGkyB5RmYwCto1pQwDIqo2w

위의 값을 https://jwt.io/ 디버거에 붙여 넣으면 다음과 같은 결과를 얻을 수 있다. (JWT.IO는 브라우저 상에서 JWT을 검증하고 생성할 수 있도록 해주는 디버거 서비스이다.)

흐름

JWT을 이용한 요청/응답 흐름은 다음과 같다.

1. 클라이언트는 서버에 인증(로그인)을 요청한다.
2. 인증이 성공한다면, 서버는 비밀 키를 이용하여 JWT를 생성한다.
3. 서버는 생성한 JWT를 클라이언트 측으로 전달한다.
4. 클라이언트는 인증 헤더에 JWT를 추가하여 요청한다.
5. 서버는 JWT가 유효(validation)한지 확인하고, 유효하다면 JWT를 통해 클라이언트 측 정보를 얻는다.
6. 서버는 요청한 자원을 클라이언트에 전송한다.

JWT를 사용하면?

서버에서 토큰이 유효하다고 판단하면 클레임들을 디코딩해 정보를 가져올 수 있다. 즉, 서버의 메모리와 같은 별도의 위치에 따로 관리를 하지 않아도 된다는 것이다. 따라서 Stateless 한 서버를 만들 수 있게 된다. 그러므로 서버의 확장이 용이하고 요청 도메인에 관해 문제가 되지 않는다.

단, 클레임 셋이 증가하면 자연스럽게 토큰의 길이가 증가하게 되는데, 요청 헤더에 토큰을 삽입하는 방식이므로 과한 오버헤드가 발생할 수 있다.

Stateless vs Stateful

Stateful 서버는 클라이언트에게 요청을 받을 때마다 클라이언트의 상태를 계속 유지하고, 이 정보를 서비스 제공에 이용한다. 세션을 유지하는 웹 서버가 이에 해당한다. 예를 들어, 유저가 로그인을 하면 세션에 로그인이 됐다고 저장을 해두고 서비스를 제공할 때마다 그 데이터를 사용한다. 여기서 이 세션은 서버의 메모리에 담을 때도 있고, 데이터베이스에 담을 때도 있다.

Stateless 서버는 반대로, 상태를 유지하지 않는다. 단지 서버는 클라이언트 측에서 들어오는 요청으로만 작업을 처리한다. 이렇게 상태가 없을 경우, 클라이언트와 서버의 연결고리가 없기 때문에 서버의 확장성이 높아진다.