"JWT"란 무엇이고 왜 사용하는 걸까? (쿠키, 세션과의 차이점)

서버가 클라이언트 인증을 확인하는 방식에는 쿠키, 세션, 토큰을 사용한다.

그렇다면 왜 이러한 인증이 필요한 걸까? 이는 HTTP의 Stateless(무상태성) 때문이다.

 

HTTP의 Stateless한 특성

인터넷의 초기 설계목적과 웹의 특성에 맞게 확장성, 단순성, 성능에 중점을 두고 HTTP를 Stateless하게 만들었습니다.

무상태 프로토콜로 설계된 HTTP는 서버와 클라이언트 간의 모든 요청이 독립적이며, 서버가 이전 요청의 상태를 기억하지 않도록 되어 있습니다.

 

1. 확장성과 성능 향상
   • 서버에 부담이 적음: HTTP가 Stateless이기 때문에 서버는 각 클라이언트의 상태를 유지할 필요가 없다. 즉, 서버는 이전 요청에 대한 정보를 기억하거나 저장할 필요가 없으므로, 클라이언트 수가 증가해도 서버의 부하가 적게 증가한다.
   • 리소스 절약: 서버가 각 요청에 대한 상태 정보를 저장하지 않기 때문에 메모리나 저장소를 절약할 수 있다. 특히, 사용자가 많아지면 상태 정보를 유지하는 비용이 커질 수 있지만, Stateless는 이러한 문제를 피할 수 있다.
2. 단순성
   • 단순한 요청/응답 구조: HTTP의 무상태 특성은 요청과 응답이 단순한 구조를 가지게 한다. 서버는 각 요청을 독립적으로 처리하므로, 요청 자체에 필요한 모든 정보가 포함되어야 한다. 이렇게 단순한 구조는 구현과 유지보수가 쉬워지고, 각 요청이 독립적이라는 점에서 더 효율적인 처리가 가능하다.
   • 데이터 일관성 문제 해결: 상태를 서버에 저장하지 않으므로, 서버 간의 데이터 동기화가 필요하지 않다. 이는 분산 서버 환경에서 서버 간 상태를 공유해야 하는 복잡성을 줄여준다.
3. 확장성
   • 수평적 확장: 무상태이기 때문에 클라이언트의 요청을 처리하는 서버가 달라져도 문제가 없다. 즉, 로드 밸런싱이 매우 쉬워집니다. 클라이언트의 요청을 여러 서버로 분배해도, 각 요청은 독립적이기 때문에 특정 서버가 클라이언트의 상태를 기억하고 있을 필요가 없다. 이는 대규모 시스템에서 매우 중요한 이점다.
   • 캐시 활용: HTTP 요청은 Stateless이므로, 클라이언트의 요청이 항상 동일한 형태로 처리된다. 이로 인해 캐시를 효율적으로 사용할 수 있습니다. 동일한 요청에 대해 캐시된 응답을 재사용할 수 있어 서버 부하를 줄이고, 응답 시간을 단축할 수 있다.
4. 신뢰성과 복구 용이성
   • 요청 실패에 대한 복구: Stateless이기 때문에 만약 클라이언트와 서버 간의 연결이 끊기거나 요청이 실패하더라도, 클라이언트는 동일한 요청을 다시 보내면 된다. 서버는 이전 상태를 기억하지 않고 독립적으로 새 요청을 처리하므로, 오류 복구가 비교적 간단하다.
   • 재시도 가능성: 서버가 상태를 저장하지 않으므로, 클라이언트는 요청이 실패할 경우 쉽게 재시도할 수 있다. 상태가 있는 시스템에서는 실패한 요청을 처리할 때 더 많은 복잡성이 필요할 수 있다.
5. 분산 시스템에 적합
   • 다중 서버 환경에서의 유연성: HTTP의 무상태 특성 덕분에 서버 간에 상태 동기화가 필요하지 않다. 이는 여러 서버가 동일한 요청을 처리할 수 있도록 하여, 서버 간 상태 동기화 문제를 피하게 해주며, 이를 통해 분산 시스템에서 더 효율적으로 동작할 수 있다.
   • 마이크로서비스와의 적합성: 최근의 마이크로서비스 아키텍처에서도 Stateless 프로토콜은 큰 장점이다. 각 서비스는 독립적으로 작동하고, 상태를 공유하지 않기 때문에, 서비스 간 의존성을 줄여준다.
6. 응용 프로그램의 유연성
   • 독립적인 요청 처리: 클라이언트는 특정한 상태에 의존하지 않고 요청을 보낼 수 있다. 상태가 없는 프로토콜 덕분에 클라이언트는 필요한 데이터를 모두 포함한 요청을 보낼 수 있고, 서버는 이 요청에 대한 응답만 하면 된다. 이는 서버와 클라이언트 간의 상호작용을 더 유연하게 만들어준다.

하지만 이러한 장점에도 불구하고, 클라이언트의 상태를 서버가 기억해야 하는 경우가 존재하다.

예시) 로그인 상태, 장바구니 정보 등의 정보를 기억하는 경우

 

이를 해결하기 위해 세션 기반 인증, 토큰 기반 인증 등의 방식이 사용되고 있다.

 

Cookie 인증

쿠키는 Key-Value 형식의 문자열 덩어리이다.

클라이언트가 어떠한 웹사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일이고, 각 사용자마다 브라우저에 정보를 저장하므로 고유 정보 식별이 가능한 것이다.

 

Cookie 인증 방식

1. 클라이언트가 서버에 요청을 보낸다.
2. 서버는 클라이언트의 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담는다.
3. 이후 해당 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다.
   서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별하거나 정보를 바탕으로 추천 광고를 띄우거나 한다.

Cookie 방식의 단점

• 보안에 취약하다. 요청 시 쿠키의 값을 그대로 보내기 때문에, 유출, 탈취 등의 위험이 존재한다.
• 쿠키에는 용량 제한이 있어 많은 정보를 담을 수 없다.
• 웹 브라우저마다 쿠키에 대한 지원 형태가 다르므로 브라우저간 공유가 불가능하다
• 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해진다.

 

Session 인증

쿠키의 보안적인 이슈로 인해, 세션은 비밀번호 등 클라이언트의 민감한 인증 정보를 브라우저가 아닌 서버 측에 저장하고 관리한다.

서버의 메모리에 저장하기도 하고, 서버의 로컬 파일이나 데이터베이스에 저장하기도 한다.

즉, 민감한 정보는 서버에서 모두 관리하게 된다.

 

세션 객체는 어떻게 생겼을까?

세션 객체는 Key에 해당하는 SESSION ID와 이에 대응하는 Value로 구성되어 있다.
Value에는 세션 생성 시간, 마지막 접근 시간, User가 저장한 속성 등이 Map 형태로 저장된다.

 

세션 인증 방식

1. 유저가 웹사이트에서 로그인하면 세션이 서버 메모리 또는 데이터베이스에 저장되며 세션을 식별하기 위한 Session Id를 기준으로 정보를 저장한다.
2. 서버에서 브라우저의 쿠키에 Session Id를 저장한다.
3. 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 Session Id를 쿠키에 담아 전송한다.
4. 서버는 클라이언트가 보낸 Session Id와 서버 메모리로 관리하고 있는 Session Id를 비교하여 인증을 수행한다.

Session 방식의 단점

• 쿠키를 포함한 요청이 외부에 노출되더라도 세션 ID 자체는 유의미한 개인 정보를 담고 있지 않지만 세션 ID 자체를 탈취하여 클라이언트인 척 위장할 수 있다. (서버에서 IP 특정을 통해 해결 가능하다고는 하다)
• 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해진다.

Session 보안 고려 사항

• 세션 ID는 보안 쿠키(HttpOnly, Secure, SameSite)로 설정해 클라이언트 측에서 조작이 불가능하게 해야하며, HTTPS 를 통해 암호화된 채널로만 전송해야 한다.
• 세션에는 만료 시간을 설정하여 일정 시간이 지나면 만료되도록 해야 보안이 강화된다.

보안 쿠키의 주요 속성

1. HttpOnly 속성
정의: 이 속성이 설정된 쿠키는 클라이언트 측 자바스크립트에서 접근할 수 없게 한다.
목적: XSS(크로스 사이트 스크립팅) 공겨에서 클라이언트 측 스크립트가 쿠키에 접근하는 것을 방지한다.
효과: `document.cookie`로 쿠키 값을 읽거나 조작할 수 없으므로, 악의적인 스크립트가 사용자 세션을 탈취하는 것을 막을 수 있게 된다.

2. Secure 속성
정의: Secure 속성이 설정된 쿠키는 HTTPS 연결에서만 전송된다.
목적: HTTP는 암호화되지 않은 평문으로 데이터를 전송하므로, 네트워크를 통해 전송중인 쿠키가 도청될 수 있는데, Secure 속성을 통해 HTTPS로 암호화된 연결에서만 쿠키가 전송되어 중간에서 탈취하는 중간자공격(MITM)을 방지할 수 있다.

3. SameSite 속성
정의: SameSite 속성은 쿠키가 크로스 사이트 요청(CSRF)에서 전송되는 방식을 제한한다. CSRF 공격은 사용자가 인지하지 못한 채 공격자가 설정한 악의적인 사이트에서 서버로 요청이 전송되도록 유도하는 공격이다.
효과: SameSite 속성을 설정하지 않으면 사용자가 방문한 다른 사이트에서 서버로 악의적인 요청을 보내는 CSRF 공격에 노출될 수 있다.

SameSite 종류
1️⃣ Strict: 쿠키는 동일한 도메인 내에서만 전송된다.
2️⃣ Lax: 크로스 사이트 요청에서 GET 요청에만 쿠키가 전송된다. 사용자가 리디렉션을 통해 웹사이트로 돌아갈 때는 쿠키가 전송되지만, 다른 방식의 요청에서는 전송되지 않는다.
3️⃣ None: 아무런 제한 없이 크로스 사이트 요청에서 쿠키가 전송된다. 이 경우 쿠키는 항상 전송되며, CSRF 공격에 취약할 수 있다.

 

 

Token 인증

토큰 기반 인증 시스템은 클라이언트가 서버에 접속하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 토큰을 부여한다. 토큰은 유일하며 토큰을 발급받은 클라이언트는 서버에 요청을 보낼 때, 요청 헤더에 토큰을 같이 보낸다. 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과의 일치 여부를 체크하여 인증과정을 처리하게 된다.

 

기존 세션 기반 인증과의 차이점
서버(세션) 기반 인증은 서버의 세션을 사용하여 사용자 인증을 하는 방법으로 서버에서 사용자의 인증정보를 관리하는 것을 의미합니다. 클라이언트의 상태를 계속해서 유지해야하며(Stateful), 사용자가 증가함에 따라 성능의 문제를 일으킬 수 있으며 확장이 어렵다는 단점이 존재한다. 또한, 서버가 파일이나 DB에 세션정보를 가지고 있어야 한다는 점과 이를 조회하는 과정에서의 오버헤드가 발생한다.

토큰은 세션과 달리 인증정보가 서버가 아닌 클라이언트에 저장되기 때문에 서버의 메모리 부담을 줄일 수 있고, 토큰 자체에 데이터가 들어있으므로 서버는 위조되었는지만 판별하면 된다. 서버 기반 인증과 달리 상태를 유지하지 않으므로 Stateless하다
특히, 토큰 기반 인증은 앱에서 많이 사용되는데, 웹에는 쿠키와 세션이 존재하지만 앱에서는 없기 때문이다.

 

Token 인증 방식

1. 사용자가 아이디, 비밀번호 등으로 로그인을 한다.
2. 서버 측에서 사용자(클라이언트)에게 유일한 토큰을 발급한다.
3. 클라이언트는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장해두고, 서버에 요청을 할 때마다 해당 토큰을 서버 HTTP 요청 헤더에 포함시켜 전달한다.
4. 서버는 전달받은 토큰을 검증하고 요청에 응답한다.
   토큰에는 요청한 사람의 정보가 담겨있기에 서버는 DB를 조회하지 않고 누가 요청하는지 알 수 있다.

Token 인증 방식

• 쿠키/세션과 다르게 토큰 자체의 데이터 길이가 길어 인증 요청이 많아질수록 네트워크 부하가 심해질 수 있다.
• Payload 자체는 암호화되지 않으므로 유저의 중요한 정보를 담을 수 없다
• 토큰을 탈취당하면 대처하기 어렵기 때문에 사용기간을 제한하는 식으로 극복한다.

 

JWT (Json Web Token)이란?

JWT란 인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미한다. 

JWT 기반 인증은 JWT 토큰(Access Token)을 HTTP 헤더에 담아 서버가 클라이언트를 식별하는 방식이다.

 

JWT는 JSON 데이터를 Base 64 URL -safe Encode를 통해 인코딩하여 직렬화한 것이며, 토큰 내부에는 위변조 방지를 위해 개인키를 통한 전자서명도 들어있다. 따라서 사용자가 JWT를 서버로 전송하면 서버는 서명을 검증하는 과정을 거치게 되며 검증이 완료되면 요청한 응답을 돌려준다.

 

Base 64 URL -safe Encode는 일반적인 Base 64 Encode에서 URL에서 안전하게 사용하도록 +, /를 -, _로 표현한 것이다.

Base 64 Encode는 이진 데이터를 텍스트 형식으로 변환하는 인코딩 방식이며, 주로 이메일, 이미지, JSON, 암호화된 값을 인코딩할 때 사용되며, 이진 데이터를 URL, JSON 등의 텍스트 형식에서 안전하게 사용할 수 있게 해준다.

기본 Base64 인코딩

Hello, World! → SGVsbG8sIFdvcmxkIQ==​

Base64 URL-safe 인코딩 예시 코드 (JavaScript)

function base64UrlEncode(input) {
    let base64 = Buffer.from(input).toString('base64');
    return base64
        .replace(/\+/g, '-')  // '+'를 '-'로 대체
        .replace(/\//g, '_')  // '/'를 '_'로 대체
        .replace(/=+$/, '');  // 패딩 '=' 제거
}

const encoded = base64UrlEncode('Hello, World!');
console.log(encoded);  // 출력: SGVsbG8sIFdvcmxkIQ

 

 

JWT 구조

JWT는 .을 구분자로 나누어지는 3가지 문자열의 조합이며, .를 기준으로 Header, Payload, Signature를 의미한다.

 

Header에는 JWT에서 사용할 타입과 해시 알고리즘의 종류가 담겨 있다.

Payload에는 서버에서 첨부한 사용자 권한 정보와 데이터가 담겨 있다.

Signature에는 Header, Payload를 Base64 URL -safe Encode를 한 이후, Header에서 명시된 해시함수를 적용하고, 개인키로 서명한 전자서명이 담겨있습니다.

 

1) Header

 

• alg: 서명 암호화 알고리즘 (HMAC SHA256, RSA)
• type: 토큰 유형

 

 

2) Payload

토큰에서 사용할 정보의 조각들인 Claim이 담겨있으며, 실제 JWT를 통해서 알 수 있는 데이터이다.

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

✏️ Claim - key-value 형식으로 이뤄진 한 쌍의 정보

페이로드는 정해진 데이터 타입은 없지만 대표적으로 Registered claims, Public claims, Private claims 3가지로 나뉜다.

{
  "iss": "https://example.com",
  "sub": "user123",
  "aud": "https://myapi.com",
  "exp": 1610232021,
  "iat": 1610220000,
  "name": "John Doe",  // Public Claim
  "email": "johndoe@example.com",  // Public Claim
  "https://example.com/roles": ["admin", "user"],  // Public Claim (namespace)
  "internal_user_id": "abc123",  // Private Claim
  "department": "sales"  // Private Claim
}

• Registered claims: jwt 표준에서 미리 정의된 클레임으로, jwt의 사용을 위해 권장되거나 일반적으로 사용되는 클레임들
  • iss(issuer, 발행자): 토큰을 발급한 사람(서버), 발급 주체를 나타낸다.
  • exp(expiration time, 만료 시간): 토큰의 만료 시간을 나타내며 Unix 타임스탬프로 기록된다.
  • sub(subject, 대상자): 토큰이 발급된 대상(사용자)를 나타낸다. 일반적으로 사용자 ID로 사용된다.
  • iat(issued at, 발행 시간): 토큰이 발급된 시간을 나타낸다.
  • jti(jwt id): 토큰의 고유 식별자, 주로 토큰을 추적하거나 블랙리스트에서 사용할 때 유용하다.
  • nbf(not before): 토큰이 유효하기 시작하는 시간을 나타낸다. 이 시간 이전에는 토큰이 유효하지 않는다.
• Public claims: 표준화된 클레임이 아니며, 애플리케이션 또는 서비스에 의해 정의된 공개 클레임입니다. 이들은 중복되지 않고, 토큰을 사용하는 시스템에서 자유롭게 정의할 수 있는 클레임입니다
  • 사용자 프로필 정보
  • 네임스페이스 기반 정의: 충돌을 방지하기 위해 네임스페이스를 정의하여 사용하는 경우도 존재함
• Private claims: 특정 클라이언트와 서버 간의 통신에서만 사용되며, 해당 시스템들 간에만 의미 있는 클레임입니다. 이들은 공통적으로 사용되지 않으며, 등록되거나 표준화되지 않은 클레임입니다. 주로 특정 비즈니스 요구 사항을 충족하기 위해 사용됩니다

3) Signature

시그니처에서 사용하는 알고리즘은 헤더에서 정의한 알고리즘 방식(alg)를 활용한다.

시그니처의 구조는 (헤더 + 페이로드)와 서버가 갖고있는 유일한 key 값을 합친 것에서 헤더가 정의한 알고리즘으로 암호화를 한다.

 

Header와 Payload는 단순히 인코딩된 값이기 때문에 제 3자가 복호화 및 조작할 수 있지만, Signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없다. 따라서 Signature는 토큰의 위변조 여부를 확인하는데 사용된다.

 

JWT를 이용한 인증 과정

1. 사용자가 ID, PW를 입력하여 서버에 로그인 인증을 요청한다.
2. 서버에서 클라이언트로부터 인증 요청을 받으면, Header, Payload, Signature를 정의한다.
   Header, Payload, Signature를 각각 Base64로 한 번 더 암호화하여 JWT를 생성하고, 이를 쿠키에 담아 클라이언트에게 발급한다.
3. 클라이언트는 서버로부터 받은 JWT를 로컬 스토리지, 쿠키 등을 통해 저장한다.
   API를 서버에 요청할 때 Authorization header에 Access Token을 담아서 보낸다.
4. 서버는 클라이언트가 Header에 담아 보낸 JWT가 내 서버에서 발급한 토큰인지 일치여부를 확인하여 일치한다면 인증을 통과시켜주고 아닌 경우 통과시키지 않는다.
   인증이 통과되었으므로 페이로드에 들어있는 유저의 정보를 select해서 클라이언트에 돌려준다.
5. 클라이언트가 서버에 요청을 했는데 Access Token의 유효 시간이 만료되면 클라이언트는 Refresh Token을 이용해서 서버로부터 새로운 Access Token을 발급받는다.

토큰 인증이 신뢰성을 갖게 되는 이유

유저1의 JWT가 A(Header) + B(Payload) + C(Signature) 일 때

다른 유저(유저2)가 B를 임의로 수정하여 JWT 토큰을 만들었다고 가정하자. 유저2 JWT는 A + B' + C이다.

수정한 토큰을 서버에 요청을 보내면 서버는 유효성 검사를 시행한다.

유저2의 JWT: A + B' + C

서버에서 검증 후 생성한 JWT: A + B'  + C' => B'의 변경으로 인해 signature의 결과가 달라지게 된다.

대조 결과가 일치하지 않아 유저의 정보가 임의로 조작되었음을 알 수 있다

 

즉, 서버는 토큰 안에 들어있는 정보가 무엇인지 아는 것이 중요한 것이 아니다! 해당 토큰이 유효한 토큰인지 확인하는 것이 중요하므로 클라이언트로부터 받은 JWT 헤더, 페이로드를 서버의 key값을 이용해 시그니처를 만들고 이를 비교하며 일치한 경우에만 인증을 통과시키는 것이다.

 

여기서 JWT는 암호화가 아닌 서명이 목적임을 알 수 있다.
JWT는 Base64로 인코딩을 하므로, 인코딩된 JWT를 1초만에 복호화할 수 있고, 복호화를 하면 사용자의 데이터를 담은 Payload가 그대로 노출된다. (즉, Payload에는 중요한 정보를 넣으면 안된다.)
토큰은 정보 보호가 아닌 위조 방지를 위한 방식이다.

 

JWT 장점

• Header와 Payload를 가지고, Signature를 생성하므로 데이터 위변조를 막을 수 있다.
• 인증 정보에 대한 별도의 저장소가 필요하지 않는다.
• JWT는 토큰에 대한 기본정보와 전달할 정보 및 토큰이 검증되었음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
• 클라이언트 인증 정보를 저장하는 세션과 달리 서버는 무상태(Stateless)가 되어 서버 확장성이 우수해질 수 있다.
• 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다.
• OAuth의 경우, Facebook, Google 등의 소셜 계정을 통해 다른 웹 서비스에서도 로그인을 할 수 있다.
• 모바일 어플리케이션 환경에서도 잘 동작한다. (모바일은 쿠키를 활용한 세션 사용 불가능)
• 세션과 달리 데이터베이스 조회를 통하여 인증, 인가를 하지 않아도 된다

JWT 단점

• Self-Contained: 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있다.
• 토큰 길이: 토큰의 Payload에 세 가지 종류의 클레임을 저장하므로, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다.
• Payload 인코딩: Payload는 암호화된 것이 아닌 Base 64로 인코딩된 것이므로, Payload가 탈취당하여 디코딩된다면 데이터를 볼 수 있게 된다.
• Store Token: stateless 특징을 가지고 있으므로, 토큰은 클라이언트 측에서 관리하고 저장한다. 때문에 토큰 자체를 탈취당하면 대처하기 어렵다

 

 

출처 

https://velopert.com/2350

[JWT] 토큰(Token) 기반 인증에 대한 소개 | VELOPERT.LOG

https://jwt.io/

JWT.IO

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-%EC%8B%9C%ED%81%90%EB%A6%AC%ED%8B%B0

[지금 무료] 스프링부트 시큐리티 & JWT 강의 강의 | 최주호 - 인프런

https://velopert.com/2389

[JWT] JSON Web Token 소개 및 구조 | VELOPERT.LOG

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC#token_%EC%9D%B8%EC%A6%9D

🌐 JWT 토큰 인증 이란? (쿠키 vs 세션 vs 토큰)