Json Web Token
인증에 필요한 정보들을 Json 객체로 담은 후 비밀키로 서명한 토큰
동작 방식
-
사용자가 로그인 정보(아이디, 비밀번호 등)를 입력하면 서버에 전송한다.
-
서버는 해당 사용자 정보를 데이터베이스에서 조회한다.
-
사용자가 존재하고 인증 정보가 일치하면 액세스 토큰을 발급한다.
-
발급한 액세스 토큰을 사용자에게 전달한다.
-
사용자는 인증이 필요한 모든 요청에 액세스 토큰을 함께 전송한다.
-
서버는 액세스 토큰이 유효한지 검증한다.
-
유효한 토큰이면 요청을 처리하여 응답을 전송하고, 그렇지 않으면 에러를 반환한다.
특징 및 장단점
특징 및 장점 👍
1. 자기 포함적 (Self - Contained)
- JWT는 필요한 모든 정보를 자체적으로 보유함
- 해당 정보에는 토큰이 발행된 이유, 대상, 만료 시간 등이 포함됨
- 그러므로 매우 유연하게 사용 가능함
2. 컴팩트 (Compact)
- 상대적으로 작은 크기를 가지고 있어 URL, POST 매개변수 또는 HTTP 헤더 등을 통해 쉽게 전송 가능함
- 원격 사이트에 대한 요청을 처리하는 데 유용함
3. 독립적 (Self - Descriptive)
- 자체적으로 토큰의 구조에 대한 정보를 포함하고 있으므로 어디서든 처리 가능함
4. 보안성
- JWT는 디지털 서명을 통해 검증되므로 정보의 신뢰성이 보장되며 토큰이 조작되지 않았음을 확인 가능함
5. 확장 가능성 (Scalability)
- 분산 시스템 환경에서 사용하기 용이함
- 각 토큰은 자체적으로 정보를 포함하고 있으므로 서버가 토큰을 생성한 후 클라이언트가 소유해도 문제가 없음
- 그로 인해, 서버는 별도의 세션을 유지할 필요가 없으므로 확장성이 높음
단점 👎
- 데이터 오버헤드
- 매 요청마다 헤더에 포함되어 전송되므로 데이터 트래픽에 약간의 오버헤드가 발생
- JWT 크기가 클 경우 오버헤드가 더욱 커질 수 있음
- 보안 고려사항
- 클라이언트 사이드에 저장되므로 토큰이 탈취되면 시스템이 취약해 질 수 있음
- 따라서 보안을 위해 HTTPS를 사용해야 하며, 민감한 데이터는 토큰에 포함 시키지 않아야 함
- 상태 비저장 (Stateless)
- 상태 비저장성 때문에 만료 시간까지 토큰이 계속 유효하여 토큰이 발행되면 무효화 시키는 것이 어려움
화이트리스트와 블랙리스트
JWT를 사용할 때 토큰의 유효성을 검사하고 관리하기 위한 보안 관리 방법
화이트리스트
특정 JWT 토큰을 수락하는데 사용
즉, 시스템에서 허용된 특정 JWT 토큰만을 유효하게 하는 방식
- 주로 액세스 토큰이나 리프레시 토큰을 검증할 때, 토큰의 서명을 확인하고 해당 토큰의 정보를 확인 후에 그 정보가 화이트리스트에 등록되어 있는지 확인
→ 등록이 되어 있다면 토큰은 유효함 - 특정 토큰만을 허용, 그외의 토큰은 거부
장점
- 구현이 쉬움
- 토큰을 다 저장하고 화이트리스트의 DB 조회만 하면 됨
- 토큰이 수학적으로 유효한지 체크하지 않아도 됨
단점
- 블랙리스트의 DB 조회보다 느리다.
블랙리스트
특정 JWT 토큰을 거부하는데 사용
즉, 시스템에서 특정 JWT 토큰을 무효화하는 방식
- 토큰이 만료되거나, 사용자가 로그아웃했을 때, 혹은 토큰이 탈취당했을 때 토큰을 무효화해야 할 경우에 블랙리스트를 사용
- 블랙리스트에 있는 토큰을 발견하면 시스템은 해당 토큰을 거부하고, 클라이언트는 새로운 토큰을 요청해야 함
- 토큰을 강제로 만료시키거나 특정 조건에 따라 토큰을 무효화할 때 유용
장점
- 화이트리스트의DB 조회보다 빠름
단점
- 화이트리스트보다 구현을 많이 해야 함
- 수학적인 방식으로 인증 → 블랙리스트의 DB 조회
- 신고하면 블랙리스트의 DB에 토큰 추가, 만료된 토큰 DB에서 제거
🔐 액세스 토큰과 리프레시 토큰
🔑 액세스 토큰 Access Token
- 매 요청마다 사용됨
- 보통 수명이 짧음
- 때문에, 화이트리스트와 블랙리스트를 지정할 필요 없음
- 별도의 재발급 수단이 필요
🔑 리프레시 토큰 Refresh Token
- 액세스 토큰을 재발급 받기 위한 수단
- 수명이 긺
- 액세스 토큰의 수명 주기에 따라 호출됨
- 화이트리스트 지정을 해야함
- ex) DB에 저장하는 등
💡 JWT 토큰 관리 방법
1. 서버 측에서 쿠키를 사용하는 방식 🍪⭕
장점
- 보안 : HttpOnly 쿠키를 사용하면, 클라이언트 사이드 스크립트를 통한 쿠키 접근을 막을 수 있어 XSS (Cross-Site Scripting) 공격을 방지할 수 있음.
- 간편함 : 브라우저가 자동으로 쿠키를 처리하기 때문에, JWT의 저장과 전송이 자동화 됨.
- CSRF 보호: 적절히 구성된 경우, 쿠키를 사용하는 서버 측 인증은 CSRF (Cross-Site Request Forgery) 공격에 대한 내성이 있음. (SameSite 속성 Lax, Strict)
단점
- CSRF 공격 가능성: CSRF 보호 조치가 없는 경우, 사용자는 CSRF 공격의 위험에 노출될 수 있음. (SameSite 속성 None)
- Same-Origin 정책 제약: 쿠키는 동일 출처 정책(Same-Origin Policy)에 의해 제한되므로, 다양한 도메인을 사용하는 애플리케이션에서는 관리가 복잡해질 수 있음.
2. 프론트엔드에서 직접 관리하는 방식 🍪❌
장점
- 유연성: 다양한 도메인이나 서브도메인 간에 토큰을 쉽게 공유하고 관리할 수 있음.
- 제어력: 프론트엔드에서 토큰을 완전히 제어할 수 있으므로, 복잡한 인증 흐름을 구현할 때 유리함.
단점
- XSS 취약성: 프론트엔드에서 JWT를 관리할 경우, 스토리지(예: localStorage)가 XSS 공격에 취약할 수 있음. (자바스크립트로 접근 가능)
- 보안 고려사항: 보안에 더 많은 주의가 필요하며, 토큰의 안전한 저장과 관리를 위한 추가적인 조치가 필요합니다.
3. 결론 ✅
-
쿠키 기반 접근 방식은 서버 측에서 보안이 강화된 환경을 제공하지만, CSRF 공격에 대한 보호가 필요하며, 동일 출처 정책의 제약을 받음.
-
프론트엔드 관리 방식은 유연성과 확장성이 뛰어나지만, XSS 공격에 더 취약하고 보안 관리에 더 많은 노력이 필요합니다.
반갑습니다