📨

JWT (1)

태그

backend study

Session

•

장점

◦

JSESSIONID는 유의미한 값이 아니라 서버에서 세션 정보를 찾는 KEY로만 활용

◦

탈취되었다고 해서 개인정보가 탈취된건 아님

•

단점

◦

서버에 세션 정보를 저장할 공간이 필요

◦

서비스를 이용하는 사용자가 많다면 저장할 공간도 더 많이 필요

◦

분산 서버에서는 세션을 공유하는데 어려움이 있음

Token

•

세션의 단점을 해결하기 위해서 토큰으로 인증하는 방법을 사용

•

유저가 로그인을 하면 서버에서는 토큰을 생성한 뒤에 저장하지 않고(stateless) 토큰 값을 내려줍니다

•

이 토큰 값을 유저가 게시글 조회 요청을 할 때 함께 보내고 서버2(서버1이여도 상관없음)에서 이 토근을 의미있는 값으로 해석, 그리고 그 ㄱ밧을 토대로 유저를 인증

이처럼 가능한 이유는 세션 방식에서의 JSESSIONID는 key로만 활용될 수 있는 의미없는 값이 들어있지만 토큰은 유저를 설명할 수 있는 데이터(ex userID)를 포함하고 있음

•

장점

◦

세션관리를 할 필요가 없어 별도의 저장소가 필요하지 않음

◦

로그인을 제공한 서버 말고도 서버 분산 &클러스터 환경과 같은 확장성에 좋음

•

단점

◦

한번 제공된 토큰은 회수가 어려움

▪

세션의 경우에는 서버에서 세션을 삭제해버리면 브라우저의 JSESSIONID는 무용지물이 되어버림

▪

그러나 토큰은 세션을 저장하지 않기 때문에 한번 제공된 토큰을 회수할 수 없음

▪

그래서 보통 토큰의 유효기간을 짧게 함(개발환경에서는 길게 함 why? → 짧게 하면 클라이언트가 토큰을 자주 발급 받아야됨)

◦

토큰에는 유저의 정보가 있기 때문에 상대적으로 안정성이 우려됨

▪

민감정보를 토큰에 포함시키면 안됨(ex 패스워드, 개인정보)

JWT의 구조

토큰 방식에서 가장 잘 알려진 JWT가 있음, Json Web Token의 줄임말

HEADER.PAYLOAD.SIGNATURE

HEADER

Header는 JWT를 검증하는데 필요한 정보를 가진 객체

Signature에 사용할 암호화 알고리즘이 무엇인지, 토큰 타입, key의 ID가 무엇인지 정보를 담고 있음

이 정보를 Json으로 변환해서 UTF-8로 인코딩한 뒤 Base64 URL-Sage로 인코딩한 값이 들어가 있음

결과 값이 난해한 문자로 보이지만 암호화된 값은 아님.

PAYLOAD

실질적으로 인증에 필요한 데이터를 저장

데이터의 각각 필드들의 Claim이라고 함, 대부분의 경우에 Claim에 username을 포함함

인증할 때 payload에 있는 username을 가져와서 유저 정보를 조회할 때 사용해야하기 때문

또한 토큰 발행시간(iat)와 만료시간(exp)를 포함함

그 외에도 원하는 Claim을 얼마든지 추가 할 수 있지만 민감정보는 포함시켜서는 안됨

Payload 역시 Header와 마찬가지로 암호화되지 않음

Json으로 바꾼뒤 UTF-8로 인코딩하고 Base64로 변경한 데이터일 뿐

SIGNATURE

앞선 Header와 Payload는 암호화하지 않고 변환한 데이터

이렇게 Header와 Payload 생성 메커니즘은 너무 쉽고 누구나 만들 수 있는 데이터

따라서 저 두 개의 데이터만 있다면 토큰에 대한 진위 여부 판단은 전혀 이루어질 수 없음

그래서 JWT의 구조에서 가장 마지막에 있는 Signature는 토큰 자체의 진위여부를 판단하는 용도로 사용함.

Signature는 Header와 Payload를 합친뒤 비밀키로 Hash를 생성하여 암호화함

→ 헤더.페이로드 값을 SecretKey로 Hashing하고 Base64로 변경함

Key Rolling

JWT의 토큰 생성 메커니즘을 보다보면 Secret Key가 노출되면 사실상 모든 데이터가 유출될 수 있다는 것을 알 수 있음.

이러한 문제를 방지하기 위해서 Secret Key를 여러개 두고 Key 노출에 대비할 수 있음

Secret Key를 여러개를 사용하고 수시로 추가하고 삭제해줘서 변경한다면

Secret Key 중에 1개가 노출되어도 다른 Secret Key와 데이터는 안전한 상태가 됨

이걸 바로 Key Rolling이라고 함(Key Rolling이 필수는 아님)

Key Rolling에서는 여러개의 Secret Key가 존재 함

Secret Key 1개에 Unique한 ID를 연결시켜 두면 JWT 토큰을 만들 때 헤더에 kid를 포함하여 제공하고 서버에서 토큰을 해설할 때 kid로 Secret Key를 찾아서 Signature를 검증함

JWT Util 만들기

의존성 추가

JwtKey: JWT Secret Key를 관리하고 제공합니다, Key Rolling을 지원함

JwtUtils: JWT 토큰을 생성하거나 Parsing하는 메서드를 제공함

SigningKeyResolver:  JWT의 헤더에서 kid를 찾아서 Key(SecretKey + 알고리즘)를 찾아옴