참고
JWT(Json Web Token)
NOTE
json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token!
한줄요약 ⇒ 쿠키처럼 한번 발급받으면 저장하고 요청마다 보냄
1.
애플리케이 실행될 떄, JWT를 static 변수와 로컬 스토리지에 저장하게 된다.
•
static에 저장되는 이유 → HTTP 통신마다 JWT와 통신해야하는데 로컬 스토리지에 있다면 오버헤드가 발생하기 때문
2.
JWT를 포함해서 요청을 보낸다면 허가된 JWT인지 검사한다.
3.
로그아웃을 진행하는 경우, 로컬 스토리지에 저장된 JWT 데이터를 제거한다.
JWT 구조
NOTE
Header ,Payload, Signature의 3부분으로 이루어지며, JSON 형태인 각 부분은 Base64로 인코딩되어 표현된다!
왼쪽의 값이 인코딩된 값이다.
Header(헤더)
NOTE
typ, alg 2가지 정보로 구성된다!
{
"alg": "HS256",
"typ": JWT
}
JSON
복사
•
typ
◦
토큰의 타입을 지정한다.
◦
ex) JWT
•
alg
◦
알고리즘 방식을 지정한다
◦
HS256, RSA
Payload
NOTE
토큰에서 사용할 정보의 조각들인 클레임(Claim)이 담겨있다!
•
클레임은 총 3가지로 나누어지며, JSON(Key-Value) 형태로 다수의 정보를 넣을 수 있다.
1. 등록된 클레임
•
토큰 정보를 표현하기 위해 이미 정해진 종류의 데이터들이다.
•
종류
◦
iss(issuer)
▪
토큰 발급자
◦
sub(subject)
▪
토큰 제목
▪
unique한 값을 사용한다.
◦
aud(audience)
▪
토큰 대상자
◦
exp(expiration)
▪
토큰 만료시간
▪
NumericDate 형식
◦
nbf(not before)
▪
토큰 활성 날짜
◦
iat(issued at)
▪
토큰 발급시간
◦
jti(JWT ID)
▪
토큰 식별자
2. 공개 클레임
•
사용자 정의 클레임으로, 공개용 정보를 위해 사용된다.
•
충돌 방지를 위해 URI 포맷을 사용한다.
3. 비공개 클레임
•
사용자 정의 클레임으로, 서버와 클라이언트 사이에 임의로 지정한 정보를 저장한다.
Signature(서명)
NOTE
토큰을 인코딩하거나 유효성 검증을 할 떄 사용하는 고유한 암호화 코드이다!
인코딩 된값을 서명에 등록된 비밀키를 통해 해싱해서 암호화한다.
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
JSON
복사
(인코딩된 Header + 인코딩된 Paylaod + 암호) → Header에 지정된 알고리즘을 가져와서 서명한다.
•
서명은 도중에 메시지가 변경되지 않았는지 확인하는데 사용한다.
JWT 단점 및 고려사항
NOTE
•
Self-contained
◦
토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있다.
•
토큰 길이
◦
토큰의 페이로드에 3종류의 클레임을 저장하기 때문에, 많아질수록 길이가 늘어나 네트워크에 부하를 줄 수 있다.
•
Payload 인코딩
base64로 인코딩하면 그대로 드러난다..
◦
Payload 자체는 암호화 된 것이 아니라, Base64로 인코딩된것이다.
◦
중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로, JWE로 암호화하거나, 중요한 데이터를 넣으면 안된다.
•
Stateless
◦
JWT는 상태를 저장하지 않으므로, 한번 만들어지면 제어가 불가능하다.
◦
즉 토큰을 임의로 삭제하는게 불가능하다!
•
Tore Token
◦
클라이언트 측에서 관리해야 하기 때문에, 토큰을 저장해야 한다.