JWT

JWT 헤더는 토큰의 첫 번째 부분을 구성하며, 토큰의 메타데이터를 담고 있다. 일반적으로 토큰의 유형과 서명에 사용된 암호화 알고리즘을 명시한다. 이 정보는 Base64Url 인코딩되어 JSON 객체 형태로 저장된다.

헤더의 가장 일반적인 구조는 다음과 같다.

alg 필드는 필수 항목으로, 서명 방식을 결정한다. HS256은 대칭 키 방식을, RS256은 비대칭 키 방식을 사용한다는 것을 의미한다. none 값은 서명이 없음을 나타내며, 보안상의 이유로 사용이 제한된다. 헤더는 서명 과정에 직접적으로 관여하여, 검증자가 올바른 알고리즘으로 서명을 확인할 수 있도록 한다.

페이로드는 JWT의 두 번째 부분으로, 토큰이 전달하려는 실제 데이터를 담고 있다. 이 데이터 조각들을 클레임이라고 부르며, 주로 사용자 정보나 권한, 토큰 자체의 메타데이터를 포함한다. 페이로드는 Base64Url 인코딩되어 있지만, 암호화되지 않기 때문에 민감한 정보를 저장해서는 안 된다.

클레임은 등록된 클레임, 공개 클레임, 비공개 클레임 세 가지 유형으로 구분된다. 등록된 클레임은 미리 정의된 표준 필드로, 선택적으로 사용할 수 있다. 주요 등록된 클레임은 다음과 같다.

공개 클레임은 충돌을 방지하기 위해 IANA에 등록되거나 URL 형식으로 정의되는 사용자 정의 클레임이다. 비공개 클레임은 통신 당사자 간에 합의하여 사용하는 사용자 정의 클레임으로, 예를 들어 "username": "john_doe"와 같은 형태를 가질 수 있다.

페이로드의 내용은 서명을 통해 변조 여부를 검증할 수 있지만, 누구나 디코딩하여 내용을 읽을 수 있다는 점을 명심해야 한다. 따라서 비밀번호나 신용카드 번호와 같은 절대적으로 보호되어야 하는 정보는 JWT 페이로드에 포함시키지 않는 것이 보안상 필수적이다.

서명은 JWT의 세 번째이자 마지막 부분으로, 토큰의 무결성과 신뢰성을 보장하는 핵심적인 역할을 한다. 서명은 헤더와 페이로드의 내용이 전송 중에 변조되지 않았음을 검증하기 위해 생성된다. 서버는 비밀 키 또는 공개/개인 키 쌍을 사용하여 서명을 생성하며, 이 서명 없이는 토큰의 내용을 임의로 변경할 수 없다.

서명 생성 과정은 다음과 같다. 먼저, Base64Url로 인코딩된 헤더와 페이로드를 점('.')으로 연결하여 서명 대상 문자열을 만든다. 그런 다음, 헤더에 지정된 암호화 알고리즘 (예: HMAC SHA256, RSA, ECDSA)과 비밀 키(또는 개인 키)를 사용하여 이 문자열에 대한 서명을 계산한다. 최종적으로 생성된 서명 역시 Base64Url 인코딩되어 헤더와 페이로드 뒤에 점으로 구분되어 추가된다.

토큰을 검증할 때는 수신 측(보통 서버)이 동일한 알고리즘과 적절한 키(비밀 키 또는 발행자의 공개 키)를 사용하여 헤더와 페이로드로부터 서명을 다시 계산한다. 새로 계산한 서명 값이 토큰에 포함된 서명 값과 일치하면, 토큰이 유효하고 변조되지 않았다고 판단한다. 이 과정을 통해 JWT는 자기 포함적(self-contained) 특성을 유지하며, 별도의 저장소 조회 없이도 토큰 자체로 신뢰성을 입증할 수 있다.

토큰 생성은 JWT를 발급하는 첫 번째 단계이다. 이 과정은 일반적으로 인증 서버나 애플리케이션의 백엔드에서 수행된다. 생성 절차는 헤더와 페이로드를 정의하고, 이를 서명하여 최종 토큰 문자열을 조합하는 방식으로 이루어진다.

먼저, 헤더와 페이로드 객체를 생성한다. 헤더에는 토큰 유형(JWT)과 사용된 서명 알고리즘(예: HMAC SHA256 또는 RSA)을 명시한다. 페이로드에는 클레임(claim)이라 불리는 정보 조각들을 담는다. 클레임은 등록된(registered) 클레임, 공개(public) 클레임, 비공개(private) 클레임으로 구분된다. 등록된 클레임은 토큰의 발급자(iss), 만료 시간(exp), 대상자(aud) 등 미리 정의된 표준 필드를 포함한다.

다음으로, 생성된 헤더와 페이로드는 각각 Base64Url 인코딩을 거쳐 문자열로 변환된다. 이 두 문자열을 마침표(.)로 연결한 후, 서버가 보유한 비밀 키(Secret Key) 또는 개인 키(Private Key)를 사용해 지정된 알고리즘으로 서명을 생성한다. 최종적으로, 인코딩된 헤더, 페이로드, 그리고 이를 다시 Base64Url로 인코딩한 서명을 마침표로 연결하여 완전한 JWT 문자열을 생성한다. 이 문자열이 클라이언트에게 발급되는 토큰이다.

JWT는 생성된 후 일반적으로 HTTP 요청의 Authorization 헤더를 통해 전송됩니다. 가장 일반적인 방식은 'Bearer' 스키마를 사용하는 것으로, 헤더 값은 Bearer <토큰> 형식을 따릅니다. 이 방식은 RESTful API나 웹 애플리케이션에서 표준적으로 사용됩니다.

토큰을 전송하는 다른 방법으로는 URL 쿼리 매개변수나 POST 요청의 본문에 포함하는 방식이 있습니다. 그러나 URL 쿼리 매개변수에 포함할 경우, 서버 로그나 브라우저 히스토리에 토큰이 노출될 위험이 있어 보안상 권장되지 않습니다. 쿠키를 이용해 전송하는 방법도 있으나, CSRF 공격에 대한 추가적인 보호 장치가 필요합니다.

토큰 전송 시 중요한 보안 고려사항은 HTTPS를 통한 통신을 사용하는 것입니다. JWT 자체는 서명으로 무결성을 보장하지만, 전송 과정에서 제3자에 의해 탈취될 수 있기 때문입니다. 또한 클라이언트 측에서는 토큰을 안전하게 저장해야 하며, 로컬 스토리지나 세션 스토리지 사용 시 XSS 공격에 노출될 수 있다는 점을 인지해야 합니다.

JWT 검증은 수신한 토큰의 무결성과 신뢰성을 확인하는 과정이다. 이 과정은 주로 서버 측에서 수행되며, 토큰이 위조되거나 변조되지 않았는지, 그리고 유효한 클레임을 포함하는지 검사한다.

검증 절차는 일반적으로 다음 단계를 따른다.

1. 구조 확인: 토큰이 점(.)으로 구분된 헤더, 페이로드, 서명의 세 부분으로 구성되어 있는지 확인한다.

2. 서명 검증: 토큰 생성 시 사용된 비밀 키 또는 공개 키를 이용해 서명 부분을 재계산한다. 이렇게 계산한 서명 값이 토큰에 포함된 서명 값과 일치해야 한다. 서명 검증에 실패하면 토큰은 거부된다.

3. 클레임 검증: 페이로드에 포함된 표준 클레임을 기준으로 유효성을 판단한다. 주요 검증 항목은 다음과 같다.

검증이 성공하면, 서버는 페이로드에 포함된 사용자 정보나 권한(클레임)을 신뢰하고 이를 바탕으로 인가 결정을 내린다. 검증에 실패하면 토큰은 무효화되며, 요청은 거부된다. 이 검증 방식 덕분에 서버는 별도의 세션 저장소를 조회할 필요 없이 토큰 자체만으로 요청의 유효성을 빠르게 판단할 수 있다.

JWT는 무상태성을 기반으로 설계되어 서버 측에서 세션 정보를 저장할 필요가 없습니다. 이는 서버의 부하를 줄이고 확장성을 크게 향상시킵니다. 또한 여러 서비스나 도메인 간에 인증 정보를 손쉽게 공유할 수 있어 마이크로서비스 아키텍처나 분산 시스템 환경에 적합합니다.

토큰 자체(자체 포함 토큰)에 필요한 모든 정보를 포함하고 있어, 데이터베이스 조회 없이도 사용자 정보와 권한을 확인할 수 있습니다. 이는 인증 프로세스의 효율성을 높입니다. 표준화된 JSON 형식을 사용하기 때문에 다양한 프로그래밍 언어와 플랫폼에서 쉽게 생성하고 검증할 수 있습니다[1].

클라이언트 측에서 토큰을 저장하고 관리하기 때문에, 서버의 메모리나 스토리지 부담이 없습니다. 웹 애플리케이션과 모바일 애플리케이션 모두에서 일관된 인증 방식을 적용할 수 있습니다. 또한 서명을 통해 토큰의 무결성을 보장할 수 있어, 전송 중 변조 위험을 방지합니다.

JWT는 여러 장점에도 불구하고 잘못 사용하거나 구성할 경우 보안 취약점으로 이어질 수 있다. 주요 단점은 토큰 자체가 상태를 유지하지 않는 무상태성에서 비롯된다. 한번 발급된 JWT는 서버 측에서 강제로 만료시키기 어렵다. 이는 토큰이 탈취당했을 때 유효 기간이 만료될 때까지 악용될 수 있음을 의미한다. 따라서 JWT의 만료 시간은 신중하게 설정해야 한다.

페이로드에 저장된 정보는 암호화되지 않고 단순히 Base64로 인코딩되어 있기 때문에, 민감한 정보를 포함해서는 안 된다. 누구나 토큰을 디코딩하여 내용을 볼 수 있다. 또한, 서명 검증을 위한 비밀 키 또는 공개 키의 관리가 매우 중요하다. 키가 유출되면 공격자가 자유롭게 토큰을 위조할 수 있다.

주요 보안 고려사항은 다음과 같다.

마지막으로, JWT는 본래 정보 교환을 위해 설계되었으며, 세션 관리에 사용될 때는 위의 보안 문제들을 충분히 인지하고 구조를 설계해야 한다. 특히 대규모 시스템에서의 로그아웃 처리나 토큰 블랙리스트 관리는 추가적인 오버헤드를 발생시킨다.

JWT는 인증과 권한 부여를 처리하는 데 널리 사용되는 방법이다. 서버는 사용자의 로그인 정보를 확인한 후, 해당 사용자의 신원과 권한을 담은 JWT를 생성하여 클라이언트에게 발급한다. 이후 클라이언트는 이 토큰을 보관하고, 보호된 리소스에 접근할 때마다 HTTP 요청의 Authorization 헤더에 토큰을 첨부하여 전송한다.

서버는 매번 요청을 받을 때마다 토큰의 서명을 검증하여 위변조 여부를 확인한다. 서명이 유효하면, 서버는 별도의 데이터베이스 조회 없이 토큰 내부(페이로드)에 포함된 정보(예: 사용자 ID, 역할, 만료 시간)를 신뢰하고 요청을 처리한다. 이는 상태 비저장 인증 메커니즘의 핵심이다.

JWT 기반 인증의 주요 흐름은 다음 표와 같다.

이 방식은 특히 마이크로서비스 아키텍처나 RESTful API와 같은 분산 시스템에서 유용하다. 각 서비스가 독립적으로 토큰을 검증할 수 있어, 중앙 집중식 세션 저장소에 의존하지 않아도 된다. 그러나 토큰이 탈취당할 경우 발생할 수 있는 보안 문제를 방지하기 위해, HTTPS 사용과 짧은 토큰 만료 시간 설정, 민감한 정보를 페이로드에 저장하지 않는 것 등이 중요하다[3].

JWT는 인증 외에도 당사자 간에 정보를 안전하게 교환하는 데 사용됩니다. 이는 암호화 서명을 통해 데이터의 무결성과 신뢰성을 보장하기 때문입니다. 페이로드에 필요한 정보를 포함시켜 별도의 데이터베이스 조회 없이도 정보를 전달하고 검증할 수 있습니다.

주요 정보 교환 시나리오는 다음과 같습니다.

이러한 방식은 데이터를 자체적으로 포함하는 자기 기술 토큰의 특성을 활용합니다. 서명된 JWT는 수신자가 발급자를 신뢰할 수 있고, 내용이 중간에 조작되지 않았음을 확인할 수 있게 합니다. 그러나 페이로드의 정보는 기본적으로 Base64로 인코딩될 뿐 암호화되지 않으므로, 민감한 정보를 포함할 경우 반드시 JWE를 사용하여 암호화해야 합니다[4].

단일 사인온(SSO)은 사용자가 한 번의 로그인으로 여러 개의 관련된 애플리케이션 또는 서비스에 접근할 수 있도록 하는 인증 메커니즘이다. JWT는 이러한 SSO 시스템을 구현하는 데 매우 효과적인 도구로 사용된다. 중앙 집중식 인증 서버(예: IDP)가 사용자를 인증하고, 그 결과를 JWT 형태로 발급하면, 사용자는 이 토큰을 다른 서비스나 애플리케이션(SP)에 제시하여 추가 로그인 없이 접근 권한을 획득한다.

SSO에서 JWT의 핵심 역할은 신뢰할 수 있는 인증 정보의 전달자이다. 인증 서버는 토큰을 생성할 때 서명을 추가하여, 토큰의 내용이 위변조되지 않았음을 보장한다. 이후 사용자가 다른 서비스에 접근할 때마다, 해당 서비스는 토큰의 서명을 공유된 비밀 키 또는 공개 키로 검증함으로써 인증 서버를 직접 확인하지 않고도 사용자의 신원과 권한을 신뢰할 수 있다. 이는 마이크로서비스 아키텍처 환경에서 특히 유용하며, 각 서비스가 독립적으로 인증 결정을 내릴 수 있게 한다.

JWT 기반 SSO의 주요 구현 패턴은 다음과 같다.

이 방식은 사용자 경험을 향상시키고, 인증 관리를 중앙화하여 보안 정책을 일관되게 적용할 수 있다는 장점이 있다. 그러나 JWT 자체의 특성상, 발급된 토큰을 강제로 만료시키는 것이 어렵기 때문에, 짧은 유효 기간 설정과 리프레시 토큰의 활용, 또는 블랙리스트 관리와 같은 추가적인 보안 조치가 필요하다.

JWT는 언어에 구애받지 않는 개방형 표준이므로, 대부분의 현대 프로그래밍 언어에서 구현이 가능하다. 특히 웹 서버 및 API 개발에 널리 사용되는 언어들을 중심으로 공식 및 서드파티 라이브러리가 잘 구축되어 있다.

주요 구현 언어와 그 특징은 다음과 같다.

이러한 언어별 라이브러리들은 일반적으로 JWT의 생성, 서명, 검증 기능을 제공한다. 선택한 언어의 생태계와 프레임워크에 맞는 검증된 라이브러리를 사용하는 것이 보안과 유지보수 측면에서 중요하다.

다양한 프로그래밍 언어와 프레임워크를 위한 JWT 라이브러리가 존재하며, 이들은 토큰 생성, 서명, 검증 기능을 표준화된 방식으로 제공한다. 대부분의 라이브러리는 RFC 7519 표준을 준수하며, HMAC, RSA, ECDSA와 같은 서명 알고리즘을 지원한다.

주요 언어별 인기 라이브러리는 다음과 같다.

이들 라이브러리는 종종 프레임워크별 인증 솔루션에 통합되어 사용된다. 예를 들어, Spring Security는 Java 환경에서, Passport.js는 Node.js 환경에서 JWT를 활용한 인증 전략을 제공한다. 라이브러리 선택 시 프로젝트의 언어, 프레임워크, 성능 요구사항, 보안 알고리즘 지원 범위, 커뮤니티 활성도 및 유지보수 상태를 고려해야 한다.

JWT와 세션 기반 인증은 모두 웹 애플리케이션에서 사용자의 상태를 관리하는 주요 방식이다. 그러나 그 접근법과 특성에서 근본적인 차이를 보인다.

JWT는 클라이언트 측에 상태 정보를 저장하는 무상태성 방식을 채택한다. 서버는 토큰을 생성하고 서명한 후 클라이언트에게 전달하면, 이후 클라이언트는 이 토큰을 요청 시마다 함께 보낸다. 서버는 토큰의 서명만 검증하여 그 유효성을 판단하며, 별도의 세션 저장소를 유지할 필요가 없다. 이는 서버의 확장성을 높이고, 마이크로서비스 아키텍처와 같은 분산 환경에 적합하다. 반면, 전통적인 세션 방식은 상태성을 유지한다. 서버는 사용자 로그인 시 고유한 세션 ID를 생성하여 안전한 저장소(예: 메모리, 데이터베이스, Redis)에 저장하고, 이 ID를 쿠키 등을 통해 클라이언트에게 전달한다. 클라이언트의 이후 요청에는 이 세션 ID가 포함되며, 서버는 이를 받아 저장소에서 해당 사용자의 상태 정보를 조회한다.

두 방식의 주요 차이점은 아래 표와 같이 정리할 수 있다.

보안 측면에서 JWT는 토큰이 탈취당하면 만료 시간까지 악용될 수 있는 위험이 있다. 이를 완화하기 위해 짧은 만료 시간을 설정하고 리프레시 토큰을 활용한다. 세션 방식은 서버 측에서 즉시 세션을 무효화할 수 있어 통제력이 높지만, 세션 저장소에 대한 부하와 세션 고정 공격 등의 위협에 노출될 수 있다. 선택은 애플리케이션의 아키텍처, 확장성 요구사항, 보안 정책에 따라 달라진다.

JWT와 OAuth는 모두 현대 웹 인증 및 권한 부여에서 중요한 역할을 하지만, 그 목적과 범위, 작동 방식에서 근본적인 차이를 보인다. JWT는 주로 정보를 안전하게 표현하는 토큰 형식(포맷)이며, OAuth는 권한 위임을 위한 프레임워크(프로토콜)이다. 이는 핵심적인 구분점으로, OAuth 프레임워크 내에서 접근 토큰을 전달하는 수단으로 JWT가 사용될 수 있다[7].

다음 표는 두 기술의 주요 차이점을 요약한다.

실제 구현에서 둘은 상호 보완적으로 사용된다. OAuth 2.0은 액세스 토큰을 발급하는 메커니즘을 정의하는 반면, 그 액세스 토큰의 형식으로 JWT를 채택할 수 있다. 이렇게 하면 토큰이 자체 포함적(self-contained)이 되어 리소스 서버가 인증 서버에 별도로 문의하지 않고도 토큰의 유효성과 클레임을 검증할 수 있다. 따라서 "JWT 대 OAuth"라는 비교는 정확히는 "토큰 형식 대 권한 부여 프로토콜"의 비교에 가깝다. 시스템 설계 시 JWT는 정보 교환의 수단으로, OAuth는 제3자 접근 권한을 관리하는 전체적인 구조로 이해하는 것이 바람직하다.