JWT

사용 배경

로그인 시 세션 이용이 기본 생각

IaaS 클라우드 서비스가 대중화 되면서 고사양 단일 서버 아키텍처에서 중-저사양 다중 서버 아키텍처로 변화

 

1. 서버 확장 시 세션 정보의 동기화 문제

• 서버가 여러개일 때 각 서버마다 세션정보 저장
• 로그인 시 ( 서버 1 ), 새로고침 시 ( 서버 2 ) 로 접근하게 된다면 서버는 인증이 안됬다고 판단

2. 세션을 각 서버에 저장하지 않고 세션 전용 서버 DB에 저장 시

• 모든 요청 시 해당 서버에서 조회하므로 DB 부하 야기

3. 웹/앱 간 상이한 쿠키-세션 처리 로직

• 웹/앱 간 쿠키 처리 방법이 다르고 또 다른 클라이언트 도입 시 쿠키-세션에 맞게 처리 필요

 

원리

1. 사용자가 로그인 시도
2. 서버가 요청 확인 후 Secret Key를 통해 Access Token 발급
3. JWT 토큰을 클라이언트에 전달
4. 클라이언트가 서버에 데이터 요청 시 JWP를 HTTP Header에 첨부
5. 서버에서 JWT 검증

 

구조

Header . Payload . Signature

 

1. Header : JWT 웹 토큰의 헤더 정보

 

{
	"alg" : "",
	"typ" : ""
}

 

• typ : 토큰 타입 ( JWT 만 존재 )
• alg : 해싱 알고리즘 ( 토큰 검증 시 사용, 헤더 암호화 X )

 

2. Payload : 토큰에 담을 정보

claim : 데이터 ( name : value )

registered ( 등록된 ) 클레임 : 토큰에 대한 정보들을 담기 위하여 이름이 이미 정해진 클레임

• iss : 토큰 발급자
• sub : 토큰 제목
• aud : 토큰 대상자
• exp : 토큰의 만료시간
• nbf : 토큰의 활성날짜
• iat : 토큰이 발급된 시간
• jti : JWT 고유 식별자 - 중복 방지 위해 사용

public ( 공개 ) 클레임 : 충돌을 방지하기 위해 URI 형식으로 저장

• URI : 특정 리소스를 식별하는 식별자
• URL : 웹 주소 ( URI 하위 개념 )

 

private ( 비공개 ) 클레임 : 사용자가 임의로 정한 정보

 

3. Signature : Header 와 Payload 의 데이터 무결성과 변조 방지를 위한 서명

• Header + Payload 를 합친 후, Secret 키와 함께 Header의 해싱 알고리즘으로 인코딩