JWT

JWT : Json Web Token

을 먼저 이해하기 위해서는 세션과 토큰에 대해 먼저 알아야 한다.

 

 

세션과 토큰

Session

유저의 정보를 DB에 저장하고 상태를 유지하는 도구

• 장점

서버에 저장되서 노출 위험 X

 

• 단점

요청이 있을때마다 매번 DB를 확인해야 한다.

DB에 세션을 저장해야 해서,

Horizontal Scaling(같은 서버를 여러개 복제시켜 트래픽을 분산)이 어렵다.

⇒ Horizontal Scaling을 사용한다면, 세션을 중복저장해야 하는 문제가 있음

⇒ Redis 캐싱 중앙화 하면 뭐 또 이 문제가 해결 될수도 있음..ㅋㅋㅋ

 

 

세션 로그인 요청

클라이언트는 쿠키안에다가 세션을 저장해 놓는다.

 

세션 데이터 요청

1. 데이터 요청 + 쿠키를 같이 보냄
2. 서버에서 쿠키를 받아서 안에 있는 세션 검증

세션 Flow

 

 

토큰

유저의 정보를 Base64로 인코딩 하여 String 값으로 만듬

 

Token 의 가장 큰 차이점이자 장점

=> Token 은 DB에 저장되지 않고, Signature 값을 이용해 검증 가능. 그래서 검증할때마다 매번 DB를 들여다볼 필요 없음.

Token 로그인 요청

DB 를 거치지 않는다. (DB에 세션 저장하는거 안함)

 

데이터 요청 + 토큰 전송

 

Token 플로우

 

 

---

 

 

JWT 란?

1. Header : 토큰의 종류와 암호화 알고리즘 등 토큰에 대한 정보가 들어가 있음
2. Payload : 발행일, 만료일, 사용자 ID 등 사용자 검증에 필요한 정보가 들어 있음
3. Signature : Base64로 인코딩 된 Header , Payload 를 알고리즘으로 사인한 값이 들어 있음. 이 값을 기반으로 토큰이 발급 된뒤, 조작되어 있는지 확인함.

 

JWT의 생김새

두개의 . 으로 구분

JWT to Json (서로 변환)

서로 변환하여 내용 확인 가능.

 

signiture 의 secret 값이 일치해야지만 JWT가 위조되지 않았다고 판단 할수 잇음.

signiture 만 검증 가능하다면, 내부 Header , payload 모두 신뢰 가능. = 위변조 하기 사실상 어려움

 

 

JWT 검증 사이트

JWT.IO

 

 

---

 

 

Refresh , Accecss Token

• 액세스 토큰 : 짧고 자주 사용 -> 유효기간이 짧음
• 리프레쉬 토큰 : 액세스 토큰 새로 발급할때만 사용 -> 유효기간이 김~

 

과정

로그인시 받는 Token 의 형태

로그인 하면서, 액세스 토큰과 리프레쉬 토큰을 받음

: Basic $token

 

 

API 요청 하면서 Header에 엑세스 토큰 전달

: Bearer $accessToken

 

 

리프레쉬 토큰은 액세스 토큰을 재발급 하는 url 로 요청한다.

: Bearer $refreshToken

 

 

엑세스 토큰이 만료된 상황에서의 전개 과정

1. api 요청
2. 만료 응답 401
3. 액세스 토큰 재발급 요청 url + 리프레쉬 토큰 과 같이 서버로 전달
4. 리프레쉬 토큰 검증
5. 엑세스 토큰 재발급 해서 클라이언트에게 전달
6. 새로 받은 엑세스 토큰으로 다시 api 요청

리프레쉬 토큰도 만료 되었으면, 아예 앱 자체에서 로그아웃 시켜야 함.