JWT의 구조 정리

JWT의 구조

 

HEADER.PAYLOAD.SIGNATURE

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.PjndlgESbR_7uPWq7tKFd6o7l799Y45mU5KvDcO2nPI

 

 

HEADER

• JWT 검증하는데 필요한 정보 가진 객체
• Header의 정보를 UTF-8 인코딩 -> Base64 인코딩한 값 저장 ( 단순 인코딩만 했기에 암호화된 값은 아님!!)
  • {"alg":"HS256","typ":"JWT"} -> eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

PAYLOAD

• 실질적으로 인증에 필요한 데이터를 저장함
• 데이터의 각각 필드들을 Claim 이라고 한다.
• 대부분의 경우에 Claim에 username을 포함한다.
• 인증할 때 payload에 있는 username을 가져와서 유저 정보를 조회할 때 사용하는 경우가 많기 때문이다.
• 그리고, 토큰 발행시간(iat)와 토큰 만료시간(exp)를 포함한다.
• Claim을 얼마든지 추가해도 되지만 민감한 정보는 포함시키면 안된다. (PAYLOAD는 암호화 되어 저장되지 않기 때문)
• PAYLOAD의 정보를 UTF-8 인코딩 -> Base64 인코딩한 값 저장 ( 단순 인코딩만 했기에 암호화된 값은 아님!!)
  • {"sub":"1234567890","name":"John Doe","iat":1516239022} -> eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ==

Signature

• Header와 Payload는 json -> utf8 -> base64로 단순 변환한 값임(암호화X)
• 그래서 Header와 Paylaod 만으로는 토큰의 진위여부 판단은 불가능함
• 그래서 JWT 구조에서 가장 마지막에 있는 Signature 부분을 토큰의 진위여부를 판단하는 용도로 사용한다.
• 헤더, 페이로드 값을 SECRET KEY로 해싱하고, 그 결과 값을 Base64로 인코딩함
  • base64UrlEncode( Hashing( base64UrlEncode(Header) + base64UrlEncode(Body), SECRET_KEY ) )

 

요약 정리

• Header에는 시그니처를 검증하는데 필요한 정보가 들어있다.
• Payload에는 인증을 위한 정보가 들어있다.
• 시그니처에는 토큰 자체를 검증하고, 위변조 가능성을 막기 위해 존재한다.
  • 비밀키를 사용해서 암호화된 해시 값으로 존재함

아래 url은 차례대로 utf8 인코딩, base64 인코딩 확인하는 URL

https://coderstoolbox.net/string/#!encoding=none&action=encode&charset=utf_8

https://www.convertstring.com/ko/EncodeDecode/Base64Encode

 

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.PjndlgESbR_7uPWq7tKFd6o7l799Y45mU5KvDcO2nPI

 

 

refresh token 관련

https://velog.io/@jkijki12/Jwt-Refresh-Token-%EC%A0%81%EC%9A%A9%EA%B8%B0

Jwt Refresh Token 적용기

https://dkswnkk.tistory.com/684