정의
- JSON 객체를 안전하게 전송하기 위한 인터넷 표준 (RFC 7519)
특징
- 무상태성 : 요청이 있을 때마다 클라이언트의 상태를 유지하지 않음
- 확장성 : 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능
- 보안성 : 비밀키 없이는 토큰을 변조하지 못함
토큰 구조
토큰 구조는 Header, Payload, Signature로 나눠집니다.
Header
{
"typ": "JWT",
"alg": "HS256" // HMAC SHA256
}
- Header는 토큰의 타입을 나타내는 typ과 암호화할 방식을 정하는 alg로 구성되어 있습니다.
- 'alg'는 서명을 생성할 때 토큰에 서명하는 데 사용되는 알고리즘을 지정합니다
- 'typ'은 'JWT'인 토큰 유형을 지정합니다.
Payload
{
"id": "1234591",
"name": "Mary Poppins",
"role": "editor",
"iss": "mywebsite.com",
"exp": 3600
}
- Payload는 토큰에 담을 정보를 저장하며, 보통 만료 일시, 발급 일시, 발급자, 권한 정보 등을 저장합니다.
- id, name : 유저의 정보
- role : 유저 권한 정보
- iss(발급자) : 토큰 출처
- exp(만료 시간) : 토큰이 만료되는 타임스탬프
Signature
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret
)
- Signature는 인코딩 된 헤더, 인코딩 된 페이로드, 암호, 헤더에 지정된 알고리즘을 가져와서 생성합니다.
- 메시지가 도중에 변경되지 않았는지 확인하는 데 사용되며 개인 키로 서명된 토큰의 경우 JWT의 보낸 사람이 누구인지 확인할 수도 있습니다.
장점
- 추가 저장소가 필요 없음.
- 확장성
- 별도의 세션 저장소 관리를 필요로 하는 세션/쿠키 방식에 비해 간편하다
단점
- 한 번 발급되면, 유효기간이 다 될 때까지 삭제가 불가능
- Payload 정보가 디코딩하면 누구나 접근할 수 있기에 중요한 정보들을 보관할 수 없음.
- 세션에 비해 길이가 길기 때문에, 인증 요청이 많아지면 서버의 자원낭비가 발생
마무리
로그인 보안 방식 중 하나인 JWT에 대해서 공부한 내용을 정리해봤습니다.
최근 로그인 기능을 구현하다가 구현한 JWT 인증 방식이 제대로 구현한 게 맞는지 궁금해서 시작했지만, 생각보다 많은 고민들과 방식들이 있어서 정리가 덜 된 상태에서 마무리가 되는 거 같습니다. 추후에 여유가 되면 JWT 인증 방식에 대해서 다시 포스팅해야겠다고 생각이 드네요.
아직 부족하거나 틀린 부분이 있을 수도 있으니 주의하시면 좋을 거 같습니다.
이번 포스팅은 마무리하면서 다음 포스팅에서 뵙겠습니다.
참고