팀 프로젝트에서 로그인 기능을 구현하면서 인증 방식을 고민하게 됐다.
처음에는 세션 기반 인증을 사용할까 고민했지만, 결국 JWT 기반 인증 방식을 선택했다.
하지만 막상 구현해보니 단순히 로그인 기능을 만드는 것보다 토큰 관리와 보안 문제에서 생각보다 많은 고민이 생겼다.
이번 글에서는 JWT 로그인 구조와 Access Token / Refresh Token을 사용하면서 고민했던 점들을 정리해보려고 한다.
JWT란 무엇인가
JWT(Json Web Token)는 사용자 인증 정보를 토큰 형태로 전달하는 방식이다.
기존 세션 방식과 가장 큰 차이는 이것이다.
세션 인증
서버에 로그인 상태 저장JWT 인증
토큰 안에 사용자 정보를 담아서 인증즉 서버가 로그인 상태를 저장하지 않아도 된다.
그래서 Stateless 인증 방식이라고 부른다.
JWT 구조
JWT는 크게 3가지로 구성된다.
Header
Payload
Signature예시
xxxxx.yyyyy.zzzzz각 역할은 다음과 같다.
Header
토큰 타입과 암호화 알고리즘 정보
Payload
사용자 정보
예시
userId
email
roleSignature
토큰 위조 방지를 위한 서명
JWT 로그인 흐름
JWT 로그인 과정은 보통 다음과 같다.
1. 사용자 로그인 요청
2. 서버에서 사용자 인증
3. JWT 토큰 발급
4. 클라이언트가 토큰 저장
5. API 요청 시 토큰 전달API 요청 시 보통 이렇게 전달한다.
Authorization: Bearer {JWT}서버에서는 토큰을 검증한 후 요청을 처리한다.
Access Token / Refresh Token 구조
JWT 인증을 구현할 때 가장 많이 사용하는 방식이
Access Token
Refresh Token구조이다.
Access Token
특징
- 짧은 유효시간
- API 요청 시 사용
예
15분
30분Refresh Token
특징
- Access Token 재발급
- 긴 유효시간
예
7일
14일로그인 구조는 보통 이렇게 된다.
로그인
↓
Access Token 발급
Refresh Token 발급
↓
Access Token 만료
↓
Refresh Token으로 재발급JWT를 사용하면서 생긴 고민
JWT 인증을 구현하면서 몇 가지 고민이 생겼다.
1. 토큰 저장 위치
토큰을 어디에 저장할 것인가?
대표적인 선택지는
LocalStorage
Cookie이다.
하지만 LocalStorage는 XSS 공격 위험이 있다.
그래서 최근에는
HttpOnly Cookie방식을 많이 사용한다.
2. 로그아웃 처리
JWT는 Stateless 방식이라 서버에 세션이 없다.
그래서 로그아웃을 해도 토큰이 살아있다.
이 문제를 해결하기 위해 보통
토큰 블랙리스트
Redis 관리같은 방법을 사용한다.
3. Payload에 어디까지 넣어야 할까
JWT Payload에는 사용자 정보를 넣을 수 있다.
예
userId
email
role하지만 데이터를 많이 넣으면 토큰이 커진다.
그래서 보통
userId
role정도만 넣는 경우가 많다.
4. Refresh Token 저장 위치
Refresh Token을 어디에 저장할지도 고민이었다.
대표적인 방법은
DB 저장
Redis 저장이다.
팀 프로젝트에서는 관리 편의성을 위해 DB에 저장하는 방식을 사용했다.
JWT를 사용하면서 느낀 점
JWT는 확실히 확장성과 분산 시스템에서 장점이 있는 인증 방식이다.
하지만 단순히 로그인 기능을 구현하는 것만 보면
Session 방식이 더 단순할 수도 있다.특히 토큰 관리와 보안 문제까지 고려하면 JWT 구조를 제대로 설계하는 것이 중요하다고 느꼈다.
마무리
JWT 인증을 구현하면서 느낀 점은 이것이다.
JWT는 단순한 토큰 인증이 아니라 토큰 관리 구조를 설계하는 문제에 가깝다.
Access Token / Refresh Token 구조와 토큰 보안 문제까지 고려해야 안정적인 인증 시스템을 만들 수 있다.
다음에는 실제로 Spring Security에서 JWT 인증을 구현하는 과정도 정리해볼 예정이다.
