[개발이론] JWT (Json Web Token) 에 대한 이해

JWT는 사실 세션, 쿠키 방식의 인증 방법에서 자주 거론되는 인증, 인가 구현 기술 중 한 가지이다.

이름은 많이 들어왔지만 정확히 자세한 원리는 알지 못했던 상태라 이번 기회에 깊게 탐구해보고 알게 된 내용들을 정리해보려 한다.

 

1. JWT란

JWT(Json Web Token)는 서버, 클라이언트 간 권한을 확인하고 인가 (Authorization)를 할 때 사용하여 웹상에서 Json형태로 주고받는 토큰을 얘기한다.

기존의 세션(Session)과 쿠키(Cookie) 방식으로 클라이언트의 인가(Authorization)를 구현하면서 여겨지던 불편한 점을 개선하고 시스템 자원의 사용량이 줄이게 되어, 속도가 중요시되는 클라이언트와 API 개발을 할 때 많이 사용되는 방식이다.

 

2. JWT의 구조

JWT는 주로 Header, Payload, Signature로 구성이 되어있다.

아래의 그림을 확인해보며 설명을 진행하도록 하겠다.

 

2-1) Header

먼저 Header부분에서는 인증방식(Type)을 나타내는 "typ"와 암호화 알고리즘(Algorithm)을 나타내는 "alg"로 구성이 되어있다. Type의 경우 해당 구현 방식은 언제나 JWT로 되어있기 때문에 항상 JWT로 고정이 되어있고 Algorithm의 경우에는 Header와 Playload를 섞어 Signature로 암호화할 암호화 알고리즘을 표시하고 있다. 

이따가 다시 설명을 하겠지만 Header, Payload, Signature 3가지 구성요소는 모두 암호화되어있지만 Signature를 제외한 모든 부분은 누구나 해석이 가능하게 되어있고 

Header의 경우는 Base64로 암호화되어 저장이 되어있다.

 

2-2) Payload

Payload부분에서는 해당 토큰에 포함시킬 클레임(Claim) 정보를 포함하고 있다. 

주로 사용자의 정보의 한 '조각'으로 나누어 보관하며 Json방식으로 key : value의 쌍으로 이루어져 있다.

서버 측에서 해당 토큰을 확인할 때 어떤 사용자가 어떤 정보로 요청한 건지 알 수 있게 해주는 것이 가능하며, 보통 userNo 나 userName 또는 userLevel 등을 포함시킬 수 있는 Custom Claim과  해당 토큰의 발급자(iss), 만료일(iat) 같이 규격이 정해져 포함되는 Reserved Claim으로 구분이 된다.

주의할 점은 토큰은 사용자의 정보를 참고할 수 있을 최소한의 정보를 포함해야 하고, ID 나 Password 같은 민감한 정보는 절대로 포함해서는 안된다.

 

 

2-3) Signature

이전까지는 아무나 열어보고 Decode 할 수 있는 Header와 Payload 부분에 대해 설명했다면 Signature은 몹시 비밀스러운 녀석이다. 만약 클라이언트와 서버 간 통신을 할 때 누구나 해석이 가능하고 조작이 가능한 Header와 Payload만을 이용하여 인가(Authorization)가 이루어진다면 JWT를 사용할 이유 따윈 사실 없다고 봐야 한다.

그래서 나는 JWT구현에서 가장 중요한 녀석이 이 Signature라고 생각한다. 

Signature는 Header와 Payload 그리고 서버 개발자를 제외한 그 누구도 알아선 안 되는 Secret Key를 Header의 암호화 알고리즘에 따라 잘 짬뽕시켜둔 녀석이다. 따라서 누군가 Header나 Payload를 임의로 조작한다 한들 서버 측에서는 Signature에 들어간 정보와 비교하여 다르게 판단이 죄면 즉시 조작된 토큰이라는 것을 알 수 있게 된다.

 

 

3. JWT의 작동 방식

위의 그림에서 보이는 것처럼 사용자가 로그인을 진행했을 경우 서버는 DB에 저장된 사용자 정보 조각(Claim)들을 가져와 JWT토큰을 생성해 줘야 하고 그렇게 생성된 토큰을 다시 클라이언트에게 전달해줘야 한다.

그리고 매번 클라이언트가 요청할 때마다 서버는 JWT토큰의 유효성과 그 안에 포함되어있는 정보를 확인하도록 한다.

최대한 매끄러운 이해를 위해 위의 그림처럼 단순하게 설명을 했지만, 실제로는 토큰의 보호를 위해

JWT방식을 사용할 땐 Access Token과 Refresh Token을 사용하기 때문에 해당 부분에 대해서도 설명을 하도록 하겠다.

 

4. Access Token & Refresh Token

만약 클라이언트가 며칠 동안 같은 토큰을 이용하여 API를 사용한다고 가정해보자.

못된 해커 하나가 해당 클라이언트의 토큰을 어떻게 잘 빼와서 아무도 눈치 못 채게 몰래 서버를 이용한다고 가정하면 

클라이언트나 서버나 해당 토큰을 멈출 방법이 없게 된다.

이러한 문제가 있기 때문에, 접근용 토큰인 Access Token과 새로운 Access Token을 발급할 때 사용하는 Refresh Token을 나누어 사용해야 한다.

 

4-1) Access Token

 

앞에서 설명했던 userNo, userLevel과 같이 자주 사용되는 정보들을 담아두도록 하고 매번 서버로 요청을 할 경우 Access Token 하나만 가지고 인가(Authorization)를 하도록 한다. 하지만 해당 Access Token 은 정말로 사용자 본인이 맞는지 확인할 방법이 없어 아래와 같은 특징들을 가지고 유출 문제를 해결하도록 한다.

 

  * 최대 10분 ~ 1시간 정도의 짧은 시간을 유효시간으로 설정한다

  * 해커 놈은 Access Token을 잘 훔쳐갔다 해도 10분이나 1시간이 지난 상태이기 때문에 이미 토큰은 유효한 상태가 아니다.

  * 정상 사용자는 Refresh Token을 이용해 10분이 지났다면 새로운 Access Token을 발급받아 사용한다.

 

4-2) Refresh Token

 

Access Token이 만료되었을 경우 새로운 Access Token을 발급받을 수단이 있다.

바로 Refresh Token을 이용하는 것이다.

자주 노출이 되어 만료일이 매우 짧은 Access Token과는 다르게 Refresh Token은 노출이 적고

오직 새로운 Access Token을 발급받기 위하여 사용한다

특징은 아래와 같다..

 

  * 최대 150일 정도의 긴 시간을 유효시간으로 설정한다

  * Refresh Token의 상태 여부를 위해 서버 측 DB 내에 별도로 저장한다.

  * Access Token 갱신 이외에는 사용할 일이 없어야 한다.

 

4-3) Access Token과 Refresh Token의 작동 순서

 

여기까지 정리한 내용을 기반으로 클라이언트 App과 서버가 JWT, Access Token & Refresh Token을 통해 인가(Authenticate)를 구현한다면 아래와 같은 순서로 작동이 될 것이다.

 

  (1) 사용자가 App에서 로그인을 진행한다

  (2) 서버는 로그인 ID, PW 정보를 확인한다.

  (3) 이후 userNo, userLevel 등과 같은 Claim정보를 포함한 Access Token과 Refresh Token을 반환한다.

  (4) Refresh Token은 서버도 DB에 저장을 해두도록 한다.

  (5) 사용자의 App에서는 Access Token과 Refresh Token을 저장한다.

  (6) 사용자는 서버의 API를 사용할 때마다 Access Token을 Authorization Header에 넣어 요청을 한다.

  (7) 이후 실컷 사용하다가 만료기간이 지나버린 Access Token으로 서버에 요청을 한다.

  (8) 서버는 만료된 Access Token을 받을 경우 419 같은 오류로 응답을 한다.

  (9) 사용자 App은 419 오류를 응답받고 Refresh Token으로 /refresh라는 url에 요청을 한다.

  (10) 서버는 Refresh Token이 만료되었는지 그리고 DB에 저장된 상태 여부 확인하고 새로운 Access Token을 반환한다.

  (11) 사용자 App은 발급받은 Access Token을 새로 저장하고 바로 이전에 하려던 요청을 다시 시작한다.

  (12) (6) 번 이후로 돌아가 다시 실컷 사용한다

  (13) 이번에는 서버 측에서 전달받은 Refresh Token이 만료되었거나 DB에서 사용 금지 상태로 되어있다.

  (14) /refresh라는 url 결과로 419 가 반환되게 된다.

  (15) 사용자 App은 /refresh라는 url에 Refresh Token을 넣고 요청을 해도 419가 반환됐으므로 재로그인 유도.

 

 

5. 결론

JWT를 구현하면서 Refresh라는 개념까지 적용이 되어 구현하는 난이도가 꽤 번거로워진 것은 사실이다.

하지만 그만큼 보안성에 있어 매우 유익하기 때문에 빼려야 뺄 수 없는 녀석이기도 하다.

기존의 Session 방식이나 Cookie방식의 인가(Authenticate)를 사용하든 JWT를 사용하든 각각 장단점은 존재하기 때문에

앞으로 사용할 서비스에 따라 JWT를 이용하든 Session 방식을 이용하든 아니면 두 가지를 혼합하여 적절하게 이용하든,

잘 저울질을 하며 구현을 하면 좋을 것 같다.

꽤 기다란 내용의 포스팅이 되었던 것 같은데 이번 기회에 JWT방식에 대해 깊게 공부를 할 수 있는 기회가 되었던 것 같다.

여기서 마치도록 하겠다.