1. 토큰 기반 인증이란?
사용자가 서버에 접근할 때, 인증된 사용자인지 확인하는 방법은 크게 두 가지로 나뉜다.
(1) 토큰 기반 인증 vs 세션 기반 인증
1️⃣ 토큰 기반 인증
클라이언트가 토큰을 보관하고 요청 시 전송 → 서버는 무상태성 유지
2️⃣ 세션 기반 인증
서버가 사용자 정보를 세션으로 저장 → 상태 유지 필요
1️⃣ 토큰 기반 인증
토큰은 서버에서 클라이언트를 구분하기 위한 값으로, 서버에서 토큰을 생성하여 클라이언트에 제공한다.
클라이언트를 해당 토큰을 저장하고 있다가 API 요청시 함께 전송한다.
서버는 토큰을 검증하여 유효한 사용자인지 확인한다.
서버가 인증 정보를 저장하지 않기 때문에 무상태성을 유지할 수 있고, 확장성이 뛰어나다.
2️⃣ 세션 기반 인증
서버는 사용자마다 세션을 생성하여 사용자의 정보를 DB 또는 메모리에 저장한다.
사용자가 서버에 접근할 때마다, 해당 세션 정보를 조회하여 인증을 수행한다.
서버가 인증 정보를 유지해야 하므로 stateful(상태 유지) 방식이며,
서버 확장 시 세션을 공유하는 작업이 필요하여 확장성이 좋지 않다.
(2) 토큰을 전달하고 인증 받는 과정
- 클라이언트가 로그인을 통해 아이디와 비밀번호를 서버에 전달해 인증을 요청
- 서버는 아이디와 비밀번호를 확인하여 유효한 사용자인지 검증하고, 유효한 사용자이면 토큰을 생성하여 응답
- 클라이언트를 서버가 제공한 토큰을 저장
- 이후 인증이 필요한 API를 사용할 때, 토큰 정보와 함께 요청
- 서버는 토큰이 유효한지 검증
- 유효한 토큰이면 클라이언트가 요청한 내용을 처리하여 응답
(3) 토큰 기반 인증의 특징
📌 토큰 기반 인증은 무상태성, 확장성, 무결성이라는 특징이 있다.
1️⃣ 무상태성 (Stateless)
토큰 기반 인증에서는 사용자의 인증 정보가 담긴 토큰을 생성하고 이를 이용하여 인증을 수행한다.
사용자의 인증 정보가 담긴 토큰은 서버가 아닌 클라이언트에 저장되므로,
서버는 별도로 인증 정보를 보관할 필요가 없다.
이로인해 서버는 상태를 유지하기 위한 추가적인 자원을 소비하지 않으며, 완전한 무상태성을 유지할 수 있다.
클라이언트는 인증된 상태를 유지하면서 요청을 보낼 때마다 토큰을 함께 전송하며,
서버는 이 토큰을 검증하는 방식으로 인증을 처리한다.
이를 통해 서버는 인증 정보를 저장하지 않고도 효율적인 검증이 가능하다.
2️⃣ 확장성
무상태성은 서버의 확장성에 영향을 준다.
서버 확장 시, 상태 관리를 할 필요가 없으므로,
새로운 서버를 추가하더라도 별도의 세션 공유 없이 원활하게 확장할 수 있다.
예를 들어 결제 서버와 주문 서버가 따로 있을 때,
세션 기반 인증은 각각 API마다 개별적으로 인증을 수행해야 한다.
하지만 토큰 기반 인증은 클라이언트가 가지고 있는 하나의 토큰으로
2개의 서버에 요청을 보낼 수 있기에 효율적인 인증이 가능하다.
또한 페북 로그인, 구글 로그인과 같은 토큰 기반 인증을 활용하면,
다른 시스템과의 로그인 방식 통합이 용이하며, 외부 서비스에 대한 권한 공유도 가능하다.
이를 통해 인증 방식을 확장하고, 다양한 서비스 간의 연계를 보다 쉽게 구현할 수 있다.
3️⃣ 무결성
토큰 방식은 HMAC(Hash-based Message AuthentiCation)기법을 사용하여 토큰의 보안을 강화한다.
HMAC을 사용하면 토큰이 발급된 이후에는 그 내용을 변경할 수 없으므로, 토큰의 무결성이 보장된다.
즉, 토큰이 클라이언트에 전달된 후에도 변조되지 않았음을 확인할 수 있으며,
이를 통해 신뢰할 수 있는 인증이 가능해진다.
2. JWT
발급받은 토큰을 이용해 인증을 하려면,
HTTP 요청 헤더 중 Authorization 키 값에 Bearer + JWT 토큰값을 넣어 보내야 한다.
(1) JWT 구조
[JWT 구조]
.을 기준으로, 헤더(header), 내용(payload), 서명(signature) 으로 이루어져 있다.
aaaaa(헤더).bbbbb(내용).ccccc(서명)
(2) 리프레시 토큰
🔍 토큰 유효기간
토큰에는 유효기간(Expiration, exp)이 설정되며, 보안과 시스템 효율성을 위해 중요한 역할을 한다.
유효 기간을 설정하면, 보안이 강화되어 토큰이 유출되어도 일정 시간이 되면 자동으로 만료되기 때문에 악용을 방지할 수 있다.
또한, 권한 관리가 용이해져, 사용자의 권한 변경 시 새로운 토큰을 발급 받도록 할 수 있다.
서버 측면에서는 부하를 감소시키는 효과가 있어, 만료된 토큰을 무분별하게 사용하는 문제를 방지할 수 있다.
마지막으로 세션 관리가 불필요하여 서버가 별도의 인정 정보를 저장할 필요 없이 가볍고 효율적인 인증이 가능해진다.
토큰의 유효기간을 짧게 설정하면 보안성, 권한 관리, 서버 부하 감소 등의 장점을 극대화 할 수 있다.
하지만 사용자의 입장에서는 자주 로그인해야 하는 불편함이 발생할 수 있다.
이를 해결하기 위해 액세스 토큰(Access Token)과 리프레시 토큰(Refresh Token)을 함께 사용한다.
리프레시 토큰은 액세스 토큰이 만료되었을 때, 새로운 액세스 토큰을 발급하기 위해 사용된다.
즉, 액세스 토큰의 유효기간은 짧게, 리프레시 토큰의 유효기간을 길게 설정하여,
짧은 유효기간으로 인한 불편함을 최소화하고 보안 취약점을 보완할 수 있다.
(3) 리프레시 토큰으로 액세스 토큰을 발급 받는 과정
- 클라이언트가 서버에 인증을 요청
- 서버는 클라이언트가 전달한 정보를 바탕으로 인증 정보가 유효한지 확인한 후, 액세스 토큰과 리프레시 토큰을 전달 → 클라이언트는 전달받은 토큰을 저장
- 리프레시 토큰은 DB에 저장
- 인증이 필요한 API 호출을 할 때, 클라이언트에 저장된 액세스 토큰과 함께 API 요청
- 서버는 전달받은 액세스 토큰이 유효한지 검사 후, 유효하다면 요청한 내용을 처리
- 만료된 액세스 토큰과 함께 API 요청
- 서버는 토큰이 만료되어 유효하지 않다 판단하여, 만료되었다는 에러를 전달
- 클라이언트는 리프레시 토큰과 함께 새로운 액세스 토큰을 발급하는 요청을 전송
- 서버는 전달받은 리프레시 토큰과 DB에 저장된 리프레시 토큰이 동일한지 유효성 검사
- 유효한 리프레시 ㅌ토큰이면 새로운 액세스 토큰을 생성한 후 응답
- 이후, 4번과 같이 API 요청
(4) JWT 토큰 인증 순차적인 흐름 예시
