JWT를 이용한 인증 방식의 동작 원리

JWT (JSON Web Token)는 무상태(Stateless) 방식의 인증 시스템으로, 사용자 인증 정보를 토큰(Token) 형태로 발급하여 클라이언트와 서버 간의 인증을 처리하는 방식입니다.

JWT 구성 요소(HEADER+PAYLOAD+SIGNATURE로 사용자 맞춤 인증 기반 토큰 생성)

Header (헤더)	토큰 타입(typ)과 암호 알고리즘(alg) 정보 포함	{ "alg": "HS256", "typ": "JWT" }
Payload (페이로드)	사용자 정보(Claims) 포함	{ "sub": "userId", "role": "USER", "exp": 1690591600 }
Signature (서명)	토큰 변조 방지를 위한 서명( 헤더(Header)와 페이로드(Payload)를 합쳐서 암호화한 값)	HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secretKey)

Header와 Payload를 Base64Url로 인코딩한 후, 비밀키를 사용해 암호화하여 서명을 생성한다.
이는 사용자가 JWT를 자꾸 요청할 때, HEADER와 PAYLOAD가 변경되었는지 확인함으로써, 무결성을 유지할 수 있고, 공격자가 PAYLOAD를 수정해도, 시그니처가 변경되지 않으면 서버에서 이를 감지해 보안을 강화할 수 있다.


Signature 검증 과정
1. 클라이언트가 Authorization: Bearer <JWT> 형태로 API 요청.
2.서버는 JWT를 받아 Header와 Payload를 다시 암호화하여 기존 Signature와 비교.
3. 시그니처가 일치하면 유효한 토큰, 그렇지 않으면 변조된 것으로 간주하고 요청 거부.

 

JWT 인증 방식의 흐름

1. 사용자가 로그인 요청
   • 사용자가 ID와 비밀번호를 입력하여 로그인 요청을 보냄.
2. 서버에서 사용자 인증 (DB 조회)
   • Spring Security의 Authentication Filter가 로그인 요청을 가로채어 처리.
   • AuthenticationManager를 사용하여 DB에서 사용자 정보를 조회하고 인증을 수행.
3. 서버에서 JWT 발급
   • 인증이 완료되면 Access Token과 Refresh Token을 생성하여 반환.
4. 클라이언트가 JWT 저장
   • Access Token과 Refresh Token을 LocalStorage 또는 HttpOnly Cookie에 저장.
5. 클라이언트가 요청 시 JWT 포함하여 전송
   • 이후 API 요청 시 Authorization 헤더에 Bearer <Access Token>을 포함하여 전송.
6. 서버에서 JWT 검증
   • 서버는 받은 JWT의 서명을 검증하고 유효한 경우 요청을 처리.
7. 토큰 만료 시 Refresh Token을 사용해 새로운 Access Token 발급
   • Access Token이 만료되면 클라이언트는 Refresh Token을 이용해 새로운 Access Token을 요청.
   • 서버는 Refresh Token의 유효성을 검증한 후 새로운 Access Token을 발급하여 반환.

JWT의 만료 시간(Expiration Time) 설정 이유

1. 보안 강화 → 토큰이 탈취되더라도 일정 시간이 지나면 무효화됨.
2. 리소스 관리 → 무제한 토큰을 허용하면 인증된 사용자가 많아질수록 서버 부담 증가.
3. 로그아웃 기능 제공 → 토큰 만료를 통해 자동 로그아웃 가능.

Refresh Token의 역할

구분	Access Token	Refresh Token
목적	사용자 인증 (짧은 유효 기간)	새로운 Access Token 발급 (긴 유효 기간)
보관 위치	클라이언트 (Authorization 헤더)	서버 또는 클라이언트 (HttpOnly Cookie)
만료 시간	짧음 (15~30분)	김 (7~30일)
발급 대상	사용자 로그인 시 발급	Access Token이 만료되었을 때 사용

 Refresh Token 동작 방식

1. 사용자가 Access Token 만료 후 API 요청.
2. 서버가 Access Token이 만료되었음을 감지.
3. 클라이언트가 Refresh Token을 이용해 새로운 Access Token 요청.
4. 서버가 Refresh Token을 검증 후 새로운 Access Token을 발급.

JWT(JSON Web Token)의 장점

1. 서버의 상태를 유지할 필요 없음 (Stateless 인증)
   • JWT는 자체적으로 사용자 정보를 포함하고 있어 세션 저장소(Session Storage)가 필요하지 않음.
   • 서버는 매 요청마다 세션을 확인하지 않고, 토큰만 검증하면 되므로 성능이 향상됨.
2. 빠른 인증 처리
   • JWT는 토큰 내부에 사용자 정보를 포함하므로, 서버가 별도로 DB를 조회할 필요 없음.
   • 토큰의 서명(Signature)만 검증하면 되므로 인증 속도가 빠름.
3. 다양한 서비스 간 인증 가능 (분산 시스템에 적합)
   • JWT는 분산 환경(마이크로서비스, 모바일, 웹, API 게이트웨이 등)에서 사용하기 적합.
   • 동일한 JWT를 사용하여 여러 개의 서비스(서버)에서 인증을 공유할 수 있음.
4. 보안 강화 (서명 및 암호화 가능)
   • JWT는 HMAC, RSA 등의 서명 알고리즘을 사용하여 변조 방지.
   • 필요하면 Payload를 암호화하여 민감한 정보를 보호할 수 있음.
5. 다양한 플랫폼 및 언어에서 지원
   • JSON 기반이므로 웹, 모바일, 서버 등 다양한 플랫폼에서 사용 가능.
   • 다양한 언어(Java, Python, JavaScript, Go 등)에서 라이브러리 지원이 풍부함.
6. 액세스 제어 및 권한 관리 용이
   • JWT의 Payload에 사용자의 역할(Role), 권한(Privileges) 등을 포함할 수 있음.
   • 예: role: "ADMIN", permissions: ["read", "write"] 등의 정보를 포함하여 접근 제어 가능.
7. OAuth 2.0 등과 쉽게 연동 가능
   • JWT는 OAuth 2.0, OpenID Connect 등의 인증 프로토콜에서 널리 사용됨.
   • Google, Facebook, Naver, Kakao 로그인 등에서 JWT 기반의 토큰 인증 방식을 활용.
8. 토큰 만료 시간 설정 가능
   • JWT는 만료 시간(exp)을 설정할 수 있어 보안성을 높일 수 있음.
   • Access Token은 짧게(예: 1530분), Refresh Token은 길게(예: 730일) 설정하여 유효성을 유지할 수 있음.
9. 쿠키(Cookie) 또는 헤더(Header) 기반 인증 가능
   • JWT는 Authorization: Bearer <토큰> 형태로 HTTP 헤더에 포함할 수 있음.
   • 또는 HttpOnly Cookie에 저장하여 XSS 공격을 방지할 수도 있음.