Cookie, Session, JWT(Json Web Token) pt.1

HTTP 는 상태를 저장하지 않습니다. ('Stateless' 하다)

 HTTP는 기본적으로 상태 정보를 저장하지 않는 상태가 없는(Stateless) 프로토콜입니다. 이는 각 요청이 서로 독립적이라는 것을 의미하며, 서버가 클라이언트의 상태를 추적하거나 저장하지 않는다는 것을 의미합니다. 이러한 특징은 단순함, 빠른 속도, 더 나은 확장성을 제공하지만, 사용자 인증 같은 상태 정보가 필요한 작업을 처리하기 어렵게 만듭니다.

-> 쿠키와 세션 모두 HTTP 에 상태 정보를 유지(Stateful)하기 위해 사용됩니다. 즉, 쿠키와 세션을 통해, HTTP를 이용한 웹 어플리케이션은 상태 정보를 유지하고, 사용자 인증 및 인가, 사용자 설정 유지 등의 기능을 구현할 수 있게 됩니다.

 

• 쿠키(Cookie): 쿠키는 서버가 사용자의 웹 브라우저에 저장하는 작은 텍스트 파일입니다. 쿠키는 이름, 값, 만료일, 경로, 도메인 등의 정보를 가질 수 있습니다. 쿠키는 사용자가 웹 사이트를 다시 방문할 때마다 해당 정보를 서버에 보내서 사용자를 식별하거나 설정을 유지합니다. 그러나 쿠키는 제한된 용량을 가지고 있으며, 사용자에게 보안적인 위험을 끌어낼 수 있습니다.
• 세션(Session): 세션은 쿠키를 사용하여 클라이언트의 상태 정보를 서버에 저장하는 방법입니다. 서버는 각 클라이언트에 대해 유니크한 세션 ID를 생성하고, 이 ID를 클라이언트의 쿠키에 저장합니다. 클라이언트가 다음 요청을 보낼 때, 서버는 세션 ID를 통해 해당 클라이언트의 세션 데이터에 접근할 수 있습니다. 이 방식은 상태 정보를 서버 측에 저장하므로, 쿠키보다 더 많은 정보를 저장할 수 있고, 보안성도 높습니다. 그러나 모든 세션 정보를 서버에 저장해야 하므로 서버의 부하를 증가시킬 수 있습니다.

• JWT(Json Web Token) :  사용자에 대한 속성을 저장하는 Claim 기반의 Web Token입니다. Json 포맷을 이용하여 정보를 표현합니다. 이 토큰을 통해 로그인 정보를 서버에 저장하지 않고 클라이언트에 로그인 정보를 JWT로 암호화하여 저장할 수 있습니다. 따라서 JWT를 통해 사용자의 인증 및 인가를 할 수 있습니다.
• JWT의 주요 장점은 다음과 같습니다:

1. 동시 접속자가 많을 때 서버 부하를 낮출 수 있습니다.
2. 클라이언트와 서버가 다른 도메인을 사용할 때 효과적입니다. 예를 들어, 카카오 OAuth2 로그인 시 JWT 토큰이 사용됩니다.

• 하지만 JWT의 단점도 있습니다:

1. 구현의 복잡도가 증가합니다.
2. JWT에 담는 내용이 많아질수록 네트워크 비용이 증가합니다.
3. 일단 생성된 JWT를 일부만 만료시킬 방법이 없습니다.
4. Secret key가 유출되면 JWT를 조작할 수 있습니다.

• JWT의 구조는 다음 세 부분으로 이루어집니다:

1. Header: 토큰의 타입과 사용된 알고리즘을 지정합니다.
2. { "alg": "HS256", "typ": "JWT" }
3. Payload: 클레임 정보를 담고 있습니다. 클레임은 사용자에 대한 정보를 의미합니다.
4. { "sub": "1234567890", "username": "카즈하", "admin": true }
5. Signature: Header와 Payload를 합쳐서 Secret Key를 이용해 암호화한 결과입니다.
6. HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

• 모든 서버는 동일한 Secret Key를 소유하며, 이 Secret Key를 통해 암호화와 위조 검증을 진행합니다. 복호화 시에는 Secret Key가 필요하지 않으나, JWT 수정을 위해서는 Secret Key가 필요하므로 JWT는 Read only 데이터가 됩니다.

 

1. 쿠키와 세션의 차이점은 무엇인가요?

쿠키와 세션은 웹에서 상태 정보를 저장하고 관리하기 위해 사용되는 기술입니다. 하지만 두 기술은 저장 위치와 보안, 생명 주기 등에서 몇 가지 차이점을 가지고 있습니다.

1. 저장 위치: 쿠키는 클라이언트의 웹 브라우저에 저장되는 반면, 세션은 서버 측에 저장됩니다.
2. 보안: 세션은 서버에 저장되므로 쿠키에 비해 상대적으로 보안성이 높습니다. 반면 쿠키는 클라이언트에 저장되기 때문에 쿠키 정보가 노출되거나 조작될 위험이 있습니다.
3. 생명 주기: 쿠키는 설정한 만료 시간이 될 때까지 브라우저에 저장되므로 사용자가 브라우저를 종료해도 정보가 유지됩니다. 반면, 세션은 사용자가 브라우저를 종료하면 세션이 종료되며, 서버에서 설정한 세션 타임아웃에 따라 세션이 종료될 수 있습니다.
4. 용량: 쿠키는 총 4KB까지 저장할 수 있으며, 세션은 서버의 메모리를 사용하기 때문에 상대적으로 더 많은 데이터를 저장할 수 있습니다. 하지만 세션의 경우 많은 양의 데이터를 저장하면 서버의 부하가 증가할 수 있습니다.
5. 데이터 타입: 쿠키는 문자열만 저장할 수 있는 반면, 세션은 객체와 같은 복잡한 데이터 타입도 저장할 수 있습니다.

따라서, 쿠키와 세션 중 어떤 것을 사용할지는 상황과 요구 사항에 따라 달라집니다. 일반적으로 민감한 정보를 다루는 경우에는 세션을, 개인화 설정과 같은 사용자 경험을 개선하는 데에는 쿠키를 사용하는 것이 일반적입니다.

 

2. 세션을 사용하면서 발생할 수 있는 보안 문제나 그에 대한 해결책은 무엇인가요?

세션 하이재킹: 이는 공격자가 사용자의 세션 ID를 가로채어 해당 사용자로서의 권한을 획득하는 것을 의미합니다. 세션 ID가 네트워크를 통해 전송될 때 이를 가로챌 수 있으므로, 통신이 암호화되지 않은 경우 특히 위험합니다. 이를 해결하기 위해 HTTPS와 같은 보안 프로토콜을 사용하여 통신을 암호화하는 것이 중요합니다.

세션 고정 공격: 이는 공격자가 특정 세션 ID를 사용자에게 강제로 할당하고, 사용자가 그 세션 ID를 사용하여 인증한 후에는 공격자가 그 세션 ID를 사용하여 사용자의 권한을 획득하는 공격입니다. 이를 방지하기 위해 로그인 시에 새로운 세션 ID를 할당하는 것이 중요합니다.

크로스 사이트 스크립팅(XSS) 공격: 이는 공격자가 사용자의 웹 브라우저에 악성 스크립트를 삽입하여 실행시키는 공격입니다. 이 스크립트는 사용자의 세션 ID를 가로챌 수 있습니다. 이를 방지하기 위해 입력 데이터를 적절히 검증하고 필터링하며, 적절한 HTTP 헤더를 사용하여 브라우저의 스크립트 실행을 제한하는 것이 중요합니다.

세션 타임아웃: 너무 길게 세션을 유지하면, 공격자에게 세션 ID를 탈취당할 시간을 제공하게 됩니다. 반대로 세션을 너무 짧게 설정하면 사용자 경험이 저하될 수 있습니다. 적절한 세션 타임아웃 설정이 중요하며, 민감한 작업을 수행하기 전에 사용자 재인증을 요구하는 것도 좋은 방법입니다.

크로스 사이트 요청 위조(CSRF) 공격: 이는 공격자가 사용자가 로그인한 상태에서 악성 웹페이지를 통해 서버에 요청을 보내게 하여, 사용자가 원하지 않는 행동을 서버에 요청하게 하는 공격입니다. 이를 방지하기 위해서는 CSRF 토큰을 사용하여 요청의 유효성을 검증하거나, 동일 출처 정책(Same-origin policy)를 준수하여 서로 다른 출처의 요청을 제한하는 것이 중요합니다.

브루트 포스 공격: 공격자가 무작위의 세션 ID를 반복적으로 시도하여 유효한 세션 ID를 찾아내는 공격입니다. 이를 방지하기 위해 세션 ID는 충분히 길고 복잡하게 생성하며, 무작위의 시도에 대한 제한을 두는 것이 중요합니다.

 

3. 쿠키는 어떤 정보를 저장해야하고 어떤 정보를 저장해서는 안되나요?

쿠키는 사용자가 웹 사이트를 방문할 때 사용자의 기기에 저장되는 작은 텍스트 파일입니다. 쿠키는 일반적으로 사용자가 웹 사이트에 재방문했을 때 그 사이트가 사용자를 인식하도록 돕습니다.

쿠키에 저장해야하는 정보:

1. 세션 정보: 쿠키는 사용자 세션을 추적하기 위해 자주 사용됩니다. 사용자가 로그인했을 때 쿠키에 세션 ID를 저장할 수 있으며, 이는 사용자가 사이트를 이동하면서 로그인 상태를 유지하게 합니다.
2. 사용자 설정: 사이트에 대한 개인화된 사용자 설정을 저장하는데 쿠키를 사용할 수 있습니다. 예를 들어, 사용자가 선택한 언어 설정이나 테마 등을 저장할 수 있습니다.
3. 사용자 행동과 선호도 추적: 쿠키는 사용자의 행동과 선호도를 추적하고 기록하는데 사용됩니다. 이는 개인화된 사용자 경험을 제공하거나 타겟팅 광고를 제공하는데 도움이 됩니다.

쿠키에 저장해서는 안되는 정보:

1. 개인 식별 정보: 사용자의 신용카드 번호, 주민등록번호, 운전면허번호와 같은 민감한 개인 식별 정보는 절대 쿠키에 저장해서는 안됩니다. 쿠키는 클라이언트 측에서 쉽게 조작될 수 있으며, 이러한 정보가 유출되면 심각한 보안 문제가 발생할 수 있습니다.
2. 비밀번호: 비밀번호 또한 쿠키에 저장해서는 안됩니다. 심지어 비밀번호를 해시처리한 후에도 저장해서는 안됩니다. 만약 쿠키가 탈취되면, 공격자가 사용자의 계정에 접근할 수 있게 됩니다.
3. 대량의 정보: 쿠키는 텍스트 기반이며, 그 크기는 한정적입니다. 대량의 데이터를 쿠키에 저장하려고 하면 문제가 발생할 수 있습니다. 대량의 데이터는 보통 서버 측에서 관리하며 필요한 경우에만 클라이언트로 전송합니다.

4. 쿠키와 세션 이외에 클라이언트의 상태를 유지하는 다른 방법을 아는가요?

 

1. Hidden Fields: 웹 페이지 내부의 숨겨진 필드를 사용하여 정보를 클라이언트에 저장할 수 있습니다. 이 정보는 서버로 다시 전송될 때 함께 전송됩니다. 이 방법은 주로 HTML 폼에서 사용되며, 사용자가 입력한 데이터를 유지하는 데 사용됩니다.
2. LocalStorage, SessionStorage (Web Storage): HTML5의 Web Storage API를 사용하면 브라우저 내에 데이터를 저장할 수 있습니다. LocalStorage는 클라이언트가 웹사이트를 닫거나 재시작해도 데이터가 유지되는 반면, SessionStorage는 현재 세션 동안만 데이터를 유지합니다.
3. IndexedDB: IndexedDB는 브라우저 내에 큰 데이터를 저장하기 위한 NoSQL 데이터베이스입니다. 웹 애플리케이션에서 클라이언트 측에서 작동하는 큰 데이터베이스가 필요할 때 사용됩니다.
4. WebSockets, Server-Sent Events (SSE): 이 두 기술은 클라이언트와 서버 사이에 실시간 양방향 통신을 가능하게 합니다. 이를 통해 서버는 필요에 따라 클라이언트에 메시지를 푸시할 수 있습니다.
5. HTTP/2 Server Push: HTTP/2 프로토콜에서, 서버는 클라이언트가 명시적으로 요청하지 않아도 미리 정의된 리소스를 클라이언트에게 푸시할 수 있습니다. 이를 통해 서버는 클라이언트의 다음 요청을 예측하고 미리 리소스를 전달하여 효율성을 높일 수 있습니다.

JWT (JSON Web Tokens)는 클라이언트의 상태를 유지하는 방법 중 하나입니다. JWT는 웹 서버가 클라이언트에게 JSON 객체를 반환하는데, 이 JSON 객체는 토큰으로 암호화됩니다.

클라이언트는 이 토큰을 다음 요청에 포함시켜 인증 정보를 전달하고, 서버는 이 토큰을 복호화하여 사용자 인증 및 데이터를 처리합니다. 이 토큰은 일반적으로 HTTP 헤더의 Authorization 필드에 포함됩니다.

JWT의 주요 장점은 상태를 저장하지 않는다는 점입니다. 이는 서버가 사용자 상태를 추적하거나 저장할 필요가 없다는 것을 의미하며, 이로 인해 서버 부하를 줄이고 확장성을 높일 수 있습니다. JWT는 또한 크로스 도메인 인증을 지원하므로, 여러 도메인이나 서비스에서 사용자를 인증하는 데 유용합니다.

JWT (JSON Web Tokens)는 상태를 저장하지 않는(stateless) 방식입니다.

"상태를 저장하지 않는다"는 것은 서버가 클라이언트의 정보를 유지하지 않는다는 의미입니다. 클라이언트가 요청을 보낼 때마다 해당 요청에 필요한 모든 정보가 포함되어야 하며, 서버는 이 정보를 바탕으로 요청을 처리하고 응답을 보냅니다. 다시 말해, 서버는 클라이언트의 이전 요청을 기억하지 않으며, 각 요청을 별도로 처리합니다.

JWT는 이러한 상태를 저장하지 않는 방식을 따릅니다. 클라이언트는 요청을 보낼 때마다 JWT를 포함시켜 서버에 인증 정보를 제공합니다. 이 토큰에는 사용자를 식별하는 데 필요한 모든 정보가 들어있으므로, 서버는 이 토큰을 디코딩하여 요청을 처리합니다. 따라서 서버는 세션 상태를 유지하거나 사용자 정보를 저장할 필요가 없습니다.

이는 서버의 부하를 줄이고 확장성을 높이는 데 도움이 되며, 웹 애플리케이션을 구축하는 데 사용되는 RESTful 아키텍처의 핵심 원칙 중 하나입니다.

하지만, JWT도 몇 가지 단점이 있습니다. 예를 들어, 토큰이 탈취되면 사용자의 데이터와 권한이 위협받을 수 있습니다. 이를 방지하기 위해 HTTPS와 같은 안전한 프로토콜을 사용하거나 토큰의 유효기간을 짧게 설정하는 등의 방법이 있습니다. 또한 JWT는 일반적으로 크기가 크므로, 이를 자주 전송하는 것은 네트워크 부하를 증가시킬 수 있습니다.

 

5. 쿠키와 세션을 사용할 때 성능에 미치는 영향은 어떻게 되나요?

쿠키(Cookie):

• 쿠키는 클라이언트의 브라우저에 저장되는 작은 텍스트 파일입니다. 웹 사이트에서는 이를 사용하여 사용자의 정보나 상태를 저장하고, 이전 사용자의 활동을 추적할 수 있습니다.
• 쿠키는 각 HTTP 요청과 함께 서버로 전송되므로, 큰 크기의 쿠키는 네트워크 대역폭을 사용하고, 이로 인해 애플리케이션의 응답 시간이 느려질 수 있습니다.
• 또한, 쿠키에 저장할 수 있는 데이터는 제한적이며, 사용자가 쿠키를 삭제하거나 브라우저 설정에서 쿠키를 차단할 수 있으므로, 중요한 정보는 쿠키에 저장해서는 안 됩니다.

세션(Session):

• 세션은 서버 측에서 클라이언트의 상태 정보를 유지합니다. 세션 ID는 클라이언트에게 전달되고, 이 ID를 사용하여 각 클라이언트의 세션 데이터에 접근할 수 있습니다.
• 세션 데이터는 서버 메모리에 저장되므로, 많은 사용자가 접속하거나, 세션 데이터가 많을 경우 서버 메모리 부하가 증가할 수 있습니다. 이를 해결하기 위해선 세션 저장소로 데이터베이스나 캐시 서버(예: Redis)를 사용하는 등의 방법이 필요합니다.
• 세션은 사용자가 로그아웃하거나 일정 시간 동안 활동이 없는 경우 만료되므로, 쿠키보다 보안에 더 안전할 수 있습니다.

6. 세션, 쿠키의 생명주기(Lifecycle)는 어떻게 되나요?

세션의 생명주기는 주로 다음과 같은 단계로 이루어집니다:

1. 세션 생성: 사용자가 웹 애플리케이션에 처음으로 접속하면, 서버는 세션을 생성합니다. 이때 서버는 고유한 세션 ID를 생성하고, 이를 클라이언트에게 전달합니다. 일반적으로 이 세션 ID는 HTTP 응답의 쿠키를 통해 전달됩니다.
2. 세션 활성화: 사용자가 애플리케이션을 사용하는 동안, 서버는 이 세션 ID를 사용하여 각 클라이언트의 세션 데이터를 관리합니다. 클라이언트가 요청을 보낼 때마다, 해당 요청에 포함된 세션 ID를 사용하여 사용자의 세션 데이터에 접근할 수 있습니다.
3. 세션 업데이트: 사용자의 액션에 따라 세션 데이터를 업데이트할 수 있습니다. 예를 들어, 사용자가 상품을 장바구니에 추가하는 경우, 이 정보는 사용자의 세션 데이터에 추가될 수 있습니다.
4. 세션 만료: 세션은 일정 시간 동안 사용자의 활동이 없을 경우 만료됩니다. 만료된 세션은 더 이상 유효하지 않으며, 이후 동일한 세션 ID로 들어오는 요청은 새로운 세션을 생성하게 됩니다. 또한, 사용자가 로그아웃하는 경우에도 세션을 명시적으로 만료시킬 수 있습니다.
5. 세션 삭제: 세션 데이터는 세션이 만료되면 서버에서 삭제됩니다. 이는 서버의 메모리를 효율적으로 관리하기 위함입니다. 일부 시스템에서는 별도의 배경 프로세스가 주기적으로 만료된 세션을 청소합니다.

쿠키의 생명주기는 다음과 같은 단계로 구성됩니다:

1. 쿠키 생성: 웹 서버는 HTTP 응답 헤더에 'Set-Cookie'를 포함시켜 클라이언트에게 쿠키를 생성하도록 지시합니다. 이 'Set-Cookie' 헤더에는 쿠키 이름, 값, 만료 날짜, 경로 등 쿠키의 속성이 포함됩니다.
2. 쿠키 저장: 웹 브라우저는 응답 헤더에서 받은 정보를 바탕으로 쿠키를 생성하고 저장합니다. 쿠키는 일반적으로 클라이언트의 하드 디스크에 저장되며, 이 정보는 다음에 서버에 요청을 보낼 때마다 함께 전송됩니다.
3. 쿠키 전송: 클라이언트가 서버에 다시 요청을 보낼 때, 웹 브라우저는 쿠키 정보를 HTTP 요청 헤더에 포함시켜 서버에 전송합니다. 서버는 이 쿠키 정보를 사용하여 클라이언트를 식별하거나 세션을 유지하는 등의 작업을 수행합니다.
4. 쿠키 만료: 쿠키에는 'Expires' 또는 'Max-Age' 속성이 있어, 이를 통해 쿠키의 생명주기를 지정할 수 있습니다. 만료 날짜를 지나거나 브라우저가 종료되면, 웹 브라우저는 쿠키를 삭제합니다.
5. 쿠키 삭제: 만료된 쿠키나 명시적으로 삭제 요청된 쿠키는 브라우저에서 삭제됩니다.

7.  HTTP가 Stateless한 프로토콜이라는 것의 의미는 무엇인가요? 그리고 이것이 웹 개발에 어떤 영향을 미치나요?

HTTP 프로토콜이 Stateless라는 것은 HTTP 요청 간에 서버가 클라이언트의 상태를 유지하지 않는다는 것을 의미합니다. 즉, 서버는 각 요청을 독립적으로 처리하며 이전 요청에 대한 정보를 기억하지 않습니다. 한 요청에서 다음 요청으로 상태를 전달하려면 명시적으로 데이터를 전달해야 합니다. 이러한 설계는 HTTP 프로토콜을 간단하게 만들고 서버의 부하를 줄이는 데 도움이 됩니다.

하지만 이러한 Stateless 설계는 웹 개발에 일부 제약을 가합니다. 예를 들어, 웹 사이트에서 사용자를 인증하고 사용자 세션을 유지하는 것은 HTTP가 Stateless하기 때문에 복잡해집니다. 이를 해결하기 위해 쿠키와 세션, JWT 같은 기술들이 사용됩니다.

쿠키는 클라이언트 측에 데이터를 저장하여 서버가 클라이언트를 인식하게 하고, 세션은 서버 측에 클라이언트의 상태를 저장하여 클라이언트 간에 상태를 유지하게 합니다. JWT는 클라이언트의 상태를 토큰에 저장하고 이를 서버에 보내어 상태를 유지하는 방식입니다.

이처럼 HTTP가 Stateless한 프로토콜이라는 것은 웹 개발에서 상태 관리를 위한 추가적인 메커니즘이 필요하다는 것을 의미합니다. 

 

8. 세션 하이재킹(Session Hijacking)이란 무엇인가요? 이를 방지하기 위한 방법은 무엇인가요?

세션 하이재킹, 또는 세션 탈취는 공격자가 사용자의 세션을 가로채서 그 사용자로서의 권한을 획득하는 공격을 말합니다. 이렇게 하면 공격자는 사용자의 세션을 통해 해당 사용자의 계정에 액세스하고, 해당 사용자의 데이터를 탈취하거나 서비스를 악용할 수 있게 됩니다.

세션 하이재킹을 방지하는 몇 가지 방법은 다음과 같습니다:

1. 세션 ID의 안전한 관리: 사용자의 세션 ID를 쿠키로 관리할 때는 반드시 HttpOnly 플래그를 사용하여 자바스크립트를 통한 접근을 막아야 합니다. 이는 크로스 사이트 스크립팅(XSS) 공격을 통해 세션 ID를 탈취하는 것을 방지하는 데 도움이 됩니다.
2. HTTPS 사용: HTTPS를 사용하면 세션 ID가 평문으로 네트워크를 통해 전송되는 것을 방지하여 네트워크를 통한 세션 ID의 탈취를 방지합니다.
3. 세션 타임아웃 설정: 미사용 세션은 일정 시간 후에 만료되도록 설정하여 공격자가 탈취한 세션 ID의 사용을 제한합니다.
4. 세션 재발급: 중요한 행동(예: 로그인, 개인 정보 변경 등)을 수행하기 전에 세션 ID를 재발급하여 공격자가 이전의 세션 ID를 사용하는 것을 방지합니다.
5. CSRF 토큰 사용: 요청마다 새로운 CSRF 토큰을 발급하고 이를 검증하여 CSRF 공격을 방지합니다. CSRF 공격은 공격자가 사용자의 세션을 이용하여 의도치 않은 요청을 보내는 공격입니다.

이러한 방법들은 서버와 클라이언트 모두에서 적용되어야 효과적으로 세션 하이재킹을 방지할 수 있습니다.

 

---

 

9. JWT(Json Web Token)에 대해 설명해주실 수 있나요?

JSON Web Token(JWT)는 간단히 말해 웹 사이트와 서버간에 안전하게 정보를 주고받기 위한 방법 중 하나입니다

JWT는 특정 사용자가 서비스에 접근할 권한이 있는지를 증명하는데 사용되며, 일반적으로 서버와 클라이언트 사이의 요청에 포함되어 전송됩니다.

JWT는 크게 세 부분으로 나뉩니다: Header, Payload, Signature.

1. Header: 토큰의 유형 (표준적으로 "JWT")과 사용된 알고리즘 (예: HS256 또는 RS256)을 선언하는 JSON 객체입니다.
2. Payload: 클레임(웹 사이트나 서버가 알아야 할 정보, 예를 들어, 사용자 ID)을 포함하는 JSON 객체입니다. 클레임은 추가적인 메타데이터를 가진 속성이며, 사용자에 대한 정보와 토큰의 유효성을 결정하는데 사용됩니다.
3. Signature: 토큰의 무결성을 보증하기 위해 사용됩니다.(토큰이 변경되지 않았음을 확인하는 데 사용되는 일종의 디지털 서명) 이것은 header와 payload를 합친 다음, 비밀 키를 사용하여 이것을 암호화한 결과입니다.

토큰이 생성되면, 각 부분 (header, payload, signature)는 Base64로 인코딩되고 "."로 구분되어 하나의 문자열로 결합됩니다.

JWT는 주로 두 가지 방식으로 사용됩니다. 하나는 사용자 인증에 사용하고, 다른 하나는 안전하게 정보를 주고받는 데 사용합니다.

1. Authentication: 클라이언트가 서버에 요청할 때마다 JWT를 함께 보내서 사용자가 누구인지 인증합니다. 서버는 토큰을 검증하여 요청이 유효한지 확인합니다.
2. Information Exchange: 두 시스템 간에 안전하게 정보를 전달하기 위해 사용될 수 있습니다. 정보는 토큰에 포함되고, 토큰의 서명을 통해 무결성이 보장됩니다.

JWT의 주요 장점 중 하나는 상태를 유지하지 않는다는 것입니다. 이는 서버가 사용자의 상태를 기억할 필요가 없으며, 이로 인해 서버의 부하를 줄일 수 있습니다. 이는 특히 대규모 서비스에서 매우 유용하며, 확장성을 향상시킵니다.

그러나 JWT는 무한정 사용할 수 있는 것은 아닙니다. 예를 들어, 한 번 발급된 JWT는 취소가 불가능하기 때문에, 만료 시간을 짧게 설정하는 것이 일반적입니다. 또한 중요한 개인 정보가 포함된 경우, 토큰이 탈취될 위험이 있으므로 이를 방지하기 위한 추가적인 보안 조치가 필요합니다.

 

10. JWT는 어떤 경우에 사용하면 좋을까요? 그 이유는 무엇인가요?

1. 분산 시스템: JWT는 클라이언트와 서버 간에 정보를 안전하게 주고받을 수 있게 해줍니다. 이는 로드 밸런서가 여러 서버 간의 요청을 분산시키는 분산 시스템에서 특히 유용합니다. 세션 기반의 인증 시스템에서는 세션 정보를 모든 서버가 공유해야 하지만, JWT를 사용하면 클라이언트가 요청을 보낼 때마다 토큰을 함께 보내므로 이러한 공유가 필요 없습니다.
2. 마이크로서비스 아키텍처: 마이크로서비스 아키텍처에서 각 서비스는 자체적으로 Stateless 해야 합니다. JWT를 사용하면 각 서비스가 독립적으로 인증을 수행할 수 있습니다.
3. 모바일 애플리케이션: 모바일 환경에서는 서버 기반 세션은 상대적으로 많은 리소스를 사용하게 됩니다. 반면에 JWT는 상태를 저장하지 않는 Stateless 통신이 가능하므로 리소스를 절약할 수 있습니다.
4. 크로스 도메인 인증: 쿠키는 동일 출처 정책(Same Origin Policy)에 따라 도메인 간에 공유될 수 없습니다. 반면에 JWT는 HTTP 헤더에 포함되어 전송되므로 다른 도메인 간에도 안전하게 정보를 주고받을 수 있습니다.
5. 서드파티 인증: JWT는 OAuth, OpenID Connect 등의 서드파티 인증 프로토콜에서 사용되며, 이들 프로토콜을 사용하여 외부 서비스에 대한 인증을 제공할 수 있습니다.

 

2023.05.29 - [Web] - Cookie, Session, JWT(Json Web Token) pt.2