JWT?
JWT는 로그인된 사용자인지를 확인하는 "디지털 신분증" 같은 것
💬 왜 JWT가 필요할까?
- 보통 웹사이트에 로그인하면, 서버는 "이 사용자가 진짜인지" 알아야 함
- 따라서 매 요청마다 "누군지" 인증해야 함.
- 예전 방식은 서버가 사용자 정보를 세션에 저장했지만, 요즘은 "토큰 기반 인증", 그 중에서도 JWT를 많이 씀
JWT 구조
JWT는 3개의 부분으로 된 문자열임
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VySWQiOjEyMywibmFtZSI6Iu2VnOq1rOqzteybkA==.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c| 구분 | 설명 |
|---|---|
| Header | 토큰의 타입과 암호화 알고리즘 정보 |
| Payload | 사용자 정보, 만료시간 등 (암호화 X) |
| Signature | 위 두 개를 비밀키로 서명한 값 |
어떻게 사용되나?
- 사용자가 로그인
- 서버가 JWT 생성해서 브라우저에 전달
- 브라우저는 JWT를 로컬스토리지나 쿠키에 저장
- 다음 요청마다 JWT를 HTTP 요청에 담아 전송
- 서버는 JWT를 확인하고 → 누군지 확인 후 응답
장점
- 서버가 세션을 안 가지고도 인증 가능 (무상태)
- 분산 서버에서도 잘 작동함
- 빠름! (데이터가 토큰 안에 있음)
주의할 점
- 토큰이 탈취되면 위험 → HTTPS 사용 필수
- 일반적으로 Refresh Token도 함께 사용해서 보안 강화
Access Token과 Refresh Token이란?
JWT 기반 인증 시스템에서 사용하는 두 개의 토큰
기본 개념
- JWT는 JSON Web Token의 줄임말
- 서버가 로그인 인증 성공 시 두 개의 토큰을 발급함:
- Access Token: 사용자의 인증 정보가 담긴 토큰으로 API 요청 시 사용
- Refresh Token: Access Token이 만료되었을 때, 새로운 Access Token을 발급받기 위한 토큰
Access Token vs Refresh Token
| 항목 | Access Token | Refresh Token |
|---|---|---|
| 목적 | API 요청 시 인증 | Access Token 재발급용 |
| 담고 있는 정보 | 사용자 정보 (ex. userId, role 등) | 거의 없음 or 최소 정보 (보안 강화) |
| 저장 위치 | 메모리, 쿠키, 로컬스토리지 등 | 주로 httpOnly 쿠키 |
| 만료 시간 | 짧음 (수 분 ~ 수 시간) | 김 (며칠 ~ 몇 달) |
| 탈취 시 위험성 | 중간 (기간 짧고 사용 제한) | 높음 (새 Access Token 발급 가능) |
| 서버에 저장 여부 | ❌ 무상태 방식 (Stateless) | ✅ 저장 가능 (보안 위해 저장하는 경우도 있음) |
왜 두 개를 쓰는가?
- Access Token을 짧게 유지하면, 탈취 시 피해를 최소화할 수 있음
- 대신 Refresh Token으로 자동 재발급하면 사용자 경험은 끊기지 않음
✔ 보안성 확보 (Access Token은 짧게)
✔ 사용자 편의성 유지 (Refresh로 재로그인 없이 연장)Stateless란?
- JWT 인증은 Stateless (무상태) 방식임
- 서버가 사용자 상태(세션)를 기억하지 않음
- 클라이언트가 매 요청마다 JWT를 함께 보내며 인증을 증명함
장점:
- 서버 확장 용이 (여러 대의 서버로 분산 가능)
- 세션 저장소 없이도 인증 유지 가능
단점:
- 매 요청마다 JWT를 보내야 함 → 요청 크기 증가
- 탈취 위험 대비한 보안 조치 필요
인증(Authentication) vs 인가(Authorization)
| 개념 | 설명 |
|---|---|
| 인증(Authentication) | 등록된 사용자인지 확인 |
| 인가(Authorization) | 해당 기능을 사용할 권한이 있는지 확인 |
예: 로그인은 인증 / 관리자 페이지 접근 권한 확인은 인가
서버 세션 방식 vs 토큰 방식
서버(세션) 기반 인증 (Stateful)
- 서버가 세션을 저장해두고 사용자 상태를 기억함
- 클라이언트는 세션 ID만 보내면 됨
- 단점: 서버가 상태를 들고 있어야 함 → 확장성 낮음, CORS 문제 등
토큰(JWT) 기반 인증 (Stateless)
- 서버가 토큰을 발급하면, 클라이언트는 그 토큰을 저장 후 계속 사용
- 상태를 기억하지 않음 → 서버 확장에 유리
실제 인증 흐름 예시 (Access + Refresh Token)
- 로그인 성공 → 서버가 Access Token + Refresh Token 발급
- 클라이언트는 Access Token으로 API 요청 (인가: Authentication)
- Access Token 만료 시, 서버는 401 Unauthorized 응답
- 클라이언트는 Refresh Token으로 새로운 Access Token 요청
- 서버가 Refresh Token 검증 → Access Token 재발급
- Refresh Token도 만료됐다면 → 사용자에게 재로그인 요청
보안 고려사항
| 항목 | 설명 |
|---|---|
| 토큰 저장 위치 | Access는 메모리 or 쿠키, Refresh는 httpOnly 쿠키 추천 |
| 탈취 방지 | HTTPS 필수, 토큰 재사용 방지, 서버 측 검증 로직 구현 등 |
| 서버 측 Refresh 관리 | 보안을 강화하려면 Refresh Token을 DB에 저장하여 관리할 수 있음 |
마무리 요약
- JWT는 Stateless 인증 방식으로 토큰만으로 사용자 인증을 처리함
- 보안성과 사용자 편의성을 위해 Access + Refresh Token 구조를 사용함
- 토큰은 탈취 위험이 존재하므로 짧은 유효시간 + 자동 갱신 구조가 일반적임
- Refresh Token은 절대 노출되면 안 됨 → httpOnly 쿠키에 저장 + 주기적 갱신 필요
출처 & 참고자료
- https://velog.io/@chuu1019/Access-Token%EA%B3%BC-Refresh-Token%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B4%EA%B3%A0-%EC%99%9C-%ED%95%84%EC%9A%94%ED%95%A0%EA%B9%8C
- https://velog.io/@yena1025/JWT-%ED%86%A0%ED%81%B0%EA%B3%BC-%EB%AC%B4%EC%83%81%ED%83%9C%EC%84%B1Stateless
- https://mangkyu.tistory.com/55
