JWT 인증과 인가

웹 서비스에서 인증(Authentication)인가(Authorization)는 구별해야 할 두 가지 개념이다. 인증은 사용자의 신원을 검증하는 행위(비밀번호·생체 인식 등)이고, 인가는 인증된 사용자에게 특정 리소스나 기능에 접근할 권한을 부여하는 행위다. 인증 없이 인가가 성립할 수 없다.

클라이언트가 서버에 인증을 확인받는 방법에는 크게 세 가지가 있다. 쿠키(Cookie) 방식은 브라우저에 데이터를 저장하지만 외부 노출 위험이 있다. 세션(Session) 방식은 서버에 상태를 저장해 보안이 높지만 서버 부하가 크고 분산 환경에서 세션 공유가 필요하다. 토큰(Token) 방식은 인증 정보를 클라이언트 측에 저장하므로 서버 부담을 줄이고 확장성이 높다. JWT(JSON Web Token)는 토큰 방식의 표준으로 가장 널리 쓰인다.

JWT 구조는 점(`.`)으로 구분된 세 부분으로 이루어진다. 헤더(Header)는 사용 알고리즘 유형(HS256 등)을 Base64로 인코딩한 것이다. 페이로드(Payload)는 사용자 정보와 권한(Claims)을 담은 데이터로 Base64 인코딩되어 있어 누구나 디코딩해 볼 수 있다(암호화가 아님). 서명(Signature)은 헤더와 페이로드를 서버의 비밀키로 서명한 값으로, 이를 통해 토큰 위변조 여부를 검증한다. 서버는 클라이언트의 토큰을 받으면 서명을 검증해 신뢰 여부를 판단한다.

JWT의 장점은 상태 비저장(Stateless) 구조로 서버 부담을 낮추고, 마이크로서비스 환경에서 별도 세션 공유 없이 인증을 처리할 수 있다는 점이다. 단점으로는 토큰이 탈취되면 만료 전까지 악용될 수 있고, 페이로드가 암호화되지 않아 민감 정보를 담으면 안 된다는 점이 있다. 이 때문에 액세스 토큰(짧은 유효기간)리프레시 토큰(긴 유효기간)을 함께 사용하는 패턴이 일반적이다.

핵심 내용

  • 인증(Authentication): 신원 검증 / 인가(Authorization): 접근 권한 부여 — 순서 중요
  • 쿠키(노출 위험) → 세션(서버 부하) → 토큰(확장성) 순으로 진화
  • JWT 3요소: Header(알고리즘) / Payload(사용자 정보, Base64) / Signature(서버 비밀키 서명)
  • 페이로드는 암호화가 아닌 인코딩 → 민감 정보 포함 금지
  • 토큰 탈취 위험 → 액세스 토큰(단기) + 리프레시 토큰(장기) 조합으로 대응
  • USIM 인증의 Challenge-Response 패턴과 OAuth·JWT의 구조적 유사성

관련 개념

출처

최종 업데이트: 2026-04-06 | 출처 1개