JWT(JSON Web Token)란?

1. JWT(JSON Web Token)란?

인증에 필요한 사용자의 정보를 JSON개체로 안전하게 전송하기 위한 암호화된 토큰

 

2. 세션(Session)과의 인증 차이

세션 기반 인증

[클라이언트] 유저 로그인 =>

[서버] 유저정보 확인 =>

[서버] 맞을 시 세션 DB에 유저의 세션 아이디와 정보 등을 저장=>

[서버] 유저에게 세션아이디를 응답 =>

[클라이언트] 세션아이디를 쿠키에 저장 =>

[클라이언트] 서버에 다른 요청(헤더에 세션 아이디를 포함) =>

[서버] 요청받은 세션아이디를 이용하여  DB를 확인하고 세션이 유효한지 확인 =>

[서버] 유효 여부에 따라 클라이언트에게 응답

 

토큰 기반 인증

[클라이언트] 유저 로그인 =>

[서버] 유저정보 확인 =>

[서버] 맞을 시 유저정보가 담긴 ACCESS 토큰을 발행하여 클라이언트에게 전달 =>

[클라이언트] 토큰을 쿠키 or 로컬스토리지???에 저장 =>

[클라이언트] 서버에 다른 요청(헤더에 토큰을 포함) =>

[서버] 요청받은 ACCESS 토큰이 유효한지 확인 =>

[서버] 유효 여부에 따라 클라이언트에게 응답

 

차이 :  유저의 상태에 대한 정보를 서버에 저장하냐(세션 기반) 저장을 안하냐(토큰 기반)의 차이

 

세션 기반

장점

유저에 대한 상태를 서버가 관리하여 보안적으로 세션에 비해 뛰어나다

예) 특정한 유저를 로그아웃 시키고 싶을 경우 세션 테이블에 저장되어있는 유저의 정보만 삭제해버리면 로그아웃 되버림

 

단점

서버에 유저의 상태를 저장하기 때문에 유저가 증가할 수록 과부화가 늘어남.서버가 분산되어 있을 경우에도 어떤 서버에서 찾냐의 문제가 생김?

 

토큰 기반

장점

서버는 토큰에 대한 유효여부만 확인하면 되기때문에 세션기반에 비해서 작업이 가볍고, 서버가 분산 되어있더라도 상관없음

 

단점

세션기반에 비해서 보안이 약함 ACCESS TOKEN이 탈취되면 서버에서 아무런 방어를 할 수 없음  =>

대처를 위해 refresh 토큰이 나옴

 

-- 토큰 기반 인증 중 왜 jwt를 사용하는가?

비교대상

SWT (Simple Web Tokens): 단순 웹 토큰 => xml

SAML (Security Assertion Markup Language Token) :  보안검증 마크업 언어 => xml

JWT => JSON

1. JSON이 XML보다 인코딩 될때 크기가 작아짐

2. SWT대칭키만을 이용, JWT와 SAML은 공개/ 개인 키 쌍을 사용할 수 있음.

3. 클라이언트측에서 JSON과 XML 중 파싱하기에 JSON이 용이

 

 

토큰 기반 인증 (refresh 토큰 사용)

 

 

[클라이언트] 유저 로그인 =>

[서버] 유저정보 확인 =>

[서버]

맞을 시 유저정보가 담긴 Access(짧은 유효기간 1시간), Refresh토큰(긴 유효기간 2주)을 발행하여 클라이언트에게 전달 =>

[클라이언트] 각 토큰을 쿠키 or 로컬스토리지???에 저장 =>

[클라이언트] 서버에 다른 요청(헤더에 Access토큰을 포함) =>

[서버] 요청받은 Access 토큰이 유효한지 확인 =>

 

======유효기간 만료시======

[서버] 클라이언트에게 유효 기간 만료 응답

[클라이언트] Access, Refresh토큰을 가지고 다시 서버에게 Access토큰 재발행 요청

[서버] Access, Refresh토큰 유효한지 확인 하여 유효 여부에 따라 클라이언트에게 응답=>

******참조******

https://tansfil.tistory.com/m/59

 

 

 

 

3. 토큰의 형태

-토큰의 타입을 명시하는 header

-토큰에 담을 정보가 들어있는 payload

-서명

*****참조*****

https://velopert.com/2389

[JWT] JSON Web Token 소개 및 구조 | VELOPERT.LOG

 

header와 payload를 해싱하여 만들어진 토큰