JWT

Gon Kim·2022년 10월 14일

이왕 공부한 김에 아까워서 하는 정리[0년차]

목록 보기

3/14

JWT

1) JSON WEB TOKEN

JSON Web Token(JWT)는 정보를 JSON 객체 형태로 전달하기 위한 표준이다.

2) 구조

어떻게 생겼는지부터 보고 가자. 이 후 claim이 무엇인지 조금 더 자세히 확인하고, JWT가 왜 보안성이 좋은지 알아본다. 사실 보안.. 보다는 변조로부터 자유롭다가 더 맞다.

JOSE header

JOSE = JSON Object Signing and Encryption
대게 암호화 관련 정보(해싱 알고리즘), JWT 타입이 명시된다.

JWS payload

대상의 정보가 들어간다. 이를 claim이라고 한다.
claim의 type과 naming rule에 주의해야할 것

JWS signature

JWS = JSON Web Signatures
sender가 JWT에 적혀있는 sender와 일치하는지 확인하기 위해, 그리고 메세지가 변조되지 않았음을 확인하기 위해 쓰인다.
header와 payload를 Base64로 인코딩한 값, 그리고 secret(HMAC 사용할 때 얻는 key. RSA쓰면 아마 비밀 key 사용할 듯. 뒤에 나온다)을 재료로 만든다. 이 때, header에 명시된 알고리즘을 사용한다.
- HMAC SHA256을 사용하는 알고리즘으로 signature를 만드는 예시는 다음과 같다.
```
HMACSHA256(
      base64UrlEncode(header) + "." +
      base64UrlEncode(payload),
      secret)
```

3) 장점

하나 하나 뜯어보기 전에 어떤 친구이고, 어디다 쓰는지 먼저 알아보자. 이런 장점이 있다.

Compact

인코딩 시켜놓은 결과를 봤을 때 SAML 토큰보다 훨씬 작다.

Security

X.509 인증서를 기반으로 한 공개/비밀 키를 사용해 signing 가능
HMAC 알고리즘 기반으로도 signing 가능
SAML 토큰도 공개/비빌 키 사용이 가능하지만, 그 과정이 JSON의 과정보다 훨씬 어렵다고 한다.

Common

JSON parser 쯤은 대부분의 프로그래밍 언어에서 기본적으로 제공한다.

Easier to process

클라이언트에서 처리하기에도 쉽다.

4) 사용처

그래서 이런데 쓴다.

Authentication, Authorization
- SSO에서 많이 사용된다.
sign되기 때문에, 서로 다른 party에서 안전하게 정보를 교환하는데도 사용 가능
- sender가 누구인지 명확히 알 수 있기 때문이다.
- content가 변조되었는지도 확인 가능하다.

결론적으로 세션으로 로그인을 구현할 경우, 세션 아이디로 내려준 쿠키를 받아, 해당 세션 아이디가 서버측에 존재하는지 확인하는 과정이 필요하다. 이 때 세션 아이디와 해당 세션 아이디와 매핑되는 유저 정보들은 대게 DB에서 관리한다. 즉, 해당 유저의 authentication authorization 관련 점검을 할 때마다 DB를 조회해야하는 것. JWT는 그냥 해당 유저가 로그인한 유저인지에 대한 정보를 넣을 수 있으며, 이 정보가 참인지 거짓인지 확인할 수 있으므로, 토큰을 validate한 후 별도의 DB 조회 없이 바로 유저의 상태?를 파악할 수 있다.

5) Claims

payload에 들어가는 key 정도로 생각하자

Claim은 정보를 의미한다. JSON 형식이므로 key-value 형태이다.
- ID token이면 name이 들어있을 수 있겠다.
- value는 JSON value로 들어갈 수 있는 아무 타입이나 가질 수 있을 것
- 보통 claim이라고 하면 key를 일컫는다.

Registered claim

Internet Assigned Numbers Authority (IANA)에 등록되고 JWT specification에 정의된 claim들
iss(issuer), sub(subject), aud(audience), exp(expiration time) 등이 있다. 위 IANA 링크에서 더 확인 가능

Custom claim

register되지 않은, private claims. collision의 위험이 있다.

5) 보안

JWT는 보안성이 좋다. 주의할 것은, 갈취당해도 Token에 담긴 정보를 보지 못하는게 아니라, 볼 수 있지만 변조는 못하는 것이다.

JWT를 받아서 쓰기 전에 검증하는 과정이 필요하다. 검증이 성공적으로 마쳐져야지만, 내용 변조가 없었다는 것을 확신할 수 있다.
하지만 이는 다른 사람들은 JWT 내부 내용을 볼 수 없다는 뜻이 절대 아니다. 변조를 할 수 없다는 것 뿐
따라서 JWT에는 민감한 정보를 넣으면 안되며, HTTPS등을 쓰며 JWT가 intercept되지 않도록 조취를 취해야한다. 안전하고, 계속해서 관리되는 라이브러리들을 쓰는 것도 권장한다.

X.509는 ITU-T가 만든 공개 키 기반(PKI)의 표준. 뭐 그런게 있나보다. 표준이라는 것 정도만 알아뒀다.
SSO(Single Sign-On)은 한번의 로그인으로 다른 사이트에 대한 접근 권한을 모두 얻을 수 있도록 하는 방법을 말한다. 통합 인증인 셈

6) Singing Algorithms

뭘로 만들길래 변조로부터 자유로울까? RS256을 훨씬 추천하더라

RS256(RSA Signature with SHA-256)

Asymmetric algorithm이다. 즉, 공개 키와 비밀 키를 사용한다.
JWT를 찍어내는 쪽에서 비밀 키를 지닌다. 이 쪽에서 비밀 키로 signature를 만들고, consumer는 public key로 해당 JWT를 검증한다.
public key는 JWT를 전송하는 쪽에서 파준 metadata endpoint에서 받는다.