JWT

JWT?

인증에 필요한 정보들을 암호화 시킨 JSON 토큰을 의미 JSON이 기억나지 않는다면

-> JWT 기반 인증은 JWT 토큰을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식

 

JWT는 다른 토큰들과 마찬가지로 로그인 과정에서 주로 쓰임

웹 표준을 따르기 때문에 대부분의 언어가 JWT를 지원함

JWT 구조

JWT는 . 을 구분자로 나누어지는 세 가지 문자열의 조합

Header(헤더) . Payload(내용) . Signature(서명)

Header : Algorithm & Token Type

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

alg 해시 알고리즘 (서명 암호화에 사용)

typ 토큰의 타입

Payload : Data

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

서버와 클라이언트가 주고받는 시스템에서 실제로 사용될 정보에 대한 내용을 담고있는 섹션

Registered claims

사전에 정의되어 있고 강력하게 사용이 권고되는 클레임

• iss 해당 데이터의 발행자
• iat 해당 데이터가 발행된 시간
• exp 해당 데이터가 만료된 시간
• sub 토큰의 제목
• aud 토큰의 대상
• nbf 토큰이 처리되지 않아야 할 시점
• jti 토큰의 고유 식별자

Public claims

사용자가 정의할 수 있는 클레임

공개용 정보 전달을 위해 사용

단, 충돌을 방지하려면 IANA JSON Web Token Registry에 정의돼 있거나 충돌이 방지된 네임스페이스를 포함하는 URI로 정의해야 함

Private claims

등록되거나 공개 클레임이 아닌 정보를 공유하기 위해 만들어진 클레임

통신을 주고받는 당사자들끼리 협의해서 자유롭게 키와 값을 정할 수 있음

 

Payload는 서명된 파트가 아닌 Base64 인코딩된 파트이기 때문에 누구나 디코딩하여 열람 가능

-> 민감한 정보들은 Payload에 담기면 안된다

Signature

Base64로 인코딩 된 Header, Payload와 서버만 가지고 있는 비밀 키를 설정한 알고리즘으로 암호화 한 값이 담김

Header와 Payload는 단순 인코딩 값이기 때문에 제 3자가 복호화 및 조작이 가능하지만,

Signature는 서버 측에서 관리하는 비밀 키가 유출되지 않는 이상 복호화 불가 -> 토큰의 위변조 여부를 확인하는데 사용

JWT를 이용한 인증 과정

1. 사용자가 ID, PW를 입력하여 서버에 로그인 요청

2. 서버에서 클라이언트로부터 인증 요청을 받으면 Header, Payload, Signature를 정의하고 JWT를 생성

3. 해당 정보를 쿠키에 담아 클라이언트에 발급

4. 클라이언트는 서버로부터 받는 JWT를 로컬 스토리지 또는 쿠키,,, 등등의 장소에 저장

5. API를 서버에 요청할 때 Authorization header에 Access Token을 담아서 보냄

6. 서버는 해당 토큰을 확인해서 서버에서 발행한 토큰이라면 인증 통과

 

-> 만약 액세스 토큰의 시간이 만료되었다면?

Refresh Token이 존재한다면 해당 토큰을 이용해서 서버로부터 새로운 엑세스 토큰 발급

왜 JWT?

• JSON이 XML보다 단순, 따라서 XML 기반의 SAML 토큰보다 크기가 작다
• XML은 JSON처럼 바로 객체에 매핑되기 어렵기 때문에 JWT가 더 잘 쓰이기도
• SWT는 대칭키 방식인 HMAC 방식으로 해싱하기 때문에 인증 확인자가 같은 키로 데이터를 만들어 다른 인증 확인자에게 잘못 사용할 수 있는 문제 발생 -> 공개키, 개인키 방식을 쓸 수 있는 JWT가 더,,,

---

Claim key-value 형식으로 이루어진 한 쌍의 정보

IANA JSON Web Token Registry 클레임 이름의 중복을 방지하기 위한 공식 저장소

Access Token 클라이언트가 가지고 있는 실제 유저정보가 담긴 토큰, 비교적 짧은 수명

Refresh Token 새로운 Access Token을 발급해주기 위해 사용하는 토큰