본문 바로가기

NETWORK

JWT이해하기(JWT의 구조), 세션과 토큰의 차이점

출처: https://www.youtube.com/watch?v=JY6qEnGRXic&list=PL93mKxaRDidERCyMaobSLkvSPzYtIk0Ah&index=18  

함께 읽으면 좋은 글: https://engineerinsight.tistory.com/279  ( JWT Token를 저장할 가장 안전한 곳은? Session Storage VS Local Storage VS Cookie)

세션과 토큰의 차이점: https://velog.io/@ddangle/Session%EC%84%B8%EC%85%98%EA%B3%BC-Token%ED%86%A0%ED%81%B0%EC%9D%98-%EC%B0%A8%EC%9D%B4%EB%8A%94

JWT(Jason Web Token)란? 클레임이라고 불리는 정보를 JSON형태로 안전하게 전송하기 위한 토큰 기반의 표준. 인증과 정보교환에 사용됨. 서명이 되어 있어서 신뢰성을 확보할 수 있다. 

출처:  https://jwt.io/introduction

 

클라이언트측에서 처음로그인시 인증정보를 제공하면 서버에서는 Header, Payload, Signature로 구성된 JWT을 만들어 클라이언트에 전송해 준다. 브라우저 측에서는 이를 아래와 같은 로컬 스토리지(Local Storage)영역에 저장해 둔다.

 

이후에 클라이언트측에서 서버측으로 어떤 요청을 하면 브라우저의 Local Storage영역에 저장되어 있던 JWT을 함께 서버측으로 가져가 내가 누구인지를 알리고 요청을 하는 식이다.

여기서 서버측에서 내가 누구인지를 JWT을 가지고 알아낼 텐데 알아내는 구체적인 방법으로 HS256방식, 혹은 RSA방식(서버측의 개인키로 header와 payload부분을 잠가서 시그니처(Signature)를 만든다. 잠깐 복습하자면 JWT는 Header, Payload, Signature로 구성되며 Signature은 Header, Payload, 비밀키로 구성되지만 RSA방식을 사용하면 비밀키사용없이 공개키와 개인키를 사용한다. 그리고 그 잠근 내용을 애초에 로그인 시도시 정보가 맞으면 서버에서 클라이언트측으로 토큰 형식으로보내면 나중에 클라이언트가 어떤 요청을 할때 이 JWT과 요청을 함께 서버측으로 보내게 되는 것이다. 그리고 서버는 자신이 이전에 개인키로 잠가두었던 내용을 자신이 가지고 있는 공개키로 열어보게 되어 클라이언트의 신분을 확인하는 것이다. 확인해 보아 신분이 맞으면 클라이언트측에서 요청한 내용의 정보, 이 정보는 payload에 실려서 옴. 이 요청한 정보를 클라이언트측에 제공해 주게 되는 것이다)이 사용되는 것이다.

 

위와 같은 2가지 방식(HS256, RSA)중 보편적으로 사용되는 것은 HS256입니다. HS256방식에서 header와 signature부분을  HS256(암호화 방식으로써 HMAC과 SHA256의 합성어. 그냥 몽땅 암호화 방식이라고 기억하면 됨)방식으로 암호화 한 후에 header, payload, signature각각을 Base64로 인코딩함.

서버에서 Base64로 인코딩된 아래 그림의 왼쪽과 같은 JWT을 클라이언트측에 던지면 나중에 클라이언트가 요청시에 자신이 받았던 JWT를 서버로 함께 전송하고 서버는 이 JWT을 Base64를 이용해 디코딩하면 아래그림의 오른쪽과 같은 결과를 얻게 된다. 그리고 이 디코딩된 알아볼수 있는 내용에서 header와 payload와 시크릿키(코스)를 HS256방식으로 암호화한 결과가 Encoding된 아래 그림의 왼쪽 부분의 서명(Signature)부분과 같음을 확인함으로써 데이터의 무결성을 확보하는 것이다.

이에 대한 전반적인 자세한 내용은 페이지 상단의 링크 동영상에서 볼수 있다.