JWT 정리

JWT란?

RFC 7519 웹 표준으로 지정 되어 있고,

Json 을 사용해서 토큰 자체에 정보들을 저장 하고 있는 Web Token이라고 정의 된다.

 

RFC 7519

https://www.rfc-editor.org/rfc/rfc7519

RFC 7519: JSON Web Token (JWT)

 

JWT 공식 사이트

https://jwt.io/

JWT.IO

 

 

JWT (Json Web Token)의 구성

Header, Payload, Signature 로 .을 구분자로 나누어지는 3개의 부분으로 구성되어 있다.

(색깔 별로 구분해서 보자)

Header : Signature를 해싱하기 위한 알고리즘 정보가 담긴다.

-> 위 예시에서는 HS256 알고리즘

alg : 정보를 암호화할 해싱 알고리즘

typ : 토큰의 타입

 

Payload : 서버와 클라이언트가 주고 받는, 시스템에서 실제로 사용될 정보에 대한 내용들이 담긴다.

주로 클라이언트의 고유 ID, 유효 기간 등이 포함

참고로 key-value 형식으로 이루어진 한쌍의 정보를 Claim 이라고 말한다.

 

Signature : 토큰의 유효성 검증을 위한 문자열이다.

-> 해당 문자열을 통해 서버에서 해당 토큰이 유효한 토큰인지 위변조를 검증한다.

 

Signature는 인코딩된 Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성.

Header와 Payload는 단순히 인코딩 된 값이기 때문에 제 3자가 복호화 및 조작 할 수 있지만..

Signature는 서버 측에서 관리하는 비밀키로 복호화 할 수 있다.

 

 

 

JWT의 장점

1. JWT는 토큰에 대한 기본 정보와 전달할 정보 등 필요한 모든 정보를 자체적으로 가지고 있다.

-> 중앙의 인증 서버, 데이터 스토어에 대한 의존성이 없다.

-> 시스템 수평 확장에 용이하다. (Stateless)

2. Base64 URL Safe Encoding을 사용한다.

-> URL, Header, Cookie 모두 사용 가능하다.

3. 토큰 기반으로 동작하여, 다른 로그인 시스템에 접근 및 권한 공유가 가능하다.

 

JWT의 단점

1. Payload의 정보가 많아지면 트래픽이 증가한다.

-> 데이터 설계를 잘 해야함.

2. 토큰이 클라이언트에 저장되기 때문에, 서버에서 클라이언트의 토큰을 조작 불가능

3. 토큰 내부에 정보가 저장되기 때문에, 노출되면 안되는 정보를 저장하는 실수가 생길 수 있다.

4. 중간자 공격에 취약하다.

5. 토큰이 한번 발급되면 유효기간이 만료될때 까지 계속 사용이 가능하다..

-> 강제로 만료시키기가 어렵다. (서버에서 저장하고 있지 않음)

 

 

인증 과정

1. 클라이언트에서 로그인 요청

2. 서버는 검증 후 클라이언트 고유 ID 등의 정보를 payload 에 담는다.

3. 서버는 암호화할 비밀키를 사용하여 Access Token (JWT) 를 발급 후, 클라이언트에 전달한다.

(이때, 서버는 JWT를 서버에 저장하지 않는다. -> 세션 방식과 차이점)

4. 클라이언트는 전달 받은 토큰을 저장한다.

5. 클라이언트는 서버에 요청할 때마다 토큰을 요청 헤더 Authorization 에 포함 시켜 요청한다.

6. 서버는 토큰의 Signature를 비밀키로 복호화 하고, 위변조 여부와 유효기간 등을 확인한다.

7. 유효한 토큰이라면 요청에 응답