🪙 JWT

: JSON Web Token의 약자로, 일반적으로 클라이언트와 서버 사이에서 통신할 때 권한을 위해 사용하는 토큰이다. 웹 상에서 정보를 JSON형태로 주고 받기 위해 표준규약에 따라 생성한 암호화된 토큰이며, 복잡한 형태의 읽을 수 없는 String으로 저장되어있다.

JWT는 편리하고 자가수용적인 방식으로 정보를 안전성 있게 전달한다.

자가 수용적 (Self-Contained)?

JWT 는 필요한 모든 정보를 JWT 스스로 가지고 있다. JWT 시스템에서 발급된 토큰은 “토큰에 대한 기본정보”, “전달할 정보” 그리고 “토큰의 유효성을 검증할 정보”를 포함한다.

JWT은 서명(인증)이 목적이다!

아래에서 더 자세히 언급하겠지만, JWT는 Base64url로 암호화를 하기 때문에 디버거를 사용해서 인코딩된 JWT를 1초만에 복호화할 수 있다. 복호화 하면 사용자의 데이터를 담은 부분이 그대로 노출되기에, 비밀번호와 같은 민감한 정보는 넣지 말아야 한다.

음, 그럼 왜 쓰는 걸까? 하는 의문이 생길 수 있는데, 토큰의 진짜 목적은 정보 보호가 아닌, 위조 방지이다. JWT의 비밀키가 노출되지 않는 이상 데이터를 위조해도 서버는 위조했음을 명확히 알고 해당 토큰을 걸러낼 수 있다! (자세한 내용은 아래에서 보자)

---

📜 JWT의 구조

복잡한 String 형태인 JWT는, 인코딩되기 전 상태를 보면 다음과 같이 생겼다.

이를 암호화 및 Base64url로 인코딩하면 다음과 같은 데이터가 만들어진다.
(+) Base64 인코딩의 경우 “+”, “/”, “=”이 포함되지만 JWT는 URI에서 파라미터로 사용할 수 있도록 URL-Safe 한 Base64url 인코딩을 사용한다.

위 문자열에서, 우리는 다음과 같은 JWT의 구조적 특징을 확인할 수 있다.

• JWT의 문자열은 세 문자열의 조합이다.
• 각 파트의 문자열은 온점(.)으로 구분한다.

→ 이제 각 영역에 어떤 정보가 저장되는지 알아보자!

---

1. 헤더(Header)

어떠한 알고리즘으로 암호화 할 것인지, 어떠한 토큰을 사용할 것 인지에 대한 정보가 들어있다. 암호화 전의 데이터는 다음과 같은 형태이다.

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

여기서 alg는 algorithm, typ는 type을 나타낸다. 저장해두었던 토큰을 웹 브라우저가 서버에게 전달하면, 서버는 헤더 부분을 통해 "이 JWT는 HS256 방식으로 암호화되었고, 타입은 JWT이구나!" 하고 알 수 있는 것이다.

(+) 암호화 방식은 HMAC SHA-256 혹은 RSA가 사용된다. 전자는 대칭키 암호화 방식, 후자는 비대칭키 암호화 방식에 해당한다. 이는 Signature 파트에서 설명하겠다.

2. 페이로드(Payload)

Payload를 직역하면 '탑재 화물'이다. 이처럼, 페이로드는 자바 웹 토큰 제이슨 웹 토큰의 중심부로, 실제로 전달하고자 하는 정보를 담고 있는 부분이다. '전달하고자 하는 정보'를 클레임(Claim)이라 칭한다. 정확히는, 페이로드에 담는 정보의 한 '조각'을 클레임이라 부르고, 이는 key-value의 한 쌍으로 이루어져 있다.

클레임의 종류는 크게 세 가지이다.

• 등록된 (Registered) 클레임
  : 서비스에서 필요한 정보들이 아닌, 토큰에 대한 정보들을 담기위하여 이름이 이미 정해진 클레임이다. 등록된 클레임의 사용은 모두 선택적 (optional)이며, 이에 포함된 클레임 이름들은 다음과 같다.
  - iss : 토큰 발급자 (issuer)
  - sub : 토큰 제목 (subject)
  - aud : 토큰 대상자 (audience)
  - exp : 토큰의 만료시간 (expiraton), 시간은 NumericDate 형식으로 되어있어야 하며 (예: 1480849147370) 언제나 현재 시간보다 이후로 설정되어있어야 한다.
  - nbf : Not Before 를 의미하며, 토큰의 활성 날짜와 비슷한 개념입니다. 여기에도 NumericDate 형식으로 날짜를 지정하며, 이 날짜가 지나기 전까지는 토큰이 처리되지 않는다.
  - iat : 토큰이 발급된 시간 (issued at), 이 값을 사용하여 토큰의 age 가 얼마나 되었는지 판단 할 수 있다.
  - jti : JWT의 고유 식별자로서, 주로 중복적인 처리를 방지하기 위하여 사용됩니다. 일회용 토큰에 사용하면 유용하다.

• 공개 (public) 클레임
  : 사용자가 정의할 수 있는, 공개용 정보를 위한 클레임이다. 충돌을 방지하기 위해서, 클레임 이름을 URI 형식으로 짓는다.

• 비공개 (private) 클레임
  : 등록된 클레임도아니고, 공개된 클레임들도 아니다. 양 측간에 (보통 클라이언트 <->서버) 협의하에 사용되는 클레임 이름이다. 공개 클레임과는 달리 이름이 중복되어 충돌이 될 수 있으니 사용할때에 유의해야 한다.

(+) 인코딩/디코딩이 자유로워 페이로드는 수정이 쉽다. 하지만, secret은 서버만 알고 있기에 Header와 Payload를 수정한 후 Signature를 다시 만들 수 없다. 사용자는 서버로부터 발급 받은 JWT를 그대로 소비하기만 하고, 수정없이 다시 서버로 전달한다.

사실 해당 토큰의 권한이나 만료일 등의 정보가 토큰의 중심이다. '직접적인 정보'에 해당하지 않는 Header와 Signature가 존재하는 것도, 이 페이로드 부분이 변조되지 않음을 보장하기 위함이다.

3. 서명(Signature)

토큰의 무결성을 확인할 수 있는 부분이다. Header와 Payload를 합친 후, 여기에 서버가 지정한 비밀 키로 암호화한다. 암호화 방식은 Header에서 선언된 alg에 해당하는 암호화 알고리즘이 적용된다. 앞서 JWT의 암호화 알고리즘에는 SHA-256과 RSA가 사용된다고 했는데, 이를 기반으로 대칭키 암호화 방식, 비대칭키 암호화 방식에 따른 Signature의 생성 과정을 살펴보자.

✅ Signature 생성 : 대칭키 암호화 방식

여기서 암호화는 단순 암호화가 아닌 해싱(Hashing)을 의미한다. 이는 서명 파트의 가장 중요한 '무결성 확인'을 가능하게 한다. 일방향 해시 함수는 다음과 같은 특징을 가진다.

• 암호화된 문자열(해시 값 : Hash-value)로부터 원본 문자열을 얻어낼 수 없다(거의 불가능).
• 원본 문자열이 단 1비트만 변경되더라도 그 해시 값은 완전히 달라진다.

[참고] 해시란?

이러한 특징 덕에 서명은 다음과 같이 생성된다.

1. 헤더(Header)와 페이로드(Payload)를 각각 BASE64url로 인코딩한 후, .으로 구분해 합친다.
2. 인코딩한 값에 Salt를 덧붙여 헤더(Header)에서 정의한 alg : 암호화 알고리즘 : SHA-256으로 해싱한다.
3. 해싱한 값을 다시 BASE64로 인코딩 → 이것이 서명(Signature)이 된다!

이는 다음과 같이 동작한다.

✅ Signature 생성 : 비대칭키 암호화 방식

비대칭키를 활용할 경우, 인가(Authorization)를 제3자가 수행할 수 있다.

즉, secret을 모르는 제3의 서비스는 JWT가 유효한지 그렇지 않은지 판단할 수 없는 HMAC SHA-256 대칭키 알고리즘과 달리, RSA같은 비대칭키 알고리즘은 제3의 서비스도 JWT의 유효성을 체크할 수 있다!

이전 대칭키 / 비대칭키 에서 다루었던 바와 같이, 비대칭키 암호화 방식은 공개 키(Public key)와 개인 키(Private key)를 가진다. 공개 키로 암호화한 문서는 개인 키로만 복호화할 수 있으며, 반대도 마찬가지이다.

비대칭키를 JWT에 적용해 Signature를 생성하는 과정은 다음과 같다.

1. 헤더(Header)와 페이로드(Payload)를 각각 BASE64로 인코딩한 후, .으로 구분해 합친다. (여기까지는 동일하다.)
2. 개인키는 secret, 암호화 알고리즘은 RSA를 적용해 1번의 인코딩 결과를 암호화한다.
3. 암호문을 다시 BASE64로 인코딩 → 이것이 서명(Signature)이 된다!

이는 다음과 같이 동작한다.

(+) 추가 설명 : 제3의 서비스
사용자가 JWT를 서버가 아니라 제3의 서비스에게 전달한다고 해보자. 이 제3의 서비스는 사용자의 ID를 식별해야하고, 이것이 위조되지 않았는지 판단해야한다.

제3의 서비스는 원래 서버로부터 공개키를 받아왔다.

이 공개 키(A)를 사용하면 사용자가 보낸 JWT의 signature를 복호화할 수 있다. 복호화한 결과가, JWT 속 header, payload와 일치 한다면, 이 JWT가 위조 되지 않았음이 증명된다. 이를 통해 인증 서버 없이 인가(Athorization)를 수행할 수 있다.

즉, 제3자에 해당하는 서버는 공개 키(A) 만으로 사용자의 JWT의 위조 여부를 판별한다 :>

---

✏️ JWT의 특징 및 비교 정리

JWT의 장점

• Self-contained : 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요없다!👍
• URL : Base64가 아닌 Base64url 방식으로 인코딩되어 URL 파라미터와 헤더로 사용 가능하다.
• Stateless : 별도의 인증 저장소가 필요하지 않아서 인증서버와 DB에 의존하지 않아도 된다 : 분산/클라우드 기반 인프라 스트럭처에 잘 대응할 수 있다!

JWT의 단점 및 고려사항

• Self-contained : 편리함은 장점이나, 전송 시 탈취당하면 정보가 그대로 노출된다.
• 토큰 길이 : Payload 부분의 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다. 
• Payload 인코딩 : 페이로드(Payload) 자체는 암호화 된 것이 아니라, BASE64로 인코딩 된 것이다. 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로, 중요 데이터를 넣지 않아야 한다. 불가피한 이유로 JWT 토큰에 민감한 사용자 정보를 저장해야한다면 반드시 암호화를 하여 JWT 토큰을 디코딩한 후에도 알아볼 수 없게 해야 한다.
• Stateless : JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능하다. 즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 한다. 
• 토큰 저장 : 토큰은 클라이언트 측에서 관리해야 하기 때문에, 토큰을 저장해야 한다.

---

📝 정리하기!
JWT (JSON Web Token)은 웹 상에서 JSON 형태로 정보를 주고받기 위한 암호화된 토큰이다. 이는 헤더, 페이로드, 서명이 . (점)으로 이어진 문자열이다🤗