[JWT] JWT(JSON Web Token)란?

JWT(JSON Web Token) :

데이터를 안전, 간결하게 전송하기 위해 고안된 인터넷 표준 인증 방식

 

토큰 인증 방식에서 가장 범용적으로 사용됨

 

 

*간략 순서

JSON 포맷의 토큰 정보를 인코딩

⬇

인코딩 된 토큰 정보를 Secret Key로 서명(Sign)한 메세지를

Web Token으로써 인증 과정에 사용

 

---

JWT의 종류

 

1. 액세스 토큰 (Access Token)

2. 리프레시 토큰 (Refresh Token)

 

: 클라이언트가 로그인 시 두 가지 모두 받음

 

 

Access Token

- 보호된 정보들에 접근할 수 있는 권한 부여에 사용

- 짧은 유효기간

(Access Token 탈취 될 경우 오래 쓰지 못하게 하려고)

 

⬇

 

Refresh Token

- Refresh Token 을 이용하여 새로운 Access Token 발급 받음

 

---

JWT의 구조

 

 

: . 으로 나누어진 세 부분 존재 (Header / Payload / Signature)

 

 

 

1) Header : 토큰의 종류, Sign 할 알고리즘 종류 정의

 

2) Payload : 서버에서 활용 가능한 사용자의 정보

* 민감한 정보를 담지 않을 것 (base64 : 쉽게 디코딩 가능)

 

* Header, Payload 를 base64 로 인코딩하여 JWT 블록을 완성한다

 

3) Signature : 토큰의 위변조 유무 검증

 

{ Header를 base64로 인코딩 한 값 + Payload를 base64로 인코딩한 값 + 원하는 비밀 키 (Secret Key)) }

를 Header에서 지정한 알고리즘으로 단방향 암호화 수행

 

---

JWT 사용 예시

 

새로 다운받은 A라는 앱이 Gmail과 연동되어 이메일을 읽어와야 할 경우,

 

사용자는

1. Gmail 인증서버에 로그인 정보(아이디, 비밀번호)를 제공합니다.
2. 인증에 성공할 경우, JWT를 발급받습니다.
3. A 앱은 JWT를 사용해 해당 사용자의 이메일을 읽거나 사용할 수 있습니다.

➡ 여러 서버를 사용해도 단 하나의 토큰을 이용하면 되는 것!

권한 부여에 매우 용이하다!

 

 

---

토큰기반 인증 절차

 

* JWT 토큰 생성시 Access Token, Refresh Token 둘 다 생성

* Token 내 Payload - 사용자 식별 정보, 사용자 권한 정보 등...

* 클라이언트 토큰 저장 위치 : Local Storage, Session Storage, Cookie 등

 

---

JWT를 통한 인증의 장점

 

1. 상태를 유지하지 않고, 확장에 용이한 애플리케이션 구현에 용이
   : 서버는 토큰이 정상적으로 검증되는지만 판단! 클라이언트 정보 저장 필요 X
   
   * 세션 방식이라면 모~든 서버가 사용자의 세션 정보 공유해야 함!
   * 토큰 방식? 하나의 토큰으로 여러 서버에서 인증 가능! (request 마다 토큰을 헤더에 포함!)
   
2. 클라이언트가 request 전송할때마다 자격 증명 정보 전송할 필요가 없음
   : 토큰 만료되기 전까지 한 번의 인증만 수행~
   
   
3. 인증 담당 시스템을 다른 플랫폼으로 옮기는 것 용이
   : Github, Google, 토큰 생성용 서버, 토큰 관련 작업 외주(?),...
   
   
4. 권한 부여에 용이
   : payload 에 사용자 권한 정보 포함시킴

 

---

JWT를 통한 인증의 단점

1. Payload - 디코딩이 용이
   : 토큰 탈취시 😲
   
   
2. 토큰의 길이 ⬆, 네트워크에 부하 ⬆
   : request 전송할 때 마다 길이가 긴 토큰 함께 전송!!
   
   
3. 토큰 자동으로 삭제 X
   : 만료 시간 관리해야 함