1. JWT 동작 방식
인증 과정에서 사용자가 성공적으로 자격 증명을 완료하면 JWT가 반환 됨
토큰 자체로 인증 수단이므로, 보안에 주의를 기울여야 함
∴ 필요한 시간 보다 더 오래 보관하면 안 됨
사용자가 특정 경로나 리소스에 접근하려고 할 때, JWT를 같이 보내줘야함.
일반적으로 Authorization 헤더에 Bearer 스키마로 전달
Authorization: Bearer <token>
HTTP 헤더를 통해 JWT를 전달하는 경우, 토큰에 너무 많은 정보를 담으면 안 됨
일부 서버는 헤더의 크기가8KB를 초과하는 걸 참지 않아..
1) Authorization 헤더
HTTP 프로토콜에서 클라이언트가 서버에 인가된 상태임을 전달하는 수단으로 사용됨
서버에서 사용자의 신원을 증명하기 위해 필수적 (HTTP/1.1 표준에서 처음 정의)
Authorization: <스키마> <자격 증명>
| 스키마 | 인증 방식 (ex. Basic, Bearer) |
| 자격 증명 | 클라이언트의 인증 정보 |
2) Bearer 토큰
클라이언트가 특정 리소스에 접근할 수 있는 권한을 증명하기 위해 서버에 전달하는 토큰
HTTPS를 통해 전달되어야 하며, 이를 통해 토큰이 네트워크에서 탈취됨을 방지
OAuth 2.0의 등장
클라이언트가 리소스 소유자를 대신해
서버에 접근할 수 있는 인증과 권한 위임 방식을 표준화한 프레임워크
민감한 사용자 정보를 직접 전송하지 않고, 액세스 토큰을 사용해 인증 수행
이 과정에서 Authorization 헤더는 토큰 기반 인증의 전달 수단으로 채택,
Bearer 스키마가 OAuth 2.0의 핵심 인증 방식으로 자리잡음
❓ 클라이언트랑 리소스 소유자 같은 말 아닌가여??
- 리소스 소유자
홍길동이라는 사용자가 있습니다. 홍길동은 자신의 개인 정보를 포함한 데이터(예: 이메일, 프로필 사진 등)를 소셜 미디어 서비스(예: 구글, 페이스북)에 가지고 있습니다. 홍길동은 이 데이터에 대한 권한을 가지고 있는 리소스 소유자입니다.
- 클라이언트
홍길동이 가입하고자 하는 앱 A가 있습니다. 이 앱은 사용자가 구글 계정을 통해 로그인을 하여 서비스를 이용할 수 있도록 제공합니다. 이때 앱 A는 리소스 소유자인 홍길동 대신 구글에 접근하여 홍길동의 인증 정보를 받아옵니다. 따라서 앱 A는 클라이언트 역할을 합니다.
2. Refresh Token
토큰을 주고 받는 환경이 보안에 취약해서, 토큰이 노출된다면?
토큰은 그 자체로 인증 수단이므로 서버는 누가 요청했는지 확인할 수가 없음.
토큰의 유효기간이 24시간이면, 도둑은 하루종일 토큰을 가지고 무엇이든 할 수 있음
❓ 그러면 토큰의 유효기간이 짧으면 되잖아요
사용자가 귀찮아 하잖아!!!!!!!!!!!!
이런 문제를 해결하기 위해 리프레시 토큰 등장
Refresh 토큰?
액세스 토큰이 만료되었을 때 새로운 액세스 토큰 (ex. JWT)을 발급하기 위해 사용
| 토큰 | 설명 | 유효기간 설정 |
|---|---|---|
| Access Token | 사용자 인증 | 짧게 |
| Refresh Token | 액세스 토큰 재발급 | 액세스 토큰보다 길게 |
토큰 도둑이 액세스 토큰 탈취해도 몇 분 뒤에는 쓸모 없어져서 안전하다.
리프레시 토큰 사용법
이전 글 - [Spring] 토큰 기반 인증, JWT
