JWT 대 세션 인증

일반적으로, 애플리케이션을 사용할 때 첫 번째 단계는 인증입니다. 여기서 최종 사용자는 자신의 신원 자격 증명을 제공하여 성공적으로 로그인합니다. 이 단계가 완료되면, 신원 시스템(즉, 신원 제공자, 인증 서버 등)은 사용자가 누구인지와 그들이 액세스할 수 있는 리소스를 알게 됩니다.

HTTP는 본질적으로 상태가 없기 때문에 세션 내 각 요청은 독립적이며 이전 요청의 정보를 기억하지 않습니다. 사용자에게 모든 동작에 대해 다시 인증을 요구하는 것은 번거롭고 사용자 경험에 해가 됩니다.

이제 세션 기반 인증과 JWT (JSON Web Tokens) 인증에 대해 알아보겠습니다. 이는 인증 상태를 유지하는 데 인기 있는 두 가지 방법입니다. 각 방법은 고유한 장점과 트레이드오프가 있으며, 어느 것을 선택할지는 애플리케이션의 특정 요구에 따라 달라집니다. 두 가지 중에서 결정해야 할 경우 이 가이드가 도움이 될 것입니다.

세션 기반 인증이란?#

세션 기반 인증은 사용자의 인증 상태 기록을 유지하기 위해 서버에 의존합니다. 세션을 생성하고 관리함으로써 서버는 사용자가 로그인된 상태를 유지하고 매번 자격 증명을 다시 입력하지 않고도 애플리케이션과 상호작용할 수 있도록 합니다.

세션 기반 인증 작동 방식#

세션 생성

1. 사용자가 인증하고 일부 자격 증명 (예: 이메일 및 비밀번호)을 제공합니다.
2. 자격 증명이 유효한 경우 서버는 해당 세션을 나타내는 지속적인 기록을 생성합니다. 세션에는 임의의 문자열, 사용자 식별자, 세션 시작 시간, 세션 만료 시간 등이 포함될 수 있습니다.
3. SessionID는 데이터베이스에 저장되고 클라이언트로 쿠키 형태로 반환됩니다.

세션 검증

1. 이 프로세스는 사용자가 수동으로 (예: 탭 클릭, 페이지 새로 고침) 또는 클라이언트에 의해 자동으로 (예: 초기 페이지 로드 중 또는 SessionID가 포함된 API 호출 시) 트리거될 수 있습니다.
2. 각 후속 호출은 클라이언트에서 세션 쿠키를 포함한 HTTP 요청을 서버로 보냅니다.
3. 서버는 서버에 저장된 세션 데이터를 참조하여 SessionID를 검증합니다.
4. 유효하면 서버는 요청을 처리하고 사용자를 승인합니다.

세션 해제 방법#

세션은 실시간으로 무효화될 수 있으며, 이는 신속한 액세스 해제가 필요한 상황에서 유용합니다.

• 사용자가 수동으로 로그아웃: 서버가 세션 기록을 삭제하여 사용자를 로그아웃시킵니다.
• 관리자가 사용자 강제 로그아웃: 관리자나 시스템이 데이터베이스에서 삭제하여 특정 세션을 종료할 수 있습니다. 예를 들어, 보안 침해 시에.
• 세션 만료: 세션은 비활성 기간 또는 일정 시간 후에 자동으로 만료될 수 있습니다.

세션 기반 인증의 장점#

• 간단하고 신뢰성 있음: 세션 기록은 명확하고 중앙 집중된 출처를 제공하여 높은 수준의 신뢰를 제공하고 인증 결정을 더 신뢰할 수 있게 만듭니다.
• 실시간 해제: 세션 기록을 삭제하거나 무효화함으로써 사용자의 액세스를 신속하게 해제할 수 있습니다.

세션 기반 인증의 단점#

• 분산 시스템에서의 지연: 여러 서버에서 세션 데이터를 유지하려면 항상 세션 저장소를 동기화해야 합니다. 이는 요청이 있을 때마다 서버가 세션 저장소를 확인해야 하기 때문에 추가적인 지연을 초래합니다.
• 높은 리소스 소비량: 각 세션은 서버 리소스를 차지하며, 사용자 기반이 확장될 때 성능에 영향을 미칩니다.
• 보안 위험: 세션 하이재킹 (도난된 세션 쿠키를 통해)은 사용자 계정에 무단 액세스를 허용할 수 있습니다.
• API에 대한 제한된 사용: 세션 기반 인증은 모바일 앱에 적합하지 않습니다. 이는 많은 사용자와 함께 서버에 세션 데이터를 저장해야 하기 때문에 부하가 증가하고 복잡해질 수 있습니다. 게다가 쿠키를 사용하므로 모바일 디바이스에서 다루기 어렵습니다.

JWT 인증이란?#

JSON Web Tokens (JWTs)는 모든 관련 사용자 정보를 JSON 개체로 직접 포함하여 다른 접근 방식을 취합니다. 세션 기반 방법과 달리 JWT는 상태가 없습니다, 즉 서버는 인증 기록을 관리하지 않습니다.

JWT 인증 작동 방식#

JWT는 세 부분으로 구성됩니다: 헤더, 페이로드, 서명.

• 헤더는 서명 알고리즘 (예: HS256) 및 토큰의 유형 (JWT)을 포함합니다.
• 페이로드는 사용자의 신원, 사용자 역할, 만료 시간과 같은 주요 클레임을 포함합니다.
• 서명는 헤더와 페이로드를 서명하는 데 사용되는 키로, 서명이 변경되지 않았는지 확인할 수 있습니다.

JWT 발급

1. 클라이언트는 인증 서버에 사용자 자격 증명을 보냅니다. (다수의 도메인에 걸쳐 액세스를 관리하는 데 특히 유용한 범용 신원 제공자)
2. 인증이 성공하면 서버는 헤더, 페이로드, 서명을 포함하는 JWT를 생성합니다.
3. AuthServer는 발급된 토큰을 클라이언트에 보냅니다. 클라이언트는 JWT를 (예: 쿠키, localStorage 또는 sessionStorage에) 저장합니다.

세션 기반 워크플로우는 비슷한 과정을 따릅니다. 그러나 인증 후 사용자 정보가 세션 내에 서버에 저장되는 반면, JWT는 클라이언트에 저장 및 후속 사용을 위해 전송된 토큰에 의존합니다.

토큰 검증

1. 후속 API 요청을 위해 클라이언트는 Authorization 헤더 (Bearer <token>)에 JWT를 보냅니다.
2. 서버는 비밀 키 또는 공개 키를 사용하여 JWT의 서명을 검증하고 클레임 (예: 만료, 발행자)을 확인합니다.
3. 토큰이 유효하면 서버는 클라이언트에게 요청된 리소스에 대한 액세스를 부여합니다.

세션 기반 인증은 서버가 세션 저장소를 조회해야 하며, 이는 외부 또는 중앙 집중식 데이터베이스에 의존할 경우 특히 느릴 수 있습니다. 반면, JWT 인증은 상태가 없으며, 클라이언트 토큰에 모든 필요한 정보를 저장하고 서명을 활용하여 보안을 보장합니다. 이는 세션 관리를 필요하지 않아 더욱 빠르고 확장 가능하게 만들어 주며, 특히 분산 시스템에서 유리합니다.

JWT 해제 방법#

클라이언트 측에서는 서명을 해제하는 것이 일반적으로 로컬 세션을 지우고 스토리지에서 토큰 (ID, 액세스, 리프레시 토큰)을 제거하는 것을 의미합니다. 그러나 JWT 인증의 경우, 이는 사용자 로컬에서만 로그아웃됩니다. 따라서 동일한 세션에서 다른 앱에 여전히 액세스할 수 있으며, 이는 토큰이 만료되거나 수동으로 종료될 때까지 계속됩니다.

JWT (JSON Web Token)를 해제하는 것은 상태가 없는 JWT의 특성상 더 어려운데, 이는 특정 전략을 구현하지 않는 이상 발행된 후 무효화할 수 없기 때문입니다. 일반적인 방법으로는:

• 짧은 만료 시간: JWT에 짧은 exp 클레임 (예: 15 분)을 설정하세요. 만료되면 사용자는 다시 인증해야 합니다. 이것은 만약 토큰이 손상된 경우 위험을 최소화하며, 공격자는 제한된 시간 동안만 사용할 수 있습니다. 사용자 경험을 원활하게 유지하기 위해 리프레시 토큰을 사용할 수 있습니다.
• 토큰 블랙리스트: 중요한 경우 (예: 사용자 로그아웃, 비밀번호 변경)에는 해제된 토큰의 블랙리스트를 유지하세요. 서버는 들어오는 토큰을 이 블록리스트와 대조하여 일치하는 경우 거부합니다. 효과적이긴 하지만, 이 접근 방식은 상태가 없는 JWT의 특성에 반하고, 리스트가 커지면 비효율적일 수 있습니다.
• 해제 엔드포인트: 인증 서버에 해제 엔드포인트를 도입하여 토큰 (예: 리프레시 토큰)을 무효화할 수 있습니다. 리프레시 토큰이 해제되면 그 토큰에서 발급된 모든 액세스 토큰은 더 이상 갱신되지 않습니다. 이 방법은 OAuth2 흐름에서 잘 작동합니다.

JWT 인증의 장점#

• 빠르고 더 많은 정보 제공: JWT의 자가 포함 특성은 서버 상호 작용 없이 클라이언트 측 검증을 더 빠르고 효율적으로 만듭니다. 예를 들어 사용자 역할 또는 기타 관련 데이터를 포함하여 커스텀 클레임을 토큰에 포함시킬 수 있으며, 서버는 데이터베이스를 조회하지 않고 역할을 결정할 수 있습니다.
• 향상된 보안: JWT는 서명 및 암호화 기법을 사용하여 공격을 더 어렵게 만듭니다.
• 크로스 도메인 지원: JWT는 싱글 사인온 (SSO)과 크로스 도메인 인증에 적합합니다. 사용자들은 동일한 토큰으로 여러 도메인이나 서비스를 인증할 수 있습니다.
• 모바일 친화적: JWT는 상태가 없는 인증이 필요한 모바일 애플리케이션에 잘 맞습니다. 토큰을 클라이언트 측에 저장하고 각 요청과 함께 전송할 수 있어 효율성과 사용 편의성을 높입니다.

JWT 인증의 단점#

• JWT는 실시간으로 업데이트되지 않음

  한 번 JWT가 서명되면 서명을 취소하거나 업데이트할 수 없으며 서명이 유효하고 만료되지 않은 한 유효합니다.

  사용자의 접근 권한이 변경되면 (보통 감소됨), 사용자는 JWT가 만료될 때까지 리소스에 대한 제거된 접근 권한을 계속 가집니다. 마찬가지로, JWT가 역할 기반의 승인 정보를 포함하면, 새 승인 범위는 기존 JWT가 만료되기 전까지는 적용되지 않습니다. 즉, JWT는 실시간 해제에 적합하지 않으며 사용자에게 적절한 만료 시간을 설정하여 이 문제를 완화할 수 있습니다.

• 다중 디바이스 및 해제 딜레마

  모든 발급된 JWT를 만료되기 전에 유효성을 검사하여 모든 디바이스의 사용자 해제를 구현할 수 없습니다. 이론적으로 서명 키를 취소하여 JWT를 무효화할 수 있지만, 이는 해당 키를 사용하는 모든 JWT를 무효화하여 캐시 키를 처리하는 과정이 단순한 사용자 해제 작업에는 비현실적입니다.

일부 신원 제공자는 이러한 JWT 문제에 대한 사전 솔루션을 제공할 수 있습니다. 자세한 내용은 "JWT 인증 경험을 향상시키는 모범 사례”를 참조하세요.

JWT와 세션의 차이점은 무엇입니까?#

세션과 JWT는 상태가 없는 HTTP 세계에서 인증 및 인가 컨텍스트를 지속시키기 위한 두 가지 인기 있는 접근 방식입니다. 두 접근 방식 모두 장단점이 있지만, 서로 다른 이점과 단점을 제공합니다.

세션은 개별 요청에 대한 강력한 인증 보장을 제공하며 안전하게 구현하기 더 간단합니다. 하지만, 서버 측 데이터베이스 검증에 의존하는 것은 지연 오버헤드를 도입하여 반응성이 높은 애플리케이션의 사용자 경험에 부정적인 영향을 미칠 수 있습니다.

반면에 JWT는 빠른 인증과 외부 앱과의 상호 운용성에 유리하지만, 보안 복잡성을 해결하기 위해 개발자의 노력이 더 필요합니다. 예를 들어, 사용자의 액세스가 해제될 때 클라이언트에게 웹훅을 사용하여 알림을 전송하여 클라이언트가 캐시된 JWT를 지우고 사용자를 재인증하도록 강제할 수 있습니다.

토큰 기반 인증은 관리 가능한 단점으로 확장에 더 적합하므로 점점 더 많은 현대 애플리케이션에서 채택되고 있습니다.

세션 대 JWT: 올바른 방법 선택하기#

인증 방법은 앱의 아키텍처와 특정 요구 사항에 맞추어야 합니다. 다음은 결정하는 데 도움이 되는 빠른 가이드입니다:

세션 기반 인증을 사용할 때#

세션 기반 인증은 실시간 세션 제어가 필요하거나 중앙 집중 관리가 필요하며 확장성이 큰 문제가 아닌 경우에 가장 잘 작동합니다. 다음과 같은 경우에 유리합니다:

• 지속적인 세션을 가진 웹 애플리케이션

  온라인 쇼핑 웹사이트와 같은 플랫폼에서는 세션을 통해 사용자의 이동 방문 중 사용자, 쇼핑 카트 및 선호도를 추적해야 합니다.

• 실시간 세션 제어가 필요한 애플리케이션

  은행 또는 금융 서비스와 같은 애플리케이션은 서버 제어 세션 데이터를 통해 강력한 액세스 관리 및 보안을 보장합니다.

• 단일 서버 또는 소규모 시스템

  내부 도구나 대규모 확장 요구가 없는 소규모 애플리케이션은 간단한 세션 관리로 사용 편의성과 신뢰성을 제공합니다.

JWT 인증을 사용할 때#

JWT 인증은 확장성, 효율성 및 분산 시스템을 우선시하는 애플리케이션에 더 적합합니다. 클라이언트와 서버 간의 상태가 없는 상호작용에 특히 유용합니다. 다음을 위해 토큰 기반 인증을 고려하세요:

• 싱글 사인온 (SSO)

  JWT는 싱글 사인온에 적합하며, 사용자가 한번 인증하면 동일한 토큰을 사용하여 여러 서비스나 애플리케이션에 원활하게 액세스할 수 있게 합니다. OAuth 2.0 및 OpenID Connect를 사용하여 안전한 클라우드 기반 애플리케이션에 대한 자세한 설명을 공유하고 JWT 형식을 액세스 토큰 및 ID 토큰에 사용하세요.

• 모바일 애플리케이션

  모바일 앱은 일반적으로 인증에 JWT를 선호하므로 디바이스에 안전하게 저장하고 각 API 요청시 전송할 수 있습니다. Android / iOS에 대한 JWT 인증의 빠른 통합을 확인해 보세요.

• 마이크로서비스 아키텍처

  마이크로서비스 환경에서 JWT는 중앙 세션 저장소에 의존하지 않고 각 서비스가 독립적으로 토큰을 검증할 수 있도록 하여 확장성과 효율성을 보장합니다.

• 크로스 도메인 인증

  JWT는 여러 도메인이나 하위 도메인 (예: api.example.com, dashboard.example.com, docs.example.com)을 포함하는 시나리오에서 뛰어납니다. 쿠키와 달리, JWT는 추가 종속성 없이 도메인 간 인증을 허용합니다.

• API 및 웹 서비스

  RESTful API와 웹 서비스는 일반적으로 JWT를 사용하여 인증합니다. 왜냐하면 그것들은 가볍고 휴대 가능하며 서버 측 세션 관리의 필요성을 제거하기 때문입니다. 머신-투-머신 인증에 대해 자세히 살펴보세요. 이 시나리오에서는 앱이 리소스와 직접 통신해야 합니다.

JWT 인증 경험을 향상시키기 위한 모범 사례#

JWT 인증은 훌륭한 도구이지만 사용자 경험에 영향을 미칠 수 있는 문제를 수반할 수 있습니다. Logto는 이러한 장애를 극복하기 위한 쉽고 신뢰할 수 있는 솔루션을 제공하여 안전하고 효율적인 인증을 위한 최상의 선택이 됩니다.

JWT로 사용자 로그아웃 문제 처리하기#

JWT 인증의 일반적인 문제 중 하나는 적절한 사용자 로그아웃 경험을 보장하는 것입니다. Logto는 기본적으로 SDK를 통해 이 과정을 쉽게 만듭니다.

• 클라이언트 측에서 토큰 및 로컬 세션을 지우고 Logto의 종료 세션 엔드포인트로 사용자를 리디렉션하여 클라이언트 애플리케이션과 서버 모두에서 세션을 쉽게 종료할 수 있습니다.
• 또한, Logto는 백채널 로그아웃을 지원하여 AuthServer가 동일한 세션을 공유하는 모든 클라이언트 애플리케이션에 사용자가 로그아웃할 때 알림을 보낼 수 있습니다.

이런 방식으로 일관되고 안전한 세션 관리를 보장합니다. 로그아웃 처리에 대해 자세히 알아보세요.

사용자 권한 변경 처리하기#

JWT로 실시간으로 사용자 권한 변경을 처리하는 것도 까다로울 수 있습니다. JWT는 기본적으로 상태가 없기 때문에 업데이트된 권한이나 역할은 토큰이 만료될 때까지 적용되지 않을 수 있습니다. Logto는 이를 효과적으로 처리하기 위한 전략을 제공합니다:

• 이 사용자의 권한을 줄이는 경우: 짧은 액세스 토큰 만료 시간을 사용하거나 API 호출을 통해 동적으로 권한을 검증합니다.
• 이 사용자를 위한 새로운 권한 추가: AuthServer를 업데이트하여 새 권한 범위를 포함시키고, 사용자가 이러한 변경 사항에 동의하도록 재요청합니다.

이러한 솔루션들은 권한을 최신 상태로 유지하여 보다 안전하고 즉각적인 시스템을 보장합니다. 권한 변경 처리에 대해 자세히 알아보세요.

Logto는 확장 가능한 신원 액세스 관리 인프라로, 클라우드 서비스 및 오픈 소스 버전을 통해 완전한 신원 솔루션을 제공합니다.