🪙 JWT 개념

JWT란?

• JWT(Json Web Token)은  간결하고도 독립된 방식으로 양 단 사이의 정보를 전송할 수 있도록 정의된 RFC 7519 웹 표준이다.
• 전송된 정보는 디지털 서명을 통해 검증되므로 신뢰할 수 있다.
• 다음 두 가지 방식으로 디지털 서명을 할 수 있다.

✅ RSA 또는 ECDSA 알고리즘을 통해 공개/비공개 키 쌍으로 서명

• 서명된 클레임이 위조 · 변조 되지 않았는지 검증할 수 있다.
• 서명을 생성한 쪽이 해당 비공개 키를 소유하고 있음을 증명할 수 있다.

✅ HMAC 알고리즘을 통해 비밀키로 서명

• 토큰의 무결성을 검증할 수 있다.
• 같은 비밀키를 가진 주체만 유효한 서명을 생성할 수 있다.
• 클레임 내용은 암호화되지 않고 누구나 볼 수 있다.

JWT 도입 근거

• HTTP의 중요한 특징 중 하나는 Stateless를 지향한다는 점이다.
• Stateless란 클라이언트가 보낸 정보를 서버에서 저장하지 않는다는 것이다.
• Stateless을 중요시하는 이유는 서버의 확장성으로 이어진다.
• Session의 경우 Session ID를 Memory든 DB든 어떠한 방식으로 서버에 저장한다.
• 가령 서비스가 흥행해서 트래픽 부하를 관리하기 위해 서버의 수를 늘린다고 하자.
• 이런 경우 여러 개의 서버에서 관리하는 Session ID는 서로 공유되지 않기 때문에 사용자 요청에 대한 인가 기능이 적절하게 처리되지 못한다. 
• 이때 Server Clustering이나 Session 저장소를 외부에 둠으로써 서버 간 Session ID를 공유할 수 있지만 병목 현상 등으로 Session Storage 접근 속도 저하나 중앙 Session Storage에 부하가 집중된다는 문제가 발생한다.
• 또한 Server Clustering은 노드 간 통신 문제로 Session 불일치 현상이 발생할 수 있다고 한다.
• 반면 JWT는 사용자 정보를 서버에 저장하지 않기 때문에 서버가 늘어나도 문제가 없다는 뜻이다.

JWT 구조

• JWT는 .으로 분리된 Header, Payload, Verify-Signature 세 부분으로 나뉜다.
• 여기서 Header, Payload는 Base64Url로 인코딩 된 문자열이다.

✅ Header

• 서명 알고리즘과 토큰의 타입을 포함한다.
• 서명 알고리즘에는 HMAC SHA256 또는 RSA 등이 들어갈 수 있다.
• 토큰의 타입에는 JWT가 문자열 값으로 들어간다.

✅ Payload

• 사용자와 추가 데이터를 나타내는 클레임을 포함한다.
• 클레임은 다음 세 가지 유형으로 나뉜다.
  1. 등록된 클레임
     • 필수는 아니지만 권장되는 클레임이다.
     • 상호 운용성을 위해 사용되며 JWT의 간결성을 위해 클레임 키는 세 글자로 제한된다.
     • iss, exp, sub, aud, nbf, iat, jti 등이 있다.
  2. 공개 클레임
     • 공개되더라도 상관없는 정보로, 충돌 방지를 위해 URI로 정의해야 한다.
  3. 비공개 클레임
     • JWT를 사용하는 당사자 간의 합의에 따라 정의된 커스텀 클레임으로, 등록되거나 공개되지 않은 정보이다.

✅ Verify-Signature

• 서명을 통해 메시지가 전송 중 변경되지 않았다는 사실과 JWT의 발신자가 올바른지 확인할 수 있다.
• 서명을 생성하려면 아래 항목들을 결합하여 서명해야 한다.
  1. 인코딩 된 Header
  2. 인코딩 된 Payload
  3. 비공개 키
  4. Header에 지정된 알고리즘

JWT 작동 원리

• 인증에서 사용자가 로그인하면 JWT가 반환 된다.
• 토큰은 자격 증명이므로 보안 문제를 방지하기 위해 필요한 기간 이상 보관하지 않아야 한다.
• 보안이 부족한 브라우저 저장소에 민감한 Session 데이터를 저장하지 않는 것이 좋다고 한다.
• Local Storage보다는 HTTP-Only Cookie에 Session 데이터를 관리하는 것이 보안성을 높일 수 있다고 한다.
• 사용자가 보호된 경로나 Resource에 접근하려 할 때, 클라이언트는 JWT를 전송해야 한다.
• 일반적으로 다음과 같이 Authorization 헤더에 Bearer Schema를 사용하여 JWT를 보낸다.

Authorization: Bearer <token>

• 서버에서는 Authorization 헤더에서 유효한 JWT를 확인하고, 유효하면 사용자가 보호된 Resource에 접근할 수 있도록 허용한다.

JWT를 통한 일반적인 로그인 과정

1. 사용자가 클라이언트에서 로그인을 한다.
2. 서버에서 Access Token과 Refreshh Token을 반환한다.
3. 클라이언트에서 Resource를 요청할 때마다 Access Token을 포함한다.
4. 서버에서 해당 토큰이 유효한지 확인한다.
5. 만약 유효 기간이 만료되는 등 유효하지 않을 경우 Refresh Token을 확인하여 클라이언트에 Access Token과 Refresh Token을 재발급한다.

회고

• 작년에 JWT 인증을 구현해 본 적은 있는데 당시 Google 검색을 통해 코드를 대부분 가져다 썼던 기억이 있다.
• 그 당시 원리를 제대로 이해하지 못했기 때문에 Refresh Token을 DB에 저장해서 Stateless도 지켜지지 않았다.