REST API 보안 핵심: JWT 완전 분석

안녕하세요! 여러분의 웹 서비스, 과연 안전하게 데이터를 주고받고 있나요? 로그인 시마다 서버에 사용자의 상태 정보를 저장하는 것이 비효율적이라고 느껴본 적은 없으신가요?

오늘은 REST API 개발 시 필수적인 **인증 및 보안** 메커니즘 중 하나인 **JWT(JSON Web Token)**에 대해 완벽하게 파헤쳐 보려고 합니다. 이 글을 통해 JWT의 기본 개념부터 구조, 그리고 실제 인증 과정까지 깊이 있게 이해하고, 여러분의 **백엔드 개발** 역량을 한층 더 끌어올리세요.

### **JWT(JSON Web Token)란 무엇인가요?**

JWT는 웹 애플리케이션에서 사용자 인증 정보를 안전하게 주고받기 위해 사용되는, URL-safe한 방법으로 정보를 압축한 토큰입니다. 클라이언트와 서버 간의 통신에서 **스테이트리스(Stateless)** 한 인증을 가능하게 하여, 서버의 부담을 줄이고 **스케일러빌리티(Scalability)** 를 향상시키는 데 큰 장점이 있습니다.

전통적인 세션 기반 인증 방식과 달리, JWT는 서버가 클라이언트의 상태를 직접 관리할 필요 없이 토큰 자체만으로 정보의 유효성을 검증할 수 있게 합니다.

### **JWT 토큰의 구조 해부: 3가지 핵심 요소**

JWT 토큰은 세 부분으로 나뉘며, 각 부분은 점(.)으로 구분되어 Base64Url 방식으로 인코딩됩니다.




1. **헤더 (Header)**
* 토큰의 타입(typ, 예: JWT)과 서명에 사용된 알고리즘(alg, 예: HS256) 정보를 담고 있습니다.
* JSON 형태로 작성된 후 Base64Url로 인코딩됩니다.
* **예시:** `{"alg": "HS256", "typ": "JWT"}`




2. **페이로드 (Payload)**
* 실제로 전달하고자 하는 정보인 **클레임(Claims)** 들을 담고 있습니다. 클레임은 크게 세 가지 유형으로 나눌 수 있어요.
* **등록된 클레임(Registered Claims):** JWT 명세에 정의된 표준 클레임입니다. `iss` (발급자), `exp` (만료 시간), `sub` (주제), `aud` (수신자) 등이 있습니다.
* **공개 클레임(Public Claims):** 충돌 방지를 위해 URI 형태로 정의된 클레임입니다.
* **비공개 클레임(Private Claims):** 클라이언트와 서버 간에 협의된 커스텀 클레임으로, 사용자 ID나 권한 정보 등을 담을 수 있습니다.
* **주의할 점:** 페이로드의 정보는 암호화되지 않고 단지 인코딩만 되기 때문에, 민감한 개인 정보는 직접 저장하지 않아야 합니다.
* **예시:** `{"sub": "user123", "name": "John Doe", "iat": 1516239022}` (iat는 토큰 발급 시간)




3. **서명 (Signature)**
* 이 부분이 바로 JWT의 **보안** 핵심입니다. 인코딩된 헤더와 인코딩된 페이로드, 그리고 서버만이 알고 있는 **비밀 키(Secret Key)** 를 이용해 생성됩니다.
* 서명은 토큰의 위변조 여부를 확인하는 데 사용됩니다. 만약 헤더나 페이로드의 내용이 변경된다면, 기존의 서명과 일치하지 않게 되어 토큰이 유효하지 않음을 알 수 있어요.
* **생성 원리:** `HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret_key)`

### **JWT 기반 인증 원리 (Flow)**

REST API에서 JWT가 어떻게 인증 과정에 활용되는지 단계별로 알아볼까요?




1. **클라이언트 로그인 요청:** 사용자가 아이디와 비밀번호를 서버로 전송합니다.



2. **서버 사용자 인증 및 토큰 발급:**
* 서버는 전송받은 아이디와 비밀번호를 데이터베이스와 비교하여 사용자를 인증합니다.
* 인증에 성공하면, 서버는 해당 사용자에 대한 정보를 담은 **JWT(액세스 토큰)** 를 생성합니다.
* 이때, 토큰의 페이로드에는 사용자 ID, 권한, 만료 시간 등이 포함되며, 서버의 비밀 키를 이용해 서명합니다.



3. **JWT 클라이언트 전달:** 서버는 생성된 JWT를 HTTP 응답의 바디나 `Authorization` 헤더(예: `Bearer `)에 담아 클라이언트로 전송합니다.



4. **클라이언트 토큰 저장:** 클라이언트는 전달받은 JWT를 로컬 스토리지, 세션 스토리지 또는 HTTP Only 쿠키 등에 안전하게 저장합니다.



5. **클라이언트 API 요청:** 이후 클라이언트는 보호된 API 리소스에 접근할 때마다, 저장해둔 JWT를 `Authorization` 헤더에 포함시켜 서버로 보냅니다.
* **예시:** `Authorization: Bearer `



6. **서버 토큰 유효성 검증:**
* 서버는 클라이언트로부터 받은 JWT의 서명을 자신의 비밀 키로 다시 생성해보고, 전달받은 서명과 일치하는지 확인합니다.
* 또한, 토큰의 만료 시간을 확인하여 유효 기간 내에 있는지 검증합니다.
* 만약 서명이 위조되었거나 토큰이 만료되었다면, 서버는 요청을 거부하고 에러를 반환합니다.



7. **리소스 접근 허용:** 토큰이 유효하다고 판단되면, 서버는 페이로드에 담긴 사용자 정보를 기반으로 해당 요청을 처리하고 적절한 응답을 반환합니다.

### **JWT의 장점과 단점, 그리고 세션과의 비교**

JWT는 편리함과 효율성을 제공하지만, 모든 상황에 완벽한 솔루션은 아닙니다. 장단점을 명확히 이해하고, 기존의 세션 기반 인증 방식과 비교하여 적절한 선택을 하는 것이 중요합니다.

**


● JWT의 장점**

* **스테이트리스(Stateless):** 서버가 사용자 상태를 저장할 필요가 없어 서버 자원을 절약하고, 여러 서버 간 로드밸런싱이 용이하여 **스케일러빌리티**가 높습니다.
* **분산 환경에 유리:** 마이크로서비스 아키텍처나 여러 도메인 간 인증 시 유용하게 사용될 수 있습니다.
* **모바일 환경 친화적:** 쿠키에 의존하지 않고 HTTP 헤더를 통해 토큰을 전달하므로 모바일 앱 개발에 유리합니다.
* **보안성:** 토큰이 서명되어 있어 위변조 여부를 쉽게 확인할 수 있습니다.

**


● JWT의 단점**

* **토큰 탈취 위험:** 토큰이 탈취되면 만료되기 전까지는 권한이 있는 것처럼 사용될 수 있습니다. 이를 방지하기 위해 **짧은 만료 시간**과 **리프레시 토큰(Refresh Token)** 전략을 함께 사용합니다.
* **토큰 무효화의 어려움:** 한 번 발급된 토큰은 만료될 때까지 유효합니다. 서버에서 강제로 무효화하려면 별도의 블랙리스트 관리 메커니즘이 필요합니다.
* **페이로드 크기:** 페이로드에 많은 정보를 담을수록 토큰의 크기가 커져 네트워크 부하가 증가할 수 있습니다.
* **민감 정보 노출 위험:** 페이로드 정보는 인코딩될 뿐 암호화되지 않으므로, 중요한 개인 정보는 절대 직접 담지 않아야 합니다.

**


● 세션 기반 인증 vs. JWT 기반 인증 비교**

특징	세션 기반 인증	JWT 기반 인증
상태 관리	서버에서 세션 상태 저장 (Stateful)	서버에 상태 저장 안 함 (Stateless)
확장성 (Scalability)	세션 공유 메커니즘 필요 (Sticky Session, Redis 등)	여러 서버 간 로드밸런싱 용이
모바일 환경	쿠키 기반으로 동작, 모바일 앱에서 다소 복잡	HTTP 헤더에 토큰 전달, 모바일 앱 친화적
토큰 무효화	서버에서 세션 삭제로 즉시 무효화 가능	만료 전 무효화 어려움 (블랙리스트 필요)
보안	CSRF 공격 방어에 유리, 세션 하이재킹 위험	토큰 탈취 시 위험, XSS/CSRF 취약점 고려 필요

 

### **결론**

JWT는 현대 웹 및 모바일 환경에서 **REST API 보안**과 **확장성**을 높이는 강력한 **인증 토큰**입니다. 그 구조와 인증 원리를 정확히 이해하고 장단점을 고려하여 구현한다면, 더욱 견고하고 효율적인 **백엔드 시스템**을 구축할 수 있습니다.

JWT를 사용할 때는 항상 **HTTPS**를 적용하여 토큰 전송 중 탈취를 방지하고, **액세스 토큰**과 **리프레시 토큰** 전략을 함께 사용하여 보안을 강화하는 것을 잊지 마세요!