JWT(Json Web Token) 이해하기

2024. 5. 16. 20:23프로젝트


JWT (Json Web Token)

JWT(Jason Web Token)는 인터넷에서 정보를 안전하게 전송하기 위해 사용되는 방법 중 하나입니다. 단순히 말해서, JWT는 작은 정보 조각들을 안전하게 교환할 수 있도록 돕는 "티켓" 또는 "증명서"와 같습니다.

 

 

 

 


1. JWT의 구조와 무결성

이 티켓은 세 부분으로 구성되어 있으며, 각 부분은 점(.)으로 구분됩니다.

  1. Header (헤더): 헤더는 주로 토큰의 타입을 선언하고, 정보를 암호화하는 데 사용된 알고리즘의 종류를 말합니다. 예를 들어, 종종 "JWT"와 "HS256"라는 알고리즘 이름을 볼 수 있습니다.
  2. Payload (페이로드): 페이로드는 토큰 안에 실제로 담겨 있는 데이터입니다. 여기에는 사용자 ID, 사용 권한, 토큰이 만료되는 시간 등이 포함될 수 있습니다. 중요한 것은 이 부분에 민감한 정보를 넣지 않는 것이 좋다는 점입니다. 왜냐하면 이 데이터는 암호화되지 않고, 단지 인코딩만 되기 때문에 누구나 쉽게 읽을 수 있기 때문입니다.
  3. Signature (서명): 서명은 토큰이 안전하게 전송되었는지 확인하는 데 사용됩니다. 서버는 헤더와 페이로드를 특정 키를 사용하여 암호화하고, 이 결과를 서명으로 사용합니다. 이 서명을 통해 토큰이 중간에 변경되지 않았는지 확인할 수 있습니다.

이미지 출처 - https://cloud.google.com



 

구조를 살펴봤으니, 이제 아래 음흉한 사용자 병선이와 JWT 이야기를 통해 JWT가 무결성을 보장하는 방식을 살펴봅시다.

 

~

1. 서버는 사이트에 로그인한 병선이에게 줄 JWT를 만들기 시작했다.

 

 

2. 병선이의 사용 권한을 포함한 정보들(페이로드)과 서버만 알고 있는 비밀키를 붙여 문자열을 만들었고, 이 문자열을 암호화 알고리즘을 거쳐 가공하여 서명을 생성했다. 여기서 중요한 사실은 비밀키인 "asdf12nnt3t41"을 서버만 알고있다는 점이다.

 

 

 

 

3. 자 이제 서명을 포함한 JWT가 완성됐고, 병선이에게 보내줬다. 이제 병선이는 서버와 통신할 일이 생긴다면 통신할 때마다 로그인하는 대신 이 티켓을 보여주며 본인이 인가된 사용자임을 증명할 것이다.

 

 

4. 하지만 티켓(JWT)을 받은 병선이는 심심한 나머지 티켓(JWT)의 페이로드, 즉, 티켓에 포함된 자신의 정보들 중 사용 권한 부분을 "유저 -> 관리자"로 조작하였고, 곧바로 다음 통신때 서버에게 조작된 티켓을 보여주며 자신이 관리자라 주장했다.

 

 

5. 서버는 병선이에게 받은 티켓에 포함된 암호화 알고리즘, 페이로드, 그리고 서버만이 알고있는 비밀키를 사용해 처음 서명을 만들때와 같은 방식으로 다시 서명을 만들었다. 당연히 서버가 직접 만들어 보내줬던 서명과는 다른 서명이 나왔고, 서버는 티켓이 조작됐음을 눈치챘다.

 

6. 완벽히 속이기 위해선 서명 부분도 조작해야 한다는 것을 깨달은 병선이는 조작된 페이로드를 사용해 본인이 직접 서명을 생성하고자 마음 먹는다. 아뿔싸, 비밀키도 같이 넣고 돌려야 하는데 이건 서버만이 알고있다. 병선이는 좌절했다.

 

위와 같은 방법으로 JWT가 조작 여부를 판단하여 무결성을 보장하기 때문에 서명이 중요합니다.

 

 


2. JWT의 사용 

이제 JWT가 실제로 어떻게 사용되는지 살펴봅시다.

 

  1. 로그인: 사용자 인증 후 JWT와 리프레시 토큰을 클라이언트(쿠키 OR 로컬스토리지 OR 세션스토리지)에 저장.
  2. 인증된 요청: 클라이언트는 데이터를 요청할 때마다 헤더에 JWT를 포함하여 서버에 요청하고, 서버는 JWT를 검증하여 응답.
  3. 토큰 갱신: JWT가 만료되면 리프레시 토큰을 사용하여 새로운 JWT를 발급받음. (토큰의 만료와 리프레시 토큰에 관한 자세한 내용은 이후 개별적으로 포스팅할 예정입니다.)
  4. 로그아웃: 클라이언트는 리프레시 토큰을 서버에 보내 로그아웃하고, 저장된 토큰을 삭제.

플로우 차트

 

 

 


 

이상으로 JWT의 구조와 실제 로그인 프로세스에서 사용되는 양상을 살펴보았습니다.

 

다음 포스팅에는 JWT를 AccessToken과 RefreshToken으로 나누어 더 자세히 알아보고,

현재 프로젝트에서 어떻게 사용되고 있는지 실제 코드와 함께 살펴보는 포스팅과

토큰을 저장하는 창고인 로컬 스토리지, 세션 스토리지, 쿠키의 차이점들에 대한 포스팅을 업로드 하겠습니다.

 

감사합니다.