[F-Lab 페이백 모각코 60일차] 토큰 기반 인증: JWT

JWT (JSON Web Token)란?

JWT는 JSON Web Token의 약자로, 두 개체 사이에서 정보를 안전하게 전송하기 위한 컴팩트하고 독립적인 방법을 제공하는 표준입니다 (RFC 7519). 주로 인증 및 정보 교환에 사용됩니다.

JWT의 구성

JWT는 세 부분으로 구성됩니다:

1. Header (헤더): 토큰의 유형 (JWT) 및 사용된 해싱 알고리즘 (예: HMAC SHA256 또는 RSA)을 포함하는 메타데이터를 담고 있습니다.
2. Payload (페이로드): 실제 토큰의 내용을 포함합니다. 이 부분에는 클레임(claim)이라는 정보 단위가 포함되며, 사용자의 정보나 권한과 같은 것들을 나타냅니다.
3. Signature (서명): 서명은 헤더와 페이로드를 암호화하는데 사용됩니다. 이 서명을 통해 토큰이 중간에 변경되지 않았음을 확인할 수 있습니다.

JWT의 사용 방법

주로 사용자 인증에 사용되며, 사용자가 시스템에 로그인 할 때 서버는 사용자의 정보와 일부 비밀(secret)을 사용하여 JWT를 생성합니다. 생성된 토큰은 사용자에게 반환되며, 사용자는 이후 요청에서 이 토큰을 함께 전송합니다. 서버는 토큰을 검증하여 사용자의 신원을 확인합니다.

장점:

1. 스케일링: JWT는 stateless 합니다. 즉, 서버는 사용자의 상태를 저장할 필요가 없습니다. 각 토큰은 모든 필요한 정보를 자체적으로 포함하기 때문입니다.
2. 확장성: JWT는 다른 시스템 사이의 정보 교환에 유용합니다. 각 시스템은 JWT의 서명을 통해 메시지의 유효성을 검증할 수 있습니다.
3. 모바일 최적화: JWT는 소형화되어 있으므로 모바일 환경에서 효과적으로 작동합니다.

단점:

1. 데이터의 만료: 한번 발행된 JWT는 수정이 불가능합니다. 따라서, 만료 시간(TTL)이 긴 토큰은 보안 문제를 일으킬 수 있습니다.
2. 데이터 노출: 페이로드는 인코딩되어 전송되지만 암호화되지 않습니다. 중요한 정보는 JWT 안에 직접 포함시키지 않는 것이 좋습니다.

JWT의 데이터 구성

JWT는 세 부분으로 나뉘어져 있습니다:

1. 헤더 (Header)
2. 페이로드 (Payload)
3. 서명 (Signature)

각 부분에 대해 좀 더 세부적으로 알아보겠습니다:

1. 헤더 (Header)

헤더는 일반적으로 두 가지 정보를 담고 있습니다: 토큰의 유형 (token type)과 해싱 알고리즘 (hashing algorithm). 헤더는 다음과 같이 구성됩니다:

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

2. 페이로드 (Payload)

페이로드는 여러 클레임 (claims)을 포함하는 JSON 객체입니다. 클레임은 세 가지 유형으로 분류됩니다:

1. 등록된 클레임 (Registered Claims): 토큰의 발행자 (iss), 주제 (sub), 수령자 (aud), 만료 시간 (exp), 발행 시간 (iat) 등이 여기에 포함됩니다.
2. 공개 클레임 (Public Claims): JWT 사용자 사이에 공유되어야 하는 추가 정보를 나타냅니다. 이러한 클레임들은 충돌을 방지하기 위해 이름이 길고 복잡해야 합니다.
3. 비공개 클레임 (Private Claims): 서버와 클라이언트 사이에 합의된 클레임으로, 사용자 정의 데이터를 저장합니다.

예시:

jsonCopy code
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true}

3. 서명 (Signature)

서명은 헤더와 페이로드의 값과, ‘시크릿’ 키를 사용하여 생성됩니다. 서명은 다음과 같은 방식으로 생성됩니다:

scssCopy code
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

JWT의 규칙

1. 안전한 전송: JWT는 민감한 정보를 포함할 수 있으므로, 항상 HTTPS를 통해 안전하게 전송되어야 합니다.
2. 짧은 만료 시간: JWT는 만료 시간이 짧아야 합니다, 그렇게 함으로써 잠재적인 보안 위험을 최소화할 수 있습니다.
3. 적절한 암호화: 중요한 데이터는 JWT 페이로드에 직접 저장되지 않아야 합니다. 필요하다면 JWE(JSON Web Encryption)를 고려하여 페이로드를 암호화해야 합니다.

이러한 규칙들은 JWT를 사용할 때 안전하고 효율적인 방식으로 정보를 교환하기 위해 따라야 할 중요한 지침들입니다.

페이로드

• "페이로드(payload)"란 어떤 전송 수단을 통해 전달되는 주요 데이터나 본문을 의미합니다. 웹 컨텍스트에서 볼 때, HTTP 요청의 'body' 부분이 페이로드에 해당합니다.
• JWT에서의 "페이로드"는 토큰의 중심 부분으로, 실제로 전달하고자 하는 정보(데이터)가 포함되어 있습니다. 이 정보는 사용자의 아이디, 권한, 만료 시간 등 다양한 클레임(claim)들로 구성될 수 있습니다.
• 간단히 말해, 페이로드는 전송하려는 주요 정보나 데이터 자체를 나타내는 용어입니다.

Q: 음 내생각에 JWT의 구성과 특징으로는 첫 헤더에는 어떤 방식을 사용해서 인코딩 할지 알려주고 페이로드에 전달할 것들을 키값 형식으로 저장, 그리고 마지막엔 앞서 말한 헤더에서의 값과 페이로드 의 값과 어떤 암호키로 암호화해서 중간에 변조되지 않았다는 것을 증명하는 것 까지 포함한 것이 JWT지?

1. 헤더 (Header): 여기에는 주로 두 가지 정보가 포함됩니다. 하나는 토큰의 유형 (JWT 자체를 나타내는 "typ")이고, 다른 하나는 사용되는 해싱 알고리즘 (예: "HS256" 또는 "RS256")입니다. 이 알고리즘은 서명 생성 시 사용됩니다.
2. 페이로드 (Payload): 이 부분에는 여러 클레임(claim)이 포함됩니다. 클레임은 전달하려는 주요 정보(데이터)를 나타내며, 이름-값 쌍으로 구성됩니다. 예를 들면, 사용자 아이디, 사용자 권한, 토큰의 만료 시간 등의 정보가 여기에 들어갑니다.
3. 서명 (Signature): 이 부분은 헤더와 페이로드, 그리고 "시크릿(secret) 키"를 사용하여 생성됩니다. 이 서명은 JWT가 변조되지 않았음을 검증하는 데 사용됩니다.

따라서 JWT는 이러한 세 부분으로 구성되어 있으며, 각 부분은 점(.)으로 구분됩니다. 서명은 JWT의 무결성을 보장하며, 이를 통해 토큰이 중간에 변경되지 않았음을 확인할 수 있습니다.

페이로드의 용도

1. HTTP 요청 및 응답:
   • 용도: 클라이언트와 서버 간에 전달되는 실제 데이터를 포함하는 부분.
   • 예: POST 요청을 통해 폼 데이터를 서버로 전송할 때, 폼의 입력 내용이 페이로드에 해당합니다.
2. JWT (JSON Web Token):
   • 용도: 사용자 정보, 권한, 토큰 만료 시간 등과 같은 클레임 정보를 담는 부분.
   • 예: 사용자 아이디와 권한 정보를 JWT 페이로드에 넣어 암호화하고 서명하여 전송합니다.
3. 네트워크 패킷:
   • 용도: 패킷의 헤더 정보를 제외한 실제 데이터를 포함하는 부분.
   • 예: ICMP 패킷에서 "echo request" 또는 "echo reply" 메시지는 페이로드로 간주됩니다.
4. 웹소켓 메시지:
   • 용도: 웹소켓 프레임의 본문에 담긴 실제 데이터.
   • 예: 실시간 채팅 애플리케이션에서 전송된 메시지 내용은 웹소켓 메시지의 페이로드에 해당합니다.
5. 파일 전송:
   • 용도: 전송될 파일의 실제 내용.
   • 예: FTP를 통해 전송되는 파일의 내용은 페이로드로 간주됩니다.
6. 암호화 및 보안:
   • 용도: 암호화나 디지털 서명의 대상이 되는 실제 데이터.
   • 예: 디지털 서명 프로세스에서 원본 메시지는 페이로드로 취급되며, 이를 암호화하거나 서명합니다.

이러한 예외적인 경우들을 통해 "페이로드"는 각 기술적 문맥에서 중심이 되는 데이터나 본문을 의미한다는 것을 알 수 있습니다.

JWT와 FTP는 서로 직접적인 연관이 없습니다. 제가 이전의 설명에서 두 기술을 동시에 언급한 것은 "페이로드"라는 용어가 다양한 기술적 문맥에서 어떻게 사용되는지 예시를 들기 위한 것이었습니다.

• JWT (JSON Web Token): JWT는 웹 애플리케이션에서 인증과 정보 전송을 위해 사용되는 토큰입니다. 페이로드에는 사용자에 관한 정보나 권한 등의 클레임이 포함됩니다.
• FTP (File Transfer Protocol): FTP는 컴퓨터 네트워크에서 파일을 전송하기 위한 프로토콜입니다. 페이로드는 이 경우 전송되는 실제 파일의 데이터를 의미합니다.

따라서, 두 기술 사이에는 직접적인 연결이나 관계는 없으며, "페이로드"라는 개념의 다양한 사용 예시를 설명하기 위해 두 기술을 언급했습니다.

JWT의 장단점

장점

1. 상태를 저장하지 않는 인증: 서버 측에 세션 정보를 저장할 필요가 없기 때문에, Stateless한 인증 방식을 구현할 수 있습니다. 이로 인해 확장성이 높아집니다.
2. 모바일 어플리케이션에 적합: JWT는 HTTP 헤더에 포함될 수 있기 때문에, 모바일 환경에서도 효과적으로 사용될 수 있습니다.
3. 다중 도메인에서의 사용: JWT는 쿠키에 종속되지 않으므로, 다양한 도메인이나 서브도메인 간에 쉽게 전달될 수 있습니다.
4. 간편한 정보 교환: JWT는 JSON 포맷을 사용하기 때문에 데이터를 쉽게 교환할 수 있습니다.
5. 자체 정보 포함: JWT에는 만료 시간, 발행자 등의 정보가 자체적으로 포함될 수 있어, 별도의 조회 작업 없이 토큰 자체로 필요한 정보를 알 수 있습니다.

단점

1. 토큰 크기: 정보를 토큰에 포함시키면 토큰의 크기가 커질 수 있어, 네트워크 부하가 증가할 수 있습니다.
2. 서버에서의 상태 관리: 일부 상황에서는 사용자의 상태를 서버에서 관리해야 할 필요가 있을 수 있으나 JWT 자체는 Stateless하기 때문에 이러한 관리가 어려울 수 있습니다.
3. 재발급의 어려움: JWT의 만료 시간이 도래하면 새로운 토큰을 발급해야 합니다. 이를 위한 추가적인 로직이 필요합니다.
4. 보안 이슈: 토큰이 탈취되면 중요한 정보가 노출될 위험이 있습니다. 또한, 약한 키나 잘못된 구현으로 인해 토큰의 무결성이 침해될 수 있습니다.
5. 삭제의 어려움: 토큰을 즉시 만료시키기 위한 방법이 없기 때문에, 토큰이 유효한 시간 동안은 해당 토큰이 유효하게 됩니다.

JWT는 많은 장점을 가지고 있지만, 적절한 사용 시나리오와 보안 고려사항을 잘 파악하여 사용해야 합니다.

JWT가 HTTP 프로토콜 중 포함 되는 영역

JWT (JSON Web Token)는 주로 HTTP 헤더에 포함되어 사용되지만, 꼭 헤더에만 포함될 수 있는 것은 아닙니다.

1. HTTP 헤더에 포함:
   • 주로 Authorization 헤더에 포함되어 전송됩니다. 예를 들어, Bearer 인증 스키마를 사용하여 Authorization 헤더에 JWT를 포함시킬 수 있습니다.
   • Authorization: Bearer [JWT 토큰]
   • 이 방식은 웹 API 호출 시 인증을 위해 가장 일반적으로 사용됩니다.
2. URL 매개변수로 포함:
   • JWT를 URL의 쿼리 매개변수로 전송하는 것도 가능합니다.
   • 이 방식은 리디렉션을 동반하는 OAuth2 인증 플로우 등에서 사용될 수 있습니다. 그러나 이 방법은 URL이 노출될 위험이 있기 때문에 민감한 정보를 포함한 JWT를 전송하는 데에는 권장되지 않습니다.
3. HTTP 바디에 포함:
   • 특정 요청에서 JWT를 HTTP 메시지의 바디에 포함시켜 전송할 수도 있습니다.
   • 예를 들어, JSON 형태의 메시지 바디에서 JWT를 하나의 속성 값으로 포함시켜 전송하는 것이 가능합니다.

최종적으로, JWT는 전송 매체나 방식에 종속적이지 않습니다. 그러나 보안상의 이유로 대부분의 시나리오에서는 HTTP 헤더를 통해 JWT를 전송하는 것이 일반적입니다. 어떤 방식으로 JWT를 전송하든지 간에, 토큰의 무결성과 보안을 항상 고려해야 합니다.

HTTP헤더 용량 제한 JWT의 길이 관련성과 고려해야 할 점

1. HTTP 헤더의 용량 제한:
   • 대부분의 웹 서버는 HTTP 헤더의 크기에 제한을 두고 있습니다. 예를 들면, Apache 서버는 기본적으로 요청 헤더의 크기 제한을 8KB로 설정하고 있습니다. Nginx는 기본적으로 4KB로 제한하고 있습니다. 이러한 제한은 웹 서버의 설정을 통해 조절할 수 있습니다.
   • 웹 브라우저도 일반적으로 HTTP 요청 헤더의 크기에 제한을 두고 있습니다. 대부분의 모던 브라우저는 이 제한을 넉넉하게 설정하고 있지만, 극단적으로 큰 JWT를 사용할 경우 문제가 될 수 있습니다.
2. JWT의 길이 문제:
   • JWT는 페이로드에 클레임을 포함하고, 이는 인코딩되어서 JWT의 크기를 증가시킵니다. 추가로, JWT는 디지털 서명이나 암호화를 위한 추가적인 데이터도 포함할 수 있습니다. 이로 인해 JWT는 상당히 길어질 수 있습니다.
   • 헤더의 크기 제한을 초과하는 JWT를 전송하려고 하면 HTTP 요청이 거부될 수 있습니다.

결론적으로, JWT의 길이는 실제 사용하는 클레임의 양과 JWT를 서명하거나 암호화하는 방식에 따라 결정됩니다. 웹 애플리케이션을 개발하거나 배포할 때, JWT의 길이와 서버 및 클라이언트의 HTTP 헤더 크기 제한을 고려해야 합니다. 필요한 경우 웹 서버의 설정을 조절하여 헤더의 크기 제한을 증가시킬 수 있습니다.

JWT의 실 사용 예

JWT (JSON Web Token)는 다양한 웹 애플리케이션 및 시스템에서 인증 및 정보 교환 목적으로 사용됩니다. JWT의 실 사용 예는 다음과 같습니다:

1. 사용자 인증:
   • 사용자가 로그인하면 서버는 사용자의 정보와 권한을 포함한 JWT를 발행하고, 클라이언트에게 반환합니다.
   • 클라이언트는 이후의 요청에서 해당 JWT를 HTTP 헤더에 포함시켜 서버에 전송합니다. 서버는 이 JWT를 검증하여 사용자의 인증 상태와 권한을 확인합니다.
   • 예: 웹 애플리케이션 로그인, 모바일 앱 인증
2. API 접근 제어:
   • 외부 서비스나 애플리케이션이 특정 API에 접근하려면 JWT를 이용해 인증을 수행할 수 있습니다.
   • 이를 통해 해당 API에 대한 접근 권한 및 요청 제한 등을 관리할 수 있습니다.
   • 예: OpenAPI 인증, 서드파티 애플리케이션의 API 접근 제어
3. 정보 교환:
   • JWT는 정보를 안전하게 전송하기 위한 수단으로 사용될 수 있습니다. JWT의 내용은 서명되므로 정보의 무결성을 검증할 수 있습니다.
   • 예: SSO (Single Sign-On) 시스템에서의 사용자 정보 전송, 서로 다른 시스템 간의 데이터 교환
4. OAuth 2.0 & OpenID Connect:
   • OAuth 2.0 인증 프로세스에서 JWT는 액세스 토큰 또는 ID 토큰으로 사용됩니다. 특히 OpenID Connect 프로토콜에서는 JWT 기반의 ID 토큰이 사용자 정보를 전달하는 데 사용됩니다.
   • 예: 소셜 로그인, OAuth 2.0 기반의 API 인증
5. Microservices 인증:
   • 마이크로서비스 아키텍처에서 서비스 간의 요청을 인증하기 위해 JWT를 사용할 수 있습니다.
   • 서비스는 JWT를 검증하여 요청을 한 서비스의 신원과 권한을 확인합니다.

위와 같은 사용 예를 통해 JWT는 웹 및 모바일 애플리케이션, API 서비스, 분산 시스템 등 다양한 환경에서 인증 및 정보 교환 목적으로 널리 사용되고 있음을 알 수 있습니다.

JWT를 이용한 인증 과정

JWT (JSON Web Token)의 토큰 인증 방법은 크게 다음 단계들로 이루어집니다:

1. 토큰 발행:
   • 사용자가 시스템에 로그인하거나 인증을 요구하는 작업을 수행할 때, 서버는 사용자의 정보와 권한, 그리고 다른 필요한 정보를 기반으로 JWT를 생성합니다.
   • 생성된 JWT는 주로 HMAC, RSA, ECDSA 등의 알고리즘을 사용하여 서명됩니다. 서명의 목적은 토큰의 무결성을 보장하고, 서버가 후에 이 토큰을 검증할 수 있게 하는 것입니다.
2. 토큰 전송:
   • 서버는 생성된 JWT를 클라이언트에게 반환합니다.
   • 클라이언트는 이 JWT를 저장하여 후속 요청에 사용합니다. 주로 JWT는 웹 스토리지, 쿠키, 메모리 등에 저장됩니다.
3. 토큰 사용:
   • 클라이언트는 서버로 요청을 보낼 때 저장한 JWT를 HTTP 헤더 (주로 Authorization 헤더)에 포함시켜 전송합니다.
   • 예: Authorization: Bearer [JWT 토큰]
4. 토큰 검증:
   • 서버는 요청을 받을 때 헤더에 포함된 JWT를 추출합니다.
   • JWT의 서명을 검증하여 토큰이 변조되지 않았음을 확인합니다. 이 과정에서 서버의 비밀 키나 공개 키가 사용될 수 있습니다.
   • 토큰의 유효기간 (exp 클레임), 발행일 (iat 클레임) 등의 클레임을 확인하여 토큰이 유효한 시간 내에 있는지 검증합니다.
   • 추가적으로, 다른 클레임들 (예: 사용자 ID, 권한 정보)도 검증될 수 있습니다.
5. 토큰 응답:
   • JWT가 올바르게 검증되면, 서버는 해당 요청을 처리하고 응답을 반환합니다.
   • 만약 JWT가 유효하지 않다면, 오류 메시지와 함께 인증 실패 응답을 반환할 수 있습니다.
6. 토큰 만료 및 재발행:
   • JWT는 일반적으로 유효기간이 있습니다. 토큰이 만료되면 클라이언트는 새로운 토큰을 요청해야 합니다.
   • 토큰 재발행을 위해 리프레시 토큰 방식을 사용하는 시스템도 있습니다. 이 방식에서는 원래의 JWT와 함께 장기 유효기간을 가진 리프레시 토큰이 발행되며, JWT가 만료될 경우 리프레시 토큰을 사용해 새로운 JWT를 받아옵니다.

위의 과정을 통해 JWT는 클라이언트와 서버 간의 인증 및 정보 교환에 효과적인 방법으로 사용됩니다.

서버 브라우저 서버 JWT의 생성 및 이동 후 반환

JWT(JSON Web Token)의 동작 과정은 대략 다음과 같습니다:

1. 토큰의 생성:
   • 사용자가 로그인 요청을 하면, 서버는 사용자의 인증 정보(예: 아이디와 비밀번호)를 검증합니다.
   • 인증이 성공적이면 서버는 사용자의 정보와 권한 등을 바탕으로 JWT를 생성합니다. 이 때의 JWT에는 사용자를 식별할 수 있는 정보와, 토큰의 발행 및 만료 시간, 그리고 다른 필요한 클레임들이 포함될 수 있습니다.
2. 토큰의 반환:
   • 생성된 JWT는 응답으로 클라이언트(브라우저)에게 반환됩니다.
3. 토큰의 저장:
   • 클라이언트는 반환받은 JWT를 저장합니다. 일반적으로 브라우저에서는 쿠키, 웹 스토리지(localStorage 또는 sessionStorage) 등의 수단으로 JWT를 저장합니다.
4. 토큰의 사용:
   • 클라이언트는 서버에 요청을 보낼 때 저장된 JWT를 HTTP 헤더 (주로 Authorization 헤더)에 포함시켜 전송합니다. 예를 들면, Authorization: Bearer [JWT 토큰] 형식으로 전송됩니다.
5. 토큰의 검증:
   • 서버는 클라이언트로부터 받은 요청에 포함된 JWT를 검증합니다. 토큰의 서명, 유효기간 등을 확인하여, 해당 토큰이 유효하고 변조되지 않았는지 검증합니다.
6. 응답의 반환:
   • 토큰이 유효하다면 요청을 처리한 후 그 결과를 클라이언트에게 반환합니다. 토큰이 유효하지 않는 경우, 인증 오류와 같은 응답을 클라이언트에게 전달합니다.

이러한 방식을 통해 서버는 상태를 저장하지 않고도 클라이언트의 인증 상태와 정보를 유지할 수 있으며, 클라이언트는 필요할 때마다 서버에 자신의 인증 상태를 증명하는 토큰을 제출할 수 있습니다.

Cookie와 Session을 이용해서 인증하는 방법과 JWT로 인증하는 방법의 차이와 장단점

1. 쿠키와 세션을 이용한 인증

작동 방식:

• 사용자가 로그인에 성공하면 서버는 사용자의 인증 정보를 세션 저장소에 저장하고, 해당 세션에 대한 고유한 식별자(세션 ID)를 생성합니다.
• 이 세션 ID는 쿠키로 사용자의 브라우저에 전달됩니다.
• 사용자가 서버에 다시 요청을 할 때 쿠키에 저장된 세션 ID가 함께 전송되어, 서버는 이 ID를 통해 사용자의 인증 정보를 세션 저장소에서 조회합니다.

장점:

• 상대적으로 구현이 간단하고 직관적입니다.
• 서버 측에서 사용자의 세션 상태를 관리할 수 있어, 필요에 따라 세션을 강제로 만료시킬 수 있습니다.

단점:

• 서버 측에서 세션 정보를 유지해야 하므로 메모리 사용량이 증가할 수 있습니다.
• 확장성이 떨어집니다. 특히 분산된 환경(예: 로드 밸런서 뒤의 여러 서버)에서는 세션 정보를 공유하기 위한 추가적인 설정이나 인프라가 필요합니다.
• 사용자의 요청마다 서버는 세션 저장소를 조회해야 하므로 I/O 부하가 증가할 수 있습니다.

2. JWT를 이용한 인증

작동 방식:

• 사용자가 로그인에 성공하면 서버는 사용자의 정보와 권한 등을 바탕으로 JWT를 생성하여 클라이언트에 반환합니다.
• 클라이언트는 이 JWT를 저장하고, 서버에 요청을 보낼 때 이 토큰을 함께 전송합니다.
• 서버는 전달받은 JWT의 유효성과 만료 시간 등을 검증한 후 요청을 처리합니다.

장점:

• 상태 비저장(stateless)이므로 서버 측에 세션 정보를 저장할 필요가 없습니다. 이로 인해 확장성이 뛰어나며, 분산 환경에서도 용이하게 동작합니다.
• 토큰 기반의 인증은 다양한 플랫폼과 서비스 간의 인증에 활용될 수 있습니다.

단점:

• JWT의 길이가 길어질수록 HTTP 헤더의 크기가 커져 네트워크 부하가 증가할 수 있습니다.
• JWT가 탈취되면 그 토큰의 만료 시간까지 사용자를 가장할 수 있으므로, 짧은 유효기간 설정과 함께 다른 보안 조치가 필요합니다.
• JWT 내의 정보는 기본적으로 암호화되지 않기 때문에 중요한 정보를 담지 않아야 하며, 필요하다면 별도로 암호화 처리가 필요합니다.

두 인증 방식은 각각의 환경과 요구 사항에 따라 적합하게 선택되어 사용되어야 합니다.

JWT 탈취 가능성과 방지 방법

JWT 탈취 가능성:

1. 크로스 사이트 스크립팅 (XSS):
   • 웹 사이트에 악성 스크립트 코드가 주입되면, 이 코드를 통해 웹 페이지에 접속한 사용자의 JWT를 탈취할 수 있습니다. 주로 웹 스토리지에 저장된 JWT를 대상으로 합니다.
2. 크로스 사이트 요청 위조 (CSRF):
   • CSRF는 공격자가 사용자를 속여 특정 웹 사이트에 악의적인 요청을 보내게 만드는 공격입니다. 하지만, 이 방법은 JWT를 탈취하기 보다는 탈취된 JWT를 사용하여 악의적인 요청을 보내는 데 활용됩니다.
3. 인터셉트 어택 (중간자 공격):
   • 네트워크 통신 중에 데이터를 도청하거나 가로챌 수 있습니다. HTTPS가 아닌 HTTP로 JWT를 전송하면 중간에서 데이터를 가로채는 것이 가능합니다.
4. 서버 누출:
   • 서버의 로그나 기타 방법으로 JWT가 누출될 수 있습니다. 로그에 JWT를 기록하는 것은 위험할 수 있습니다.

방지 방법:

1. HTTPS 사용:
   • 데이터 전송 시 HTTPS를 사용하여 암호화된 채로 전송합니다. 이를 통해 중간자 공격을 방지할 수 있습니다.
2. JWT의 저장 위치 주의:
   • JWT를 브라우저의 로컬 스토리지나 세션 스토리지에 저장하는 것은 XSS 공격의 대상이 될 수 있습니다. 가능한 쿠키를 사용하여 JWT를 저장하되, 쿠키의 httpOnly 옵션을 활성화하여 자바스크립트에서의 접근을 차단합니다.
3. 유효 기간 설정:
   • JWT에 짧은 유효 기간을 설정하여, 탈취 당하더라도 사용 범위를 제한합니다.
4. XSS 방지:
   • 입력 데이터의 검증 및 적절한 이스케이핑, CSP (Content Security Policy) 설정 등을 통해 XSS 공격을 방지합니다.
5. CSRF 방지:
   • CSRF 토큰 사용, 동일 출처 정책 (Same-Origin Policy) 준수, Referrer 검사 등의 방법으로 CSRF 공격을 방지합니다.
6. 서버 로그 관리:
   • 서버 로그에는 절대 JWT나 개인정보 같은 민감한 정보를 기록하지 않습니다. 로그 관리 및 모니터링도 철저히 수행합니다.

이 외에도 다양한 방어 기법과 전략이 있으니, 주기적인 보안 리뷰와 최신 보안 트렌드에 대한 업데이트를 유지하는 것이 중요합니다.

요약

JWT를 이용한 토큰 기반 인증 방식은 서버 측에서 세션 정보를 저장하지 않고도 클라이언트의 인증 상태와 정보를 유지할 수 있으며, 상대적으로 확장성이 뛰어나다. 그러나 JWT 탈취 가능성이 있으므로 HTTPS 사용, JWT의 저장 위치 주의, 유효 기간 설정, XSS 방지, CSRF 방지, 서버 로그 관리 등의 방어 기법과 전략이 필요하다.