JSON 웹 토큰의 약자인 JWT 토큰은 두 당사자 간에 클레임을 전달하는 간결한 형식입니다. 애플리케이션은 로그인 후에 JWT를 흔히 사용합니다. 서버가 토큰을 발급하면 클라이언트가 이후 요청에 이를 포함하여 보내고, API는 접근을 허용하기 전에 토큰을 검증합니다. JWT는 암호화폐 토큰이 아니며, 그 내용은 자동으로 비밀이 아닙니다.
금융, 거래소 및 Web3 서비스 전반의 계정 시스템은 백엔드에서 토큰 기반 인증을 사용할 수 있습니다. 디지털 자산 플랫폼을 탐색하는 독자는 Tapbit 계정을 생성할 수 있으며, 개발자는 모든 인증 토큰을 보안에 민감한 자격 증명으로 취급해야 합니다.
JWT 토큰이란 무엇인가요?
JWT 표준 RFC 7519는 JSON 객체로 전송되도록 설계된 간결한 클레임 형식을 정의합니다. 클레임은 사용자 식별자, 토큰 발급자, 대상 또는 만료 시간과 같은 진술입니다. JWT는 종종 액세스 토큰, ID 토큰 또는 서비스 간의 단기 메시지로 사용됩니다.
사람들은 종종 "JWT 토큰"이라고 말하지만, 마지막 "T"는 이미 토큰을 의미합니다. 반복은 흔하고 무해합니다. 중요한 것은 JWT가 완전한 로그인 시스템이 아닌 형식을 설명한다는 것을 이해하는 것입니다. 안전한 인증에는 올바른 발급, 검증, 저장, 만료 및 취소 정책도 필요합니다.
JSON 웹 토큰은 어떻게 작동하나요?
일반적인 로그인 흐름은 사용자가 유효한 자격 증명을 제출할 때 시작됩니다. 인증 서버는 선택된 클레임을 포함하는 JWT를 생성하고 디지털 서명 또는 메시지 인증 코드로 보호합니다. 그런 다음 클라이언트는 종종 Bearer 스킴을 사용하는 HTTP Authorization 헤더에서 API에 JWT를 제시합니다.
API는 서명을 검증하고 필요한 클레임을 확인한 후 요청을 신뢰합니다. 중요한 확인에는 발급자, 대상, 만료 시간 및 애플리케이션에서 예상하는 알고리즘이 포함될 수 있습니다. 검증이 성공하면 API는 클레임을 사용하여 권한 부여 결정을 내립니다. 실패하면 요청은 거부되어야 합니다.
JWT의 세 부분
일반적으로 볼 수 있는 서명된 JWT는 점으로 구분된 세 개의 Base64url 인코딩된 섹션으로 구성됩니다.
header.payload.signature
- Header: 토큰 유형 및 서명 알고리즘을 식별합니다.
- Payload:
sub(주체),iss(발급자),aud(대상),exp(만료)와 같은 클레임을 포함합니다. - Signature: 수신자가 무단 변경을 감지하고 올바른 키가 사용될 때 서명자를 확인할 수 있도록 합니다.
Base64url 인코딩은 암호화가 아닙니다. 일반 서명된 JWT를 얻는 사람은 누구나 일반적으로 헤더와 페이로드를 디코딩할 수 있습니다. 따라서 민감한 정보는 시스템이 적절한 암호화된 형식을 사용하고 명확한 필요성이 없는 한 페이로드에 배치해서는 안 됩니다.
초보자를 위한 JWT 예시
Alice가 로그인한 후 토큰을 발급하는 API를 생각해 보세요. 페이로드에는 Alice가 주체로 식별되고, 발급자가 명명되며, API가 대상으로 지정되고, 15분 후에 만료될 수 있습니다. Alice가 프로필을 요청하면 API는 토큰을 검증하고 주체 클레임을 사용하여 올바른 계정을 찾습니다.
누군가가 페이로드를 Alice의 식별자에서 관리자의 식별자로 변경하면 서명이 더 이상 일치하지 않습니다. 이것이 서명된 JWT의 핵심 이점입니다. 즉, 변조가 감지될 수 있습니다. 그러나 유효한 서명이 모든 클레임이 적절하다는 것을 증명하지는 않습니다. API는 여전히 토큰이 예상 발급자로부터 왔고 해당 API를 대상으로 했는지 확인해야 합니다.
JWT vs 세션 쿠키 vs API 키
| 방법 | 일반적인 목적 | 상태가 저장되는 곳 | 주요 고려 사항 |
|---|---|---|---|
| JWT | 클레임 및 API 권한 부여 | 토큰이 클레임을 전달하며, 서버는 여전히 상태를 유지할 수 있습니다. | 검증 및 취소 설계 |
| 세션 쿠키 | 브라우저 로그인 세션 | 일반적으로 서버 측 세션 저장소 | 쿠키 및 CSRF 보호 |
| API 키 | 애플리케이션 또는 프로젝트 식별 | 서버가 키를 권한에 매핑합니다. | 키는 회전되지 않는 한 장기 비밀입니다. |
JWT가 세션보다 자동으로 더 좋지는 않습니다. 세션은 즉각적인 취소를 간단하게 만들 수 있는 반면, JWT는 반복적인 데이터베이스 조회를 줄이고 분산 서비스 전반에서 잘 작동할 수 있습니다. 많은 시스템은 두 가지 접근 방식을 결합합니다. 예를 들어, 서버에서 관리하는 새로고침 토큰 레코드가 있는 단기 JWT가 있습니다.
JWT는 암호화되나요?
일반적으로 그렇지 않습니다. 익숙한 세 부분으로 된 JWT는 일반적으로 서명된 JSON 웹 서명 객체입니다. 올바르게 구현되면 서명은 무결성과 인증을 제공하지만 페이로드를 숨기지는 않습니다. JSON 웹 암호화는 기밀성을 제공할 수 있는 관련 표준이지만, 다른 구조를 사용하고 키 관리 복잡성을 추가합니다.
이 구별은 중요합니다. 개발자가 때때로 JWT를 디코더에 붙여넣고 읽을 수 있는 데이터를 보고 놀라기 때문입니다. 디코딩은 서명을 성공적으로 검증하는 것과 같지 않습니다. 애플리케이션은 디코딩된 클레임만을 기반으로 액세스를 부여해서는 안 됩니다.
일반적인 JWT 보안 위험
IETF의 JWT 모범 사례 RFC 8725는 실제 시스템에서 나타난 구현 실패를 다룹니다. 가장 큰 문제는 기본 형식 자체보다는 잘못된 검증에서 비롯되는 경우가 많습니다.
- 알고리즘 혼동: 예상치 못하거나 안전하지 않은 알고리즘을 수락합니다.
- 누락된 클레임 확인: 발급자, 대상, 만료 또는 기타 애플리케이션 요구 사항을 무시합니다.
- 토큰 도난: 로그, 스크립트, 안전하지 않은 저장소 또는 보호되지 않은 전송을 통해 베어러 토큰을 노출합니다.
- 약한 키: 추측 가능한 비밀을 사용하거나 손상된 서명 키를 회전하지 못합니다.
- 긴 만료: 도난당한 토큰이 너무 오래 유용하게 유지됩니다.
- 부실한 취소: 서명된 토큰이 조기에 무효화될 필요가 없다고 가정합니다.
JWT 모범 사례
애플리케이션은 지원하는 알고리즘만 명시적으로 허용하고, 모든 필수 클레임을 확인하며, 다른 종류의 JWT에 대해 별도의 검증 규칙을 사용해야 합니다. 토큰은 단기적이어야 하며, HTTPS를 통해서만 전송되고, URL 및 일반 로그에서는 제외되어야 합니다. 서명 키는 안전한 저장, 회전 및 명확한 소유권이 필요합니다.
저장은 애플리케이션에 따라 다릅니다. 브라우저 시스템은 안전하고 HttpOnly이며 SameSite인 쿠키를 사용할 수 있으며, 모바일 또는 백엔드 클라이언트는 플랫폼에 적합한 보호된 저장소를 사용합니다. 어떤 저장소 선택도 모든 위협을 제거하지는 못하므로, 개발자는 XSS, CSRF, 토큰 재사용 및 장치 손상을 함께 고려해야 합니다.
결론
JWT는 시스템 간에 검증 가능한 클레임을 전달하는 간결한 방법입니다. 헤더는 보호 방법을 설명하고, 페이로드는 클레임을 포함하며, 서명은 수신자가 변조를 감지하는 데 도움이 됩니다. JWT는 API 인증을 단순화할 수 있지만, 수신자가 올바른 알고리즘, 발급자, 대상, 시간 클레임 및 서명을 검증할 때만 가능합니다. 초보자를 위한 핵심 규칙은 간단합니다. JWT는 전체 인증 설계가 안전하다는 증거가 아니라 자격 증명 형식입니다.
자주 묻는 질문
JWT는 무엇의 약자인가요?
JWT는 JSON 웹 토큰의 약자로, 클레임을 JSON으로 전송하기 위한 표준화된 간결한 형식입니다.
누구나 JWT를 디코딩할 수 있나요?
일반적인 서명된 JWT를 가진 사람은 누구나 일반적으로 헤더와 페이로드를 디코딩할 수 있습니다. 디코딩은 서명을 검증하거나 클레임을 신뢰할 수 있게 만들지 않습니다.
JWT와 액세스 토큰은 같은 것인가요?
아니요. 액세스 토큰은 목적을 설명하고, JWT는 형식을 설명합니다. 일부 액세스 토큰은 JWT이고, 다른 것들은 불투명한 문자열입니다.
JWT는 얼마나 오래 지속되어야 하나요?
보편적인 기간은 없습니다. 액세스 토큰은 일반적으로 단기적이며, 정확한 수명은 시스템의 위험, 취소 및 사용성 요구 사항에 따라 결정됩니다.
JWT를 취소할 수 있나요?
예, 하지만 취소하려면 거부 목록, 키 회전, 토큰 버전 관리 또는 서버에서 관리하는 새로고침 토큰 시스템과 같은 추가 설계가 필요합니다.
