[Cs] session과 jwt 토큰에 대해 알아보자

     

목차

1. session이란
2. jwt 토큰
3. session vs jwt 토큰 
4. jwt 토큰의 베이스 인코딩
5. Refresh Token 과 Access Token

 

 

session이란

유저의 정보를 데이터베이스에 저장하고 상태를 유지하는 도구

 

session의 특징

session은 특수한 id값으로 구성되어있다.

 

session은 서버에서 생성되며 클라이언트에서 쿠키를 통해 저장된다.

 

클라이언트에서 요청을 보낼때 session ID를 같이 보내면 현재 요청을 보내는 사용자가 누구인지 서버에서

알 수 있다.(요청마다 매번 아이디와 비밀번호를 물어볼 필요가 없다.)

 

session id는 데이터베이스에 저장되기 때문에 요청이 있을 때마다 매번 데이터베이스를 확인해야 한다.

 

서버에서 데이터가 저장되기 때문에 클라이언트에 사용자 정보가 노출될 위험이 없다.

 

데이터베이스에 session을 저장해야 하기 때문에 Horizontal Scailing이 어렵다.

 

 

세션 생성 방식

1. 클라이언트가 api서버에게 id/ pass 전송
2. api의 서버의 검증
3. api서버로 부터 데이터베이스에 세션 생성 및 저장
4. api 서버가 쿠키를 클라이언트에게 전송

세션 사용 방식

1. 클라이언트가 api 서버에게 쿠키 전송
2. api서버가 자체적 검증
3. api서버가 데이터베이스에서 세션 검색
4. 데이터베이스가 유저정보로 응답
5. api서버가 데이터베이스 데이터 요청후 응답을 받음
6. api서버가 클라이언트에게 데이터를 전송

 

 

jwt 토큰

유저의 정보를 Base64로 인코딩된 string 값에 저장하는 도구

 

jwt 토큰의 특징

jwt 토큰은 header payload signature로 구성되어있으면 base 64로 인코딩 되어있다.

 

jwt 토큰은 서버에서 생성되며 클라이언트에서 저장된다.

 

클라이언트에서 요청을 보낼 때 jwt 토큰 id를 같이 보내면 현재 요청을 보내는 사용자가 누구인지 서버에서

알 수 있다.

 

jwt 토큰은 데이터베이스에 저장되지 않고 signature 값을 이용해서 검증할 수 있다. 그래서

검증할때마다 데이터베이스를 매번 들여다볼 필요가 없다.

 

정보가 모두 토큰에 담겨있고 클라이언트에서 토큰을 저장하기 때문에 정보 유출의 위험이 있다.

데이터베이스가 필요없기 때문에 Horizontal Scailing이 쉽다.

 

 

jwt 토큰 생성 방식

1. 클라이언트가 id/pass를 api서버에게 전송
2. api 서버의 검증
3. api 서버가 클라이언트에게 토큰 전송

 

jwt 토큰 사용 방식

1. 클라이언트가 api 서버에게 토큰 전송
2. api서버의 자체 검증
3. api서버가 데이터베이스에게 데이터 요청
4. 데이터베이스가 api서버에게 결과 응답
5. api서버가 클라이언트에게 데이터 전송

 

 

session vs jwt 토큰 

비교 요소	session	jwt token
유저의 정보를 어디에서 저장하고 있는가?	쿠키	토큰
클라이언트에서 서버로 보내는 정보는?	쿠키	토큰
유저 정보를 가져올 때 데이터베이스를 확인해야 하는가?	확인 필요	토큰의 payload에 들어있는 정보만 필요할 경우 확인 불필요
클라이언트에서 인증 정보를 읽을 수 있는가?	불가능	가능
horizontal scailing이 쉬운가?	어려움	쉬움

 

 

jwt 토큰의 베이스 인코딩

jwt 토큰에 대해 자세히 알아볼 수 있는 사이트

https://jwt.io/

JWT.IO

 

 

헤더는 JWT의 타입(JWT)과 서명 알고리즘(예: HMAC SHA256 또는 RSA)을 정의합니다.

 

페이로드는 JWT의 실제 데이터를 담고 있는 부분입니다. 이 부분은 보통 **클레임(Claim)**이라고 불리며, 다양한 정보를 담을 수 있습니다. 클레임은 크게 등록된 클레임(Registered Claims), 공개 클레임(Public Claims), **비공개 클레임(Private Claims)**으로 나눠집니다.

 

서명은 토큰의 무결성을 보장하고, 해당 토큰이 위조되지 않았음을 확인하는 부분입니다. 서명은 헤더와 페이로드를 기반으로 비밀 키(또는 공개/비공개 키 쌍)를 사용하여 생성됩니다.

 

위에 값 중에서 payload를 변형하게 되면 보라색깔의 문자열뿐만 아니라 다른 모든 색도 바뀌게 되는데

이는 시그니쳐의 비밀번호를 모른다면 인코딩된 값이 아예 달라져 변조를 감지할 수 있습니다.

 

 

Refresh Token 과 Access Token

두 토큰 모두 JWT 기반이다.

 

Access Token은 api 요청을 할 때 검증용 토큰으로 사용된다. 즉, 인증이 필요한 api를 사용할때는 꼭 Acess Token을 Header에 넣어서 보내야 한다.

 

Refresh Token은 Access Token을 추가로 발급할 때 사용된다. Access Token을 새로고침하는 기능이 있기 때문에

Refresh Token이라고 부른다.

 

Access Token은 유효기간이 짧고 Refresh Token은 유효기간이 길다.

 

자주 노출되는 Access Token은 유효기간을 짧게해서 Token이 탈취돼도 해커가 오래 사용하지 못하도록 방지할 수 있다.

 

상대적으로 노출이 적은 Refresh Token의 경우 Access Token을 새로 발급받을 때만 사용되기 때문에 탈취 가능성이 작다.