[Concept] JWT(Json Web Token)?

JWT

---

JWT는 Json Web Token의 약자로 토큰에서 사용되는 컨텐츠를 Json으로 구성해 토큰화하는 시스템을 말한다. 즉, Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Web Token 이라고 설명할 수 있다. JWT가 다른 토큰과 다른점은 토큰 자체가 데이터를 가지고 있다는 점이다.

 

JWT를 사용하면 토큰 자체가 데이터를 가지고 있기 때문에 서버가 stateless할 수 있다. 또한 인증을 위해 데이터베이스를 조회해야 하는 오버헤드를 줄일 수 있다는 장점이 있다.

 

JWT를 사용하지 않을 때는 발급한 토큰을 서버측 DB에 저장한 후 올바른 토큰인지 검증했다. 따라서 여러 개의 서비스를 사용할 경우 저장된 토큰을 공유해야하는데 문제가 발생하고 위에서 언급한 데이터베이스 조회시 필요한 오버헤드도 발생한다. 해당 내용 관련해서 좋은 포스팅이 있어 추가적으로 내용을 첨부한다.

https://blog.outsider.ne.kr/1160

JWT의 구성

---

JWT가 어떻게 구성되어 있는지 살펴보자. 기본적으로 JWT는 Header, Claim Set, Signature 세 부분으로 구성되어 있다. 그리고 최종적으로 각 부분이 Base64로 인코딩되어 하나의 토큰이 된다.

Header

JWT의 Header는 다음과 같이 구성되어 있는데 해당 토큰이 어떤 알고리즘을 통해 암호화되었는지, 그리고 토큰의 타입은 어떤것인지에 대한 정보를 포함하고 있다.

Claim Set

Claim Set은 JWT에 Json 포맷으로 데이터를 저장하기 위한 부분이다. 위 사진에는 현재 3가지 데이터가 포함되어 있고 이러한 데이터를 Claim이라고 표현한다.

 

하지만, 이러한 Claim안에서도 여러가지 종류가 있을 수 있다.

그 중에서 이미 등록된 Claim이 기본적으로 제공된다. 따라서 개발자는 해당 Claim 명칭을 다른 용도로 사용하면 문제가 발생할 수 있다.

• iss: 토큰 발급자(issuer)
• sub: 토큰 제목(subject)
• aud: 토큰 대상자(audience)
• exp: 토큰 만료 시간(expiration), NumericDate 형식으로 되어 있어야 함 ex) 1480849147370
• nbf: 토큰 활성 날짜(not before), 이 날이 지나기 전의 토큰은 활성화되지 않음
• iat: 토큰 발급 시간(issued at), 토큰 발급 이후의 경과 시간을 알 수 있음
• jti: JWT 토큰 식별자(JWT ID), 중복 방지를 위해 사용하며, 일회용 토큰(Access Token) 등에 사용

 

Signature

Signature은 해당 토큰을 누가 발급하고 누가 만든 토큰인지 검증하기 위한 부분이라고 생각하면 된다. 즉, 토큰의 무결성을 검증하기 위해 존재하는 부분이라고 생각하면 된다.

 

따라서 여기에 사용된 Secret Key는 절대 외부에 노출되어서는 안되며, 토큰을 발급하는 부분과 검증하는 부분에서 해당 Secret Key를 보유하며 토큰의 무결성 검증을 수행할 수 있다.

 

따라서 해당 Secret Key는 Property 파일과 같은 곳에 별도로 분리해 관리하거나 안전한 Configure Service를 통해 관리하는 것이 좋다고 한다. (물론 다양한 관리방법이 존재할 수 있다.)

JWT 사용

---

이렇게 생성된 JWT 토큰은 HTTP 통신시 Authorization 이라는 Request Header에 포함하게 된다.

{ 
	"Authorization": "Bearer {생성된 토큰 값}",
}

HTTP Request를 받은 서버는 해당 Header 값을 읽어와 검증과정을 거치고 올바른 토큰이라고 판단되었을 때 이후 과정을 진행하게 된다.

주의할점

---

1. Claim Set은 암호화되지 않기 때문에 민감한 데이터를 포함해서는 안된다.
   암호화 되지 않기 때문에 Token이 노출되었을 때 누구나 해당 값을 뜯어볼 수 있기 때문이다.
   -> Claim Set에는 인증에 관련된 Context만 포함시키는 것이 좋다.
2. Claim Set이 Base64로 인코딩되기 때문에 Claim Set에 저장되는 데이터가 많아질수록 Token의 길이가 길어진다. 따라서 반드시 필요한 데이터만 저장해야 하며 Key의 길이를 최소화하는 것이 좋다. (iss, sub과 같은 표준 Claim의 식별자가 3글자인 이유이다)
3. Token이 Client에 저장되기 때문에 강제로 만료시킬 방법이 없다.
4. Token을 Client에 저장해야 한다.
   하지만 네이티브 앱이 아니라 웹 브라우저 상에서 Client가 안전하게 데이터를 저장할만한 곳이 없다고 한다. 따라서 내부 시스템이 아닌 경우에는 Token 인증 방식을 사용하지 않는다는데 그러면 뭘 사용하는지는 더 찾아봐야 할듯하다...
5. 이미 발행한 Token을 Revoke하기 어렵다.
   따라서 권한이 자주 변경되는 환경에서 사용이 어렵다. Token에 대한 Black List를 관리하는 대응책이 있긴하다.