JWT[1/3]: JWT 이해(이론)

1. JWT 이해

1.1 JWT란

• JWT(Json Web Token)는 사용자 인증 정보를 안전하게 전달하기 위한 토큰 기반 인증 방식으로 임의의 문자열로 구성
• JWT는 서버가 사용자를 인증한 후 발급하며, 클라이언트는 이후 요청마다 JWT를 전달하여 자신의 신원을 증명
• JWT는 RFC 7519 표준 준수
• JWT 토큰은 Header.Payload.Signature으로 점(.)으로 세 개 영역을 구분

RFC 7519: JSON Web Token (JWT)

 

JSON Web Tokens - jwt.io

JWT 토큰 구조

Header

• 토큰의 메타데이터를 저장
• 일반적으로 대칭키 서명 방식(HS256)을 사용

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

• 사용자 정보를 저장
• 민감한 정보는 포함하지 않는 것을 권장

{
  "sub": "1",
  "role": "CUSTOMER",
  "type": "ACCESS"
}

Signature

• 위조 방지를 위한 서명값
• JWT는 암호화가 아니라 서명
• Payload는 누구나 볼 수 있고, Signature는 위조 여부를 검증

1.2 Cookie, Session, JWT 비교

Cookie 인증

• 클라이언트 저장소로, 브라우저가 데이터를 저장
• 보안상 취약

Session 인증

• 클라이언트 → JSESSIONID → 세션 저장소(서버)
• 서버가 상태를 관리하는 Stateful 방식

JWT 인증

• 클라이언트 → JWT → 서명 검증
• 서버가 인증 상태를 저장하지 않는 Stateless 방식

Cookie, Session, JWT 비교

항목	Session	JWT
서버 저장소	필요	불필요
확장성	낮음	높음
MSA 적합성	낮음	높음
로그아웃	쉬움	어려움
서버 부하	증가	감소

 

JWT의 가장 큰 문제

JWT는 Stateless 방식으로 발급된 토큰을 서버가 기억하지 않는다. 그래서 발급된 토큰을 강제로 폐기하기 어렵다.  이 문제가 Refresh Token 저장소, Access Token Blacklist 를 도입하게 된 가장 큰 이유이다.

1.3 JWT 생태계

각 서비스가 독립적으로 JWT를 검증할 수 있다.

• SPA: React, Vue, Next.js
• Mobile: Android, iOS
• MSA: Gateway, User Service, Order Service, Payment Service

1) OAuth2.0

OAuth2.0 에서 가장 큰 오해는 바로 JWT가 아니다.

OAuth2는 인가(Authorization) 프로토콜로, OAuth2 결과물로 JWT가 사용될 수 있다.

 

2)  OpenID Connect

OpenID Connect는 Auth 2.0 프로토콜을 기반으로 구축된 인증(Authentication) 표준으로 싱글 사인온(SSO) 및 소셜 로그인을 안전하게 구현할 수 있도록 돕는 기술이다. 확실하게 짚고 넘어가야 할 것은 OAuth 2.0은 '권한 부여(Authorization)'를 위한 프로토콜이다."A 앱이 사용자의 Google 사진첩(데이터)에 접근할 수 있는 권한을 허락한다"는 개념이다.

 

OpenID Connect는 OAuth 2.0 위에 '인증(Authentication)' 계층을 추가한 것이다.

"이 사용자가 Google에서 인증된 본인이 맞는지 확인한다"는 개념이다.

 

3) Keycloak

인증 서버로, JWT를 발급한다. 대부분 개인 프로젝트에서는 직접 구현했지만, 실무에서는 Keycloak을 사용하는 경우가 많다.

 

4) HashiCorp Vault

JWT Secret 관리에 사용된다. 현재는 application.yml 기반이지만, 운영 환경에서는 Valut, AWS Secrets Manager, Kubernetes Secret 등으로 관리하는 것이 일반적이다.