JWT

JWT (JSON Web Token)

JWT는 JSON 객체를 안전하게 전송하기 위한 인터넷 표준 방법(RFC 7519)이다. JWT는 전자 서명 되었기 때문에 데이터가 검증되고 신뢰할 수 있다. JWT는 HAMC 알고리즘 또는 RSA · ECDSA를 사용한 공유/개인 키로 서명한다.

JWT 활용 예

• 인증(Authentication) 및 권한 부여(Authorization) : JWT를 사용하는 가장 일반적인 시나리오이다. 사용자가 로그인을 하면 서버 측에서 JWT를 발급한다. 이후 사용자는 다음부터 JWT를 포함해 요청하고 서버 측에서 JWT 검증에 성공하면 서버는 요청한 사용자가 인증 및 권한이 부여된 사용자임을 알 수 있다. 쉽게 말해 JWT는 서버에 인증 및 권한 부여를 받을 수 있는 출입증과 같다. 
• JSON 교환 : JSON 객체를 안전하게 전송하는 좋은 방법이다.

JWT 구조

JWT는 점으로 구분된 세 부분으로 구성되며 세 부분은 각각 Header, Payload, Signature이다. xxxxx.yyyyy.zzzzz 식의 구조를 가진다.

• Header
• Payload
• Signature

JWT

 

Header

헤더는 토큰 유형(JWT)과 사용 중인 서명 알고리즘(예: HMAC SHA256 또는 RSA 등)의 두 부분으로 구성된다.

{"alg":"HS256","typ":"JWT"}

위 JSON 객체를 Base64Url로 인코딩하면 JWT의 Header가 된다.

 

PayLoad

페이로드는 클레임을 담는다. 클레임이란 Key-value 형식으로 이루어진 한 쌍의 정보를 말하며 토큰에 데이터를 포함하고 싶을 때 PayLoad 부분에 클레임을 포함해주면 된다. 클레임은 Registered claims, Public claims, Private claims로 구분된다.

 

1. Registered claims : 미리 정의된 클레임 집합

• iss(issuer : 발행자)
• exp(expireation time : 만료 시간)
• sub(subject : 제목)
• iat(issued At : 발생 시간)
• jti(JWI ID)

2. Public claims : 공용 레지스트리에 명시된 클레임 집합

3. Private claims : 당사자들 간의 정보 교환을 위한 사용자 지정 클레임

 

주의할점은 JWT는 전자서명 되었을 뿐 암호화가 되어있지 않다. 따라서 위변조를 방지할 수 있지만 누구나 읽을 수 있다는 점에 주의해야한다. PayLoad에 중요한 정보를 담아서는 안되며 만약 담고 싶다면 암호화 한 뒤 보내야 한다.

{"sub":"1234567890","name":"John Doe","admin":true}

위 JSON 객체를 Base64Url 인코딩하면 JWT의 PayLoad가 된다.

 

Signature

signature은 인코딩된 헤더, 페이로드를 헤더에 명시된 알고리즘으로 서명해 생성한다. 예를 들어 HS256(HMAC SHA256)을 사용하는 경우 Signature은 다음과 같이 생성된다.

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

마지막으로 Header, PayLoad, Signature 순으로 .을 붙여 구분하면 JWT가 완성된다. 아래 사이트에서 JWT를 인코딩, 디코딩 해볼 수 있다.

https://jwt.io/

JWT.IO

JWT를 통한 인증

많은 앱에서 JWT등의 토큰 기반 인증 방식을 채택한다. 왜 그럴까? 필자가 생각하는 이유는 2가지이다.

 

1. Stateless : 웹서버가 Stateless를 유지함으로써 시스템 관리와 확장성이 용이해진다.

2. DB 병목 현상 방지 : 사용자 정보가 JWT에 있으므로, DB 조회가 필요없다.

 

먼저 웹서버가 Stateless를 유지할 수 있다. 서버가 최대한 Stateless 하도록 구성되면 시스템 관리와 확장성이 용이해진다. 또한 많은 요청이 발생하는 앱에서는 DB 병목 현상을 고려해야 한다. (사용자 요청) * (DB 커넥션 개수) 만큼 DB 커넥션이 생기므로, 동접자가 백만까지 된다면 DB 커넥션은 대략 800만개가 생성된다. 하지만 생성할 수 있는 DB 커넥션 수는 제한되어 있기에 DB 병목 현상이 발생할 수 있다. 이때 인증/인가와 관련된 커넥션이라도 줄이기위해(대략 20퍼 정도) JWT를 사용한다.