JWT 다시 정리

참고링크

0. 등장 배경

• 세션과 쿠키를 이용하여 인가하는 과정에서 여러 서버가 생겨나면서 발생한 문제에서 나옴.(세션은 한 서버에서만 활동하는데 서버가 여러 개가 나온다면..?!)

1. 특징 : 자가 수용적(Self-Contained)

무슨말인가하면, 필요한 모든 정보를 자체적으로 지니고 있다는 뜻.

-토큰의 기본 정보, 전달할 정보(e.g. 유저 정보), 토큰이 검증되었다는 증명인 signature

그래서 쉽게 전달 될 수 있다.

e.g HTTP 헤더에 넣어서도, URL 파라미터로도 전달 할 수 있다.

2. 언제 쓸까? : 주로 회원인증에 쓰이지만 정보 교류에도 쓰인다.

회원 로그인 상황

유저 로그인 -> 서버가 토큰 발급하여 유저에게 전달 -> 클라이언트 요청 받을 때마다 토큰 유효성 서버가 검증

그렇다면 토큰은 어디에 저장되는가??

클라이언트가 토큰을 받으면 이를

1. 웹스토리지, 혹은 세션 스토리지에 넣고 요청할 때마다 HTTP 헤더 값에 넣어서 요청한다. -> XSS 해킹 공격에 노출된다.(악성스크립트 노출)
2. 쿠키에 넣는다.(전송수단) -> 쿠키에 한정된 도메인에서만 사용된다는 점과 CSRF 공격(사이트 외부에서 사이트 API를 사용하는 것처럼 모방하는 것)

3. 생김새

1. Header

• typ : 토큰의 타입, JWT
• alg : 해싱 알고리즘 지정, SHA256, RSA...

2. Payload : 토큰에 담을 정보가 들어있다.

정보의 조각 : claim(name / value 쌍) -> 등록된, 공개, 비공개 클레임으로 나눔

• 등록된 클레임 : 서비스에 필요한 것이 아닌 토큰에 대한 정보를 담기 위해 이름이 이미 정해진 클레임들(토큰 관련 내용들)

• 공개 클레임 : 충돌이 방지된 이름을 가지고 있다. URI 형식으로 짓는다

• 비공개 클레임 : 등록도 공개도 아닌 클레임들. 클라이언트 - 서버 협의하 사용되는 클레임 이름들(이름이 중복되어 충돌이 일어날 수 있다)

3. Signature : 헤더, 페이로드의 인코딩값을 합한 후 비밀키로 해쉬해서 생성