JWT 에 대한 내용을 설명합니다.

1. JWT (JSON Web Token)

2. ● 웹 표준 중 하나 - RFC 7519
● 수많은 프로그래밍 언어에서 라이브러리를 지원함
● 자가 수용적 (Self-contained)
● 쉽게 전달할 수 있음
주요 특징

3. ● Header, Payload, Signature 로 구성되어 있고 각각을 순서대로 period(.) 으로
연결함
내용물
eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJ2aWRlb0lkIjoiazFuTDBNb1FhQV
Z4dzJtSzA2V040OWI4T1JsSmpwM0UiLCJ2ZXJzaW9uIjoiMS4wIiwiaWF0IjoxN
TExOTUyMDM1LCJleHAiOjE1MTE5NTU2MzUsImF1ZCI6IntcIm1lZGlhSWRcIjp
cIkwzQllYUHlwVjJXZThEOXdaSkExTTV3T3haYXJqZ2I2XCIsXCJ1c2VySWRcIj
pcIldFQjpGSU5HRVJQTFVTOjkxMmY5NjA0LTE4MDYtNDZlNS1hMDNkLWRjZ
WY4MDAxOTdmMVwifSIsImlzcyI6ImV4dC52aWRlby10YWcua3IiLCJzdWIiOiJ
WSURFT3RhZyBBUEkgcGFnZS12aWV3IiwianRpIjoiZTYyYzM1NDgtYTgwZS0
0NTA5LWE2YTQtZTg4NDk1OWFkZTE5In0.qEWSfHfJxaqWMjilWaRaO5s0oQ
vf_fDmSbDryDilAzTpeqmSOYNyBri1l1UoF_n7h_bvqE2issKB6Iy68_b7Ng
Header
Payload
Signature

4. Header
● Contents
○ typ - 토큰의 타입을 지정, JWT
○ alg - Hashing algorithm 지정
■ HMAC SHA256/SHA512 혹은 RS256/512 가 사용
■ 토큰을 검증할 때 사용되는 signature 부분에서 사용됨
● URL encoding

5. Payload
● Claim - Key Value Pair
● 이 Claim을 여러 개 넣을 수 있음
● 여러 Claim을 URL Encoding
● Claim의 종류
○ 등록된 (Reserved or Registered)
○ 공개 (Public)
○ 비공개 (Private)

6. Claim
● Registered Claim - 서비스에서 필요한 정보가 아닌 토큰에 대한 정보를 담기
위해 이미 정해짐
● 항목
○ iss: issuer. 토큰 발급자
○ sub: subject. 제목
○ aud: audience. 대상자
○ exp: expiration. 만료시간
■ NumericDate 형식, epoch time (ms 단위 ) (예: 1480849147370)
○ nbf: not before. 이 시각이 지나기 전까지는 토큰이 처리되지 않음
○ iat: issued at. 발급된 시간. Token의 Age 계산
○ jti: JWT의 고유 식별자. 주로 중복적인 처리를 방지하기 위해 사용하고 일회용 토큰에
사용하면 유용함

7. Claim
● Public Claim
○ 충돌이 방지된 (collision-resistant) 이름을 가지고 있어야 함
○ IANA JSON Web Token Registry에 등록되어 있는 이름을 사용함
○ 혹은 URI 형식으로 이름 지음
● Private Claim
○ JWT를 주고 받는 양 측 간에 (Server <-> Client) 협의 하에 사용되는 클레임 이름
○ Public Claim과는 달리 이름이 중복되어 충돌이 될 수 있으니 사용할 때 유의해야 함

8. Signature
● JWT의 Sender를 증명하고 내용이 변경되지 않았는지 확인함
● 헤더의 인코딩 값과 정보의 인코딩 값을 합친 후 주어진 비밀키(Secret)로
Hash를 해서 생성
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)

9. 사용처
● 인증
○ JWT 를 사용하는 가장 흔한 시나리오
○ 사용자가 로그인을 하면 서버는 사용자의 정보에 기반한 토큰을 발급해 전달함
○ 그 후 사용자가 서버에 요청을 할 때마다 JWT를 포함하여 전달하고 해당 토큰이 유효하고
인증됐는지 검증을 하고 사용자가 요청한 작업에 권한이 있는지 확인해 작업을 처리함
○ 세션을 유지할 필요가 없고 세션에 유지하는 정보를 JWT가 가지고 있어서 세션 관리가
필요없음
○ 다만 세션을 관리하지 않으니 중간에 만료시키기 어렵기 때문에 단기간 인증에 많이 사용함
○ Self-contain한 특성이 있기 때문에 민감한 정보를 담지 않도록 함
● 정보 교류
○ 두 개체 사이에서 안정성있게 정보를 교환하기에 좋은 방법
○ 정보가 signing 이 되어있기 때문에 정보를 보낸 이가 바뀌진 않았는지 또 정보가 도중에
조작되지는 않았는지 검증할 수 있음

10. Player API에서의 사용
● 문제
○ 이전 API는 API Key를 이용했기 때문에 보안적 이슈도 있고 값을 잘못 보내거나 변조할
위험성이 있었음
○ 들어오는 사람마다 인증키를 발급하고 이 키가 유효한지 관리하면, 즉 세션을 관리하면
트래픽이 증가할수록 시스템의 부하는 커짐
○ 특히 이 사람 중 일부는 아무것도 하지 않고 나감(재생과 관련한 로깅을 하긴 하지만 이
자체는 우리에게 크게 의미 없음). 즉, 세션의 대부분이 우리 비즈니스에 큰 의미가 없음
○ 대부분의 클립의 재생은 1시간 내에 끝나고 그 이상 머무른다면 크게 의미가 없음 (네이버
등에서는 특정 시간이 흐른 후에 재생해주지 않고 리프레시해야 함)
● 무엇이 필요한가?
○ 보안을 위해 인증은 반드시 필요함
○ 트래픽 증가에 따라 시스템의 부하가 함께 늘어나서 비용이 exponential하게 증가하면 안 됨
그래서 선택한 것이 JWT

11. 참고자료
1. https://jwt.io/
2. https://velopert.com/2389