JWT(JSON WEB TOKEN) 개념

JSON Web Token

정의: 어려움....

JWT(Json Web Token)은  클레임 기반 토큰이며, 이름에서 알 수 있는 것처럼 JSON을 이용한 토큰이고 웹 표준(RFC 7519)를 구현한 것이다. 자세한 것은JWT 공식페이지에서 확인 가능하다.

 

쉽게 말해 JSON을 이용한 토큰 , self-contained데이터를 저장하는 토큰이다.

 

다음과 같은 구조이다. 

 

---

헤더(header)

구성

• 타입 : JWT 토큰 유형이다.
• 알고리즘 : HMAC, SHA256 또는 RSA와 같은 해시 알고리즘을 사용

{ 
  "typ": "JWT", 
  "alg": "HS256" //HS256 = HMAC+ SHA-256
}

위의 json을 base64로 인코딩 하여 토큰의 첫번째 헤더부분에 위치 한다.

• ex) eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

---

정보(payload)

클레임(claim) : 페이로드의 각각의 정보를 의미한다. key/value로 json형식이다.

 

 

등록된 (registered) 클레임 

이미 정해진 key들이다, 모두 optional이다.

• iss: 토큰 발급자 (issuer)
• sub: 토큰 제목 (subject)
• aud: 토큰 대상자 (audience)
• exp: 토큰의 만료시간 (expiraton), 시간은 NumericDate 형식으로 되어있어야 하며 (예: 1480849147370) 언제나 현재 시간보다 이후로 설정되어있어야합니다.
• nbf: Not Before 를 의미하며, 토큰의 활성 날짜와 비슷한 개념입니다. 여기에도 NumericDate 형식으로 날짜를 지정하며, 이 날짜가 지나기 전까지는 토큰이 처리되지 않습니다.
• iat: 토큰이 발급된 시간 (issued at), 이 값을 사용하여 토큰의age가 얼마나 되었는지 판단 할 수 있습니다.
• jti: JWT의 고유 식별자로서, 주로 중복적인 처리를 방지하기 위하여 사용됩니다. 일회용 토큰에 사용하면 유용함

공개 (public) 클레임

공개 클레임은 서로 충돌이 일어나지 않는 이름을 가지고 있어야한다.

그래서URL형태로 작성하며 예시는 아래와 같다.

 

{ "https://ka0oll.tistory.com": true }

 

비공개 (private) 클레임

양 측간에 (보통 클라이언트 <->서버) 협의하에 사용되는 클레임

{ "username" : "ka0oll" }

 

최종값이다.

{
  "sub": "1234567890",
  "https://ka0oll.tistory.com": true,
  "username" : "ka0oll"
}

---

서명(signature)

( 헤더의 인코딩값 + payload의 인코딩값 ) 을 해시 적용  +  base64 인코딩

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

)

이렇게 만든 해쉬를, base64형태로 나타내면 됩니다.

---

JWT 사용이유?

• 기존 인증 토큰 기반은 발급자가 토큰에 정보를 담을수 없다. 토큰으로 인증 요청을 처리하기 위해  발급자(서버)가 유효기간, 사용자 권한 등을 관리해야하고 인증시마다 조회를 해야한다. 보통 데이터베이스를 저장하고 조회하여 비용이 많이 들어 캐시등을 이용한다.
• 하지만 JWT토큰은 self-contained 방식을 사용함으로써 토큰 자체가 데이터를 가질수 있어, 토큰 값만으로도 유효성과 권한검증을 진행 할수있다.

장점

• Self-contained : JWT가 다른 토큰하고 가장 다른 부분은 토큰 자체가 데이터를 가지고 있다는 점이다.
• Stateless를 지향 : 세션같이 서버에서 유저정보에 상태 관리 필요없다.
• 서명 : 서명이 있어 데이터의 무결함을 검증할수있다.

단점

• 보안 :클레임셋은 암호화하지 않는다. 누구나 열어볼수있으므로 중요한 데이터는 넣지 않아야 한다. 필요한 정보만 담아야 한다.
• 크기 클레임셋의 내용이 많아지면 토큰의 길이도 같이 길어진다. 그래서 편하다고 너무 많은 정보를 담으면 안 된다.
• 만료 : 토큰을 강제로 만료시킬 방법이 없다. 서버가 토큰의 상태를 가지고 있지 않고 토큰 발급 시 해당 토큰이 유효한 조건이 결정되므로 클라이언트가 로그아웃하더라도 해당 토큰을 클라이언트가 제거하는 것뿐이지 토큰 자체가 만료되는 것은 아니다. 만약 이때 누군가 토큰을 탈취한다면 해당 토큰을 만료시간까지는 유효하게 된다. 많은 고민을 해보았지만 무상태를 유지하면서 이 부분을 같이 해결할 방법은 존재하지 않으므로 서비스에서 이 부분이 문제가 된다면 선택을 해야 한다고 본다.

 

언제사용?

회원 인증

JWT 를 사용하는 가장 흔한 시나리오 입니다. 사용자가 로그인을 하면, 서버는 사용자의 정보를 기반으로한 토큰을 발급합니다.
그 후, 사용자가 서버에 요청을 할 때 마다 JWT를 포함하여 전달합니다. 서버는 클라이언트에서 요청을 받을때 마다, 해당 토큰이 유효하고 인증됐는지 검증을 하고, 사용자가 요청한 작업에 권한이 있는지 확인하여 작업을 처리합니다.
서버에서는 사용자에 대한 세션을 유지 할 필요가 없습니다. 즉 사용자가 로그인되어있는지 안되어있는지 신경 쓸 필요가 없고, 사용자가 요청을 했을때 토큰만 확인하면 되므로 세션 관리가 필요 없다.

 

정보 교류

정보에 서명이 되어있어, 데이터의무결성, 위조 되지 않음을 검증할수있어 데이터 전송에 유용하다.

JWT는 두 개체 사이에서 안정성있게 정보를 교환하기에 좋은 방법입니다. 그 이유는, 정보가 sign 이 되어있기 때문에 정보를 보낸이가 바뀌진 않았는지, 또 정보가 도중에 조작되지는 않았는지 검증할 수 있습니다.