JWT

[kgneng2]

Intro

• JSON format을 이용한 Web Token
• JSON WEB TOKEN의 줄임말
• self-contained (필요한 모든 정보를 다가지고 있음)

• 보통 로그인 과정에서 많이 이용한다.
• 과거에 쿠키와 세션으로 로그인인증정보를 가지고 있었는데, 쿠키는 스니핑 당할위험이 있어 보안에 위험하고, 세션일 경우에는 서버에 저장하기 때문에 서버 과부하 및 서버 증설시 세션 정보 동기화로 불편함을 느끼게 된다. 또한 웹앱 두개간의 쿠기 처리가 다르기 때문에 처리방식을 다르게해야함
• 고로 토큰을 이용해서 통신하게 된다면 서버 상태값을 가지지 않고, 보안에도 강하게 이용할 수 있다.

기본구조

Header . Payload . Signature

Header

{
  "alg" : "HS256", // 해싱 알고리즘
  "typ" : "JWT" // 토큰 타입
}

• header는 암호화 하지 않고 base64 encoding 한다

Payload

• 실제 토큰으로 사용하려는 데이터가 담기는 부분. 각 데이터를 Claim이라고 하며 다음과 같이 3가지 종류가 있다.

Reserved claims : 이미 예약된 Claim. 필수는 아니지만 사용하길 권장. key 는 모두 3자리 String이다.

• iss (String) : issuer, 토큰 발행자 정보
• exp (Number) : expiration time, 만료일
• sub (String) : subject, 제목
• aud (String) : audience, 토큰 대상자
• iat : 토큰이 발급된 시간
• More

Public claims : 사용자 정의 Claim.

• Public 이라는 이름처럼 공개용 정보
• 충돌 방지를 위해 URI 포맷을 이용해 저장한다.

{
   "https://fdnsnflwnefl~~" : true
}

Private claims : 사용자 정의 Claim

• Public claims 과 다르게 사용자가 임의로 정한 정보
• 아래와 같이 일반 정보를 저장한다.

  {
  "loginId" : "kgeng2"
  "userId" : "1234"
  }

Signature

• 헤더의 인코딩 값과, 정보의 인코딩 값을 합친후 주어진 비밀키로 해쉬를 생성한다.
• . 을 이용해서 아래와 같이 합친다.

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

결과

• 위에서 만든 header와 payload json을 base64 encoding 후 . 으로 합치고, signature를 뒤에 붙인다.
• 요청은 Authorization : Bearer 을 이용해서 처리한다.

Verify

• https://jwt.io 에서 확인할수 있다

단점 ?

• 토큰 자체에 정보가 있다는게 문제가 될 수 있다. Payload에 다있고,, 암호화 방식도 있으니깐..
• 토큰을 한번 생성하면 서버에서 제어가 힘들다. 만료시간을 꼭 생성해서 처리한다.

Reference

• https://sanghaklee.tistory.com/47
• https://velopert.com/2389