JWT

단순하게만 설명하자면 그림과 같이 Header + Payload + Signature로 구성된 JSON Web Token 입니다.

JWT를 쓰는 이유

세션은 유저의 상태를 저장할 수 있는 보편적인 기술이다. 하지만 세션으로 인해 서버는 Session-Stateful하게 운영할 수 밖에 없어서 그로 인해 스케일링에서 발생하는 세션 데이터에 대한 데이터 불일치, 성능 등의 문제와 세션 그 자체가 상수가 아니고 지속적으로 변화하고 갱신되는 데이터 이기에 유지보수 비용이 발생.

=> JWT는 그 자체로 인증에 필요한 모든 요소를 갖췄기에 Session-Stateless한 아키텍쳐를 가능하게 함.

JWT 특징

구조

• Header : 토큰 타입과 해싱 알고리즘 방식을 담고 있음
• Payload : 토큰의 여러 정보를 담아내고 정보의 한 조각을 name/value의 한 쌍으로 이루어진 Claim 이라 부름
• Signature : 토큰의 유효성을 검증, Header의 인코딩값과 Payload의 인코딩값을 합친 후 주어진 비밀키로 해싱하여 생성

3가지는 본래에 JSON Format으로 존재하고 이를 각각 Base64 인코딩하여 마침표로 합치면 안전하고 여러 위치에서 활용 가능한 문자열 토큰이 완성됨.

https://jwt.io
JWT 사이트로 이동하면 인코딩 이전의 원형이 어떤 모양인지 대략 느껴볼 수 있음

Access Token

JWT는 OAuth 2.0 인증에서의 Access Token 그 자체라고 할 수 있음. 때에 따라서 JWT보다 보안이 취약한 형태의 Access Token을 사용할 수도 있다. OAuth 2.0이라는 강력하고 유연한 인증 프로토콜에 Access Token 자체를 안전하고 의미 있게 만들어주는 JWT가 결합되면 상당한 효과를 보게 됨. 뿐만아니라 JWT는 OAuth 2.0을 벗어나서 모든 Stringify Token에 적용할 수 있습니다.

단점

• 보통 세션에서 취급하는 Cookie Session ID 보다 큰 사이즈의 문자열
• Payload에 따라 secret한 정보를 취득할 수 있음
• 스스로 만료주기를 가지기에 임의로 제어 불가능
• 탈취되면 위험한 건 같음