JWT 로그인 테스트-1

JWT로 로그인을 구현하는 도중 어려움을 느껴 테스트로 구현해보고자 한다.

TableQ 프로젝트에서는 Spring Security로 로그인을 구현하여 별다른 어려움을 느끼지 못했으나

새로운 방식에 대한 접근이라 구현에서 어려움이 있다.

 

Spring Security 로그인 방식

• 기본적으로 세션 기반 인증을 사용
• 서버는 이를 검증한 후, 사용자의 정보를 저장한 세션을 생성
• 서버는 인증된 세션을 저장(예: 메모리나 데이터베이스에 저장)하고, 클라이언트는 세션 ID를 쿠키에 저장
• 클라이언트가 요청을 보낼 때 쿠키에 포함된 세션 ID를 함께 전송
• 서버는 세션 ID를 확인하여 사용자의 인증 상태를 확인
• 클라이언트의 수가 많아지면 세션 관리 부담이 증가할 수 있음

JWT 로그인 방식

• JWT는 인증과 관련된 정보를 토큰 형태로 저장하고 전달하는 방식
• 클라이언트는 JWT를 로컬 스토리지나 쿠키에 저장
• 서버는 토큰을 검증하여 인증 및 권한 부여를 처리
• 서버에서 세션을 관리할 필요가 없으므로 확장성이 높음
• 토큰 기반이기 때문에 다양한 클라이언트(웹, 모바일 등)와 통합하기에 적합
• JWT는 정보가 클라이언트에 저장되므로, 토큰이 탈취되면 문제 발생
• 이를 방지하려면 토큰 유효 기간을 짧게 설정하거나 갱신 메커니즘(Refresh Token)을 추가해야 함
• 토큰 자체가 암호화되지 않고 Base64로 인코딩되므로 민감한 정보를 포함하면 안됨

 

정리하자면 상황에 따라 적절한 로그인 방식을 선택하면 된다.

 

• Spring Security: 서버 기반 인증이 적합한 환경(단일 애플리케이션, 내부 서비스).
• JWT: 무상태 인증 및 확장성이 중요한 환경(다중 클라이언트 지원, 분산 서비스).

JWT 토큰 인증 과정

 

 

JWT는 .을 기준으로 헤더, 내용, 서명으로 이루어져 있다. 

헤더에는 토큰의 타입과 해싱 알고리즘을 지정하는 정보를 담는다.

{ 
    "type" : "JWT" // 토큰의 타입을 지정함. JWT라는 문자열이 들어가게 됨  
    "alg" : "HS256" // 해싱 알고리즘을 지정함
}

내용에는 토큰과 관련된 정보를 담는다. 내용의 한 덩어리를 클레임(claim)이라고 부르며

클레임은 키값의 한 쌍으로 이루어져 있다. 

클레임은 등록된 클레임, 공개 클레임, 비공개 클레임으로 나눌 수 있다.

 

- 등록된 클레임 : 토큰에 대한 정보를 담는 데 사용함

이름	설명
iss	토큰 발급자(issuer)
sub	토큰 제목(subject)
aud	토큰 대상자(audience)
exp	토큰의 만료시간(expiration). 시간은 NumericDate형식으로 하며 항상 현재 시간 이후로 설정
nbf	토큰의 활성 날짜와 비슷한 개념으로 Not Before를 의미함. NumericDate 형식으로 날짜를 지정하며, 이 날짜가 지나기 전까지는 토큰이 처리되지 않음.
iat	토큰이 발급된 시간으로 iat는 issued at을 의미함
jti	JWT의 고유 식별자로서 주로 일회용 토큰에 사용함

- 공개 클레임 : 공개되어도 상관없는 클레임을 의미함. 충돌을 방지할 수 있는 이름을 가져야 하며,

                        보통 URI로 클레임 이름을 설정함.

- 비공개 클레임 : 공개되면 안되는 클레임을 의미하며 클라이언트와 서버 간의 통신에 사용함

{
	"iss" : "emxaple@gmail.com", // 등록된 클레임
	"iat" : 1622370878, // 등록된 클레임
	"exp" : 1622372678, // 등록된 클레임
	"https://tableq.com" : true, // 공개 클레임
	"email" : "example@gmail.com", // 비공개 클레임
	"hello" : "안녕하세요!" // 비공개 클레임
}

 

 

서명은 해당 토큰이 조작되었거나 변경되지 않았음을 확인하는 용도로 사용하며,

헤더의 인코딩 값과 내용의 인코딩 값을 합친 후에 주어진 비밀키를 사용해 해시값을 생성한다.