JWT

Json Web Token 의 줄임말이다

JWT의 종류

Access Token
Refresh Token

• Access token은 보호된 정보들(유저의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한부여에 사용한다. 클라이언트가 처음 인증을 받게 될 때(로그인 시), access, refresh token 두 가지를 다 받지만, 실제로 권한을 얻는 데 사용하는 토큰은 access token이다.
• 권한을 부여받는 데엔 access token만 가지고 있으면 된다. 하지만 access token을 만약 악의적인 유저가 얻어냈다면 어떻게 될까?
• 악의적인 유저는 자신이 00유저인 것 마냥 서버에 여러 가지 요청을 보낼 수 있다.
• 그러므로 access token은 유효기간을 짧게 준다.
• 유효기간을 짧게 주기 때문에 Access token의 유효기간이 만료된다면 refresh token을 사용하여 새로운 access token을 발급받는다. refresh token은 조금 더 길게 줘도 된다. 이것마저 짧게 준다면 매번 로그인 할때마다 번거로울 것이다.
• 유효기간이 긴 refresh token 마저 악의적인 유저가 얻어낸다면 큰 문제가 될 것이다. 상당히 오랜 기간 동안 access token이 만료되면 다시 발급받으며 유저에게 피해를 입힐 수 있기 때문이다. 그렇기 때문에 유저의 편의보다 정보를 지키는 것이 더 중요한 웹사이트들은 refresh token을 사용하지 않는 곳이 많다.
• 세상에 완벽한 보안은 없기 때문에 최대한 여러 방법으로 이용하여 보안을 지켜나가야 할 것이다.

JWT 구조

JWT는 위 그림과 같이 . 으로 나누어진 3부분이 존재한다.

Header

Header는 이것이 어떤 종류의 토큰인지(지금의 경우엔 JWT), 어떤 알고리즘으로 sign할지가 적혀있다. JSON Web Token이라는 이름에 걸맞게 JSON 형태로 이런 형태를 보실 수 있다.

{
  "alg": "HS256",
  "typ": "JWT"
}

• 이 JSON 객체를 base64 방식으로 인코딩하면 JWT의 첫 번째 부분이 완성된다.

Payload

• Payload에는 정보가 담겨 있다. 어떤 정보에 접근 가능한지에 대한 권한을 담을 수도 있고, 사용자의 유저 이름 등 필요한 데이터는 이곳에 담아 Sign 시킨다. Payload 에는 민감한 정보는 되도록 담지 않는 것이 좋다.

{
  "sub": "someInformation",
  "name": "phillip",
  "iat": 151623391
}

첫 번째 부분과 마찬가지로, 위 JSON 객체를 base64로 인코딩하면 JWT의 두 번째 블록이 완성된다.

Signature

• base64로 인코딩된 첫 번째, 그리고 두 번째 부분이 완성되었다면, 원하는 비밀 키(암호화에 추가할 salt)를 사용하여 암호화한다. base64 인코딩을 한 값은 누구나 쉽게 디코딩할 수 있지만, 서버에서 사용하고 있는 비밀키를 보유한 게 아니라면 해독해 내는데 엄청난 시간과 노력이 들어갈 것 이다.