백엔드 개발 블로그
JWT의 구조 및 사용 예 본문
- JSON Web Token
- RFC 7519 표준
- 흔히 로그인 데이터 등을 주고 받는 데에 사용된다.
- JSON 형태의 데이터에 서명 정보를 추가하여 데이터의 위변조 여부를 검사할 수 있다.
- 서명에는 HMAC, RSA 등의 암호화 기법이 사용된다.
- HMAC 참고: https://blog.honeybomb.kr/7
데이터 구조
"헤더.페이로드.서명"
의 형태이다.- 헤더에는 서명에 사용된 알고리즘과 타입을 담고 있는 JSON이 Base64 URL 형태로 인코딩된다.
- 페이로드는 실제 전송되는 데이터를 담고 있으며 데이터 JSON이 Base64 URL 형태로 인코딩된다.
- 서명은 헤더에 명시된 알고리즘을 사용하여 헤더 및 페이로드 데이터를 서명한 문자열이다.
클레임(Claims)
- 페이로드에 사용되는 JSON은 정해진 데이터 포맷은 없으며 자유롭게 사용할 수 있다.
- 단, 여러 시스템 간의 호환성을 위하여 미리 정해진 필드명 등이 있는데, "exp", "email", "profile" 등이 있다. 이를 클레임(Claims)이라고 한다.
- 등록된 클레임과 공개 클레임 목록은 https://www.iana.org/assignments/jwt/jwt.xhtml 링크를 참고한다.
1. 등록된 클레임 (Registered Claims)
- 필수는 아니지만 JWT 사용 시 흔히 사용되는 필드들로서 여러 시스템 간 호환성을 위해 구현하도록 권장된다.
- "iss", "aud", "exp" 등이 이에 해당된다.
- 하지만 단순 웹서비스 인증 용도를 위해서는 "exp" 정도 외에는 사용할 일이 많이 없을 듯 하다.
- "exp" 필드는 초 단위의 unix timestamp 데이터로서 토큰의 만료기한을 나타낸다.
2. 공개 클레임 (Public Claims)
- JWT에서 흔히 쓰이는 데이터를 위해 필드명을 미리 정해둔 것이다.
- "email", "profile" 등이 이에 해당된다.
- 공개 클레임으로 정해진 필드명이 있다면 되도록 규약에 따르는 것이 권장된다.
3. 비공개 클레임 (Private Claims)
- 등록된 클레임도, 공개 클레임도 아니기 때문에 자유롭게 사용할 수 있는 필드명들이다.
JWT 사용 예
- 클라이언트는 ID 및 패스워드를 사용해서 최초 인증을 수행한 뒤 권한 정보가 담긴 JWT 토큰을 획득한다.
- 이후 기타 리소스에 접근하기 위한 API 요청을 보낼 때, "Authorization: Bearer" 헤더 등에 JWT 토큰을 함께 전송한다.
- 서버는 클라이언트가 함께 전송한 JWT 토큰으로부터 리소스에 대한 접근 권한을 확인한다.
- JWT의 서명이 올바르고, 만료되지 않은 토큰이면서 리소스에 대한 접근 권한이 있다고 판단되면 리소스를 클라이언트에게 반환한다.
JWT의 장점 (기존 세션 구조와의 차이)
- 세션 방식의 인증을 사용할 경우 인증 정보를 별도의 인증 DB에 저장해야 한다. 또, 리소스 요청마다 DB를 조회해야 하는 부담이 있다.
- JWT는 무상태(stateless) 토큰으로서 인증 정보를 DB 등에 저장하지 않고 토큰에 포함시키기 때문에, 별도의 저장소가 필요 없다.
- 따라서 JWT를 사용하면 DB 부하를 줄이고 요청 응답 시간을 빠르게 할 수 있다.
- MSA 구조 등에서 응답 시간을 빠르게 할 수 있고, 수천만 명의 유저가 동시 접속할 때에도 수평적 확장이 용이하다.
JWT 사용 시 주의사항
- JWT의 페이로드는 일반적으로 암호화되지 않기 때문에, 페이로드 데이터에 민감한 정보를 포함해서는 안된다. (개인정보, 패스워드 등)
- 평문은 아니어서 사람이 바로 읽을 수는 없지만, Base64 URL 형태로 인코딩된 것이기 때문에 디코딩이 아주 쉽다.
- JWT는 데이터에 서명을 할 뿐, (대부분의 경우) 암호화하는 것이 아니다.
- 세션을 사용할 경우 서버 측에서 강제로 로그아웃시킬 수 있지만, JWT를 사용할 경우 로그아웃이 힘들다.
- JWT는 토큰의 크기가 상대적으로 크기 때문에 트래픽 오버헤드가 생긴다. 따라서 페이로드 데이터는 되도록 간결해야 한다.
- 토큰 유출의 문제 등으로 인해 Refresh Token과 Access Token을 분리하여 사용하기도 한다. 관련 자료는 나중에 정리할 예정.
참고 자료
'인증 & 보안' 카테고리의 다른 글
HMAC의 구조 및 필요성 (0) | 2022.08.31 |
---|
Comments