참고링크
JWT
- JSON Web Token
- 클라이언트와 서버, 서비스와 서비스 사이 통신 시 권한 인가(Authorization)를 위해 사용하는 토큰
- URL-safe의 JSON. URL에 대해 안전한 문자열로 구성
- 웹 표준으로서 두 개체에서 JSON 객체를 사용하여 가볍고 자가수용적인(self-contained) 방식으로 정보를 안정성 있게 전달
- 자가수용적
- JWT는 필요한 모든 정보를 자체적으로 지니고 있음. JWT 시스템에서 발급된 토큰은 토큰에 대한 기본정보, 전달 할 정보(로그인 시스템에서는 유저 정보) 그리고 토큰이 검증되었다는 것을 증명해주는 signature를 포함하고 있음
- 쉽게 전달 할 수 있음.
- 웹 서버의 경우 HTTP의 헤더에 넣어서 전달 할 수도 있고, URL의 파라미터로 전달할 수도 있음
JWT 활용
- 회원 인증
- 가장 흔한 JWT 시나리오
- 유저가 로그인 → 서버는 유저의 정보에 기반한 토큰을 발급하여 유저들에게 전달. 그 후 유저가 서버에 유청을 할 떄마다 JWT를 포함하여 전달.
- 서버는 클라이언트에게서 요청을 받을 때 마다 해당 토큰이 유효하고 인증됐는지 검증. 유저가 요청한 작업에 권한이 있는 지 확인하여 작업을 처리
- 서버 측에서는 유저의 세션을 유지할 필요가 없음. 유저가 로그인 했는지 안했는지 신경 쓰지 않아도 되고, 유저가 요청을 했을 때만 토큰을 확인. 세션 관리가 필요 없으니 서버 자원을 많이 아낄 수 있음
- 정보교류
- JWT는 두 개체 사이에서 안정성 있게 정보를 교환하기에 좋은 방법
- 정보가 sign이 되어있기에 정보를 보낸이가 바뀌진 않았는지 또 정보가 도중에 조작되지는 않았는지 검증할 수 있음
JWT 토큰 구성
- 크게 세 가지 파트로 나뉨. 각 파트는 .(점)으로 구분. 순서대로 header/payload/signature
- header
- 토큰의 타입(jwt)과 해시 암호화 알고리즘(보통 HMAC SHA256 / RSA)으로 구성
- payload
- 토큰의 내용, 전달할 내용(사용자 정보, 권한, 서비스에 필요한 데이터)을 자유롭게 담을 수 있음
- payload에 담는 정보의 한 조각을 클레임이라고 부름. 이는 name: value의 한 쌍으로 이뤄져있음. 토큰에는 여러개의 클레임들을 넣을 수 있음.
- 클레임의 정보는 등록된(registerd) 클레임, 공개(public) 클레임, 비공개(private) 클레임으로 세 종류가 있음
- 등록된 클레임
- iss: 토큰 발급 대상자
- sub: 토큰 제목
- aud: 토큰 대상자
- exp: 토큰의 만료 시간
- signature
- 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드
- signiture은 위에서 만든 header와 payload의 값을 각각 BASE64로 인코딩하고 인코딩한 값을 비밀 키를 이용해 header안에서 정의한 알고리즘으로 해싱을 하고 이를 다시 인코딩하여 생성
- 헤더와 페이로드가 위 변조 되지 않았다는 것을 검증
JWT의 장점
- 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요 없음
- 따라서 서버에 대한 자원을 절약 할 수 있음. 인증과정에서 다른 곳을 거칠 필요가 없어 효율적. 또한 인증 정보를 가진 특정 서버에만 트래픽이 몰릴 일이 없음. 서버 부하를 줄이기 위한 좋은 방식
- MSA 환경에서 중앙 집중식 인증 서버와 데이터베이스에 의존하지 않은 쉬운 인가 방법을 제공
- 수평 스케일이 용이
- URL 파라미터와 헤더로 사용
- 만료가 내장. 독립적임
JWT의 단점
- 외부 공격자가 접근하기 쉬운 위치. 노출 가능한 정보
- 토큰은 클라이언트에 저장되어 데이터 베이스에서 사용자 정보를 조작하더라도 토큰에 직접 적용할 수 없음
- 더 많은 필드가 추가되면 토큰이 커질 수 있음
- 비상태 애플리케이션에서 토큰은 거의 모든 요청에 대해 전송되므로 데이터 트래픽 크기에 영향을 미칠 수 있음
