JWT(Json Web Token)란 Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token이다. JWT는 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달한다. 주로 회원 인증이나 정보 전달에 사용되는 JWT는 아래의 로직을 따라서 처리된다.
1.Header( alg = 알고리즘 방식, typ = 토큰의 타입)
2.PayLoad( 토큰에 담을 필요로 하는 정보 Claim을 이용해 설정)
3.Signature ( 헤더의 알고리즘 방식으로 페이로드를 암호화하여 표기)
구조와 사전적 의미를 좀 더 알고싶다면 https://mangkyu.tistory.com/56 를 참고!
- Cookie
- Cookie + Session
- JWT
http 와 stateful 한 관계가 유지된다면 서버 스케일아웃 후에 이슈가 생길 수 있다.
예를들면 A서버에 로그인 -> stateful 관계형성 LB에 의하여 다음 요청이 B서버로 감 (로그인 정보가 없음-> 다시로그인 시도요청)
해결책으로 sticky 세션이 존재하지만 이또한 문제점이 발생( 특정서버에 요청이 몰릴수 있음)
가장 큰 장점으로 stateless 하다. (인증 정보가 토큰에 들어있어 저장소 불필요)
단점은 모든 요청에 토큰이 포함되 트래픽 자연스럽게 증가함.
페이로드는 base64로 인코딩 된 것 이므로 탈취가능( 페이로드에 중요정보 절대 X)
보안에 100%는 없으므로, 토큰도 탈취가 가능해서 Access가 타의에 의해가능한 경우가 생긴다.
이러한 경우를 대비하여 AccessToken의 유효시간은 짧게, Refresh Token의 유효시간은 길게 생성하여 두개의 토큰을 관리하도록 하자.
근데 둘다 동시에 탈취당하면 ??
-> 이것을 방지하기위해 AccessToken 은 로컬 또는 세션스토리지에 저장하고,
Refresh Token 은 쿠키에 보안옵션( HTTP Only, SecureCookies) 를 황성화 하여 저장하도록 하자. Refresh Token 은 검증을위해 서버에도 저장되있어야 한다.
사실 Refresh Token 을 서버에 저장한다는건 Stateless하다고 할수 없다.
하지만 session은 매번 저장소에 접근하지만, jwt토큰은 access Token 이 만료 되었을 때 만
저장소에 접근하기 때문에 횟수가 다르다고 생각한다.
때문에 Refresh Token 을 클러스터링 서버에서 보관하여 Access Token 만료시에만 검증을
하는 방식으로 사용한다면 많은 트래픽이 몰리는 서비스에서 유용하다고 생각된다.