JWT 대 세션 인증

일반적으로 애플리케이션을 사용할 때 가장 먼저 하는 단계는 인증입니다. 여기서 최종 사용자는 자신의 신원 자격 증명을 제공하여 성공적으로 로그인을 합니다. 이 단계 후에는 아이덴티티 공급자, 인증 서버 등과 같은 아이덴티티 시스템이 사용자가 누구인지, 그리고 어떤 리소스에 접근할 수 있는지를 알게 됩니다.

HTTP는 본질적으로 상태가 없기 때문에 세션의 각 요청은 독립적이며 이전 요청의 정보를 기억하지 않습니다. 사용자가 각각의 작업을 수행할 때마다 다시 인증해야 한다면 번거로울 뿐만 아니라 사용자 경험에 해를 끼칩니다.

여기서 세션 기반 인증과 JWT (JSON Web Tokens) 인증이라는 두 가지 인기 방법이 있습니다. 각각 고유의 장점과 트레이드오프가 있으며, 이를 선택할지의 여부는 애플리케이션의 특정 요구 사항에 따릅니다. 이 둘 중 하나를 결정하려 한다면 이 가이드가 도움이 될 것입니다.

세션 기반 인증이란 무엇입니까?#

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

세션 기반 인증은 어떻게 작동합니까?#

세션 생성

1. 사용자가 인증을 받고 자격 증명(e.g., 이메일과 비밀번호)을 제공합니다.
2. 자격 증명이 유효하면 서버는 해당 세션을 나타내는 지속적인 기록을 생성합니다. 세션에는 임의의 문자열, 사용자 식별자, 세션 시작 시간, 세션 만료 시간 등과 같은 정보가 포함됩니다.
3. SessionID는 데이터베이스에 저장되며 사용자 클라이언트에 쿠키로 반환됩니다.

세션 검증

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

세션을 취소하는 방법은 무엇입니까?#

세션은 실시간으로 무효화할 수 있으며, 이는 빠른 액세스 취소가 필요한 상황에서 유용합니다.

• 사용자가 수동으로 로그아웃: 서버가 세션 기록을 삭제하여 사용자가 로그아웃됩니다.
• 관리자에 의한 사용자 강제 로그아웃: 관리자나 시스템이 특정 세션을 종료할 수 있으며, 예를 들어 보안 침해가 발생했을 때 수행됩니다.
• 세션 만료: 세션은 일정 시간 동안 활동이 없거나 고정된 시간 제한 후 자동으로 만료될 수 있습니다.

세션 기반 인증의 장점#

• 간단하고 신뢰할 수 있음: 세션 기록은 명확하고 중앙 집중화된 출처를 제공하여 높은 신뢰도를 보장하며, 이를 통한 승인 결정이 더 신뢰할 수 있습니다.
• 실시간 취소: 세션 기록을 삭제하거나 무효화하여 사용자의 접근 권한을 빠르게 취소할 수 있습니다.

세션 기반 인증의 단점#

• 분산 시스템에서의 지연 시간: 여러 서버에서 세션 데이터를 유지 관리하려면 항상 세션 저장소를 동기화해야 합니다. 이는 각 요청 시 세션 저장소를 확인해야 하기 때문에 추가적인 지연을 도입합니다.
• 높은 자원 소비: 각 세션이 서버 자원을 차지하여 사용자 기반이 확장되면 성능에 영향을 미칩니다.
• 보안 위험: 세션 하이재킹(세션 쿠키 도난)이 발생하면 사용자 계정에 무단으로 접근할 수 있습니다.
• API에 대한 제한된 사용: 세션 기반 인증은 모바일 앱에 적합하지 않습니다. 세션 데이터를 서버에 저장하면 많은 사용자의 경우 부하와 복잡성이 증가할 수 있습니다. 또한 쿠키를 사용하는데, 이는 모바일 장치에서 처리하기 어렵습니다.

JWT 인증이란?#

JSON Web Tokens (JWTs)는 사용자 정보가 포함된 JSON 객체를 토큰에 직접 임베딩하는 방식으로, 세션 기반 방법과 달리 상태를 갖지 않습니다. 즉, 서버는 인증 기록을 관리하지 않습니다.

JWT 인증은 어떻게 작동합니까?#

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

• 헤더는 서명 알고리즘(e.g., HS256)과 토큰 유형(JWT)을 포함합니다.
• 페이로드는 사용자의 신원, 사용자 역할, 만료 시간과 같은 클레임을 포함합니다.
• 서명은 헤더와 페이로드를 키로 서명하여 서명이 변조되지 않았는지 검증할 수 있도록 합니다.

JWT 발급

1. 클라이언트가 인증 서버에 사용자 자격 증명을 보냅니다 (여러 도메인에서의 접근을 관리하는 데 특히 유용합니다.)
2. 인증에 성공하면 서버는 헤더, 페이로드, 서명을 포함하는 JWT를 생성합니다.
3. AuthServer는 클라이언트에게 발급된 토큰을 보냅니다. 클라이언트는 JWT를 쿠키, localStorage, sessionStorage 등으로 저장합니다.

세션 기반 인증도 유사한 프로세스를 따릅니다. 그러나 인증 후 사용자 정보는 서버의 세션 내에 저장되며, JWT는 클라이언트에게 전송되어 저장 및 사용됩니다.

토큰 검증

1. 이후의 API 요청 시, 클라이언트는 JWT를 Authorization 헤더에 담아 전송합니다 (Bearer <token>).
2. 서버는 비밀 키 또는 공개 키를 사용하여 JWT의 서명을 검증하고 클레임(예: 만료, 발행인)을 확인합니다.
3. 토큰이 유효하면 서버는 클라이언트에게 요청한 리소스에 대한 접근을 허용합니다.

세션 기반 인증은 서버가 외부 또는 중앙 집중화된 데이터베이스에 의존할 경우 느릴 수 있는 세션 저장소를 조회해야 합니다. 반면에, JWT 인증은 상태가 없어 모든 필요한 정보가 클라이언트 토큰에 저장되며, 서명을 사용하여 보안을 보장합니다. 이는 세션 관리를 없애 로릴 수 있습니다.

JWT를 취소하는 방법은 무엇입니까?#

클라이언트 측에서는 보통 로그아웃 시 로컬 세션을 지우고 (ID, 액세스, 리프레시 토큰 등) 저장소에서 토큰을 제거합니다. 그러나 JWT 인증의 경우, 이는 사용자 로그아웃이 로컬에서만 이루어지며, 중앙 집중화된 세션이 변경되지 않기 때문에 동일한 세션 하에서 다른 앱에 계속 접근할 수 있습니다. 이는 토큰이 만료되거나 수동으로 종료될 때까지 유지됩니다.

JWT(JSON Web Token)를 취소하는 것은 세션 기반 인증보다 어렵습니다. JWT는 상태가 없으며 한번 발급되면 취소할 수 없기 때문입니다. 몇 가지 일반적인 방법은 다음과 같습니다.

• 짧은 만료 시간: JWT에 짧은 exp 클레임(예: 15분)을 설정합니다. 만료되면 사용자는 다시 인증해야 합니다. 토큰이 침해되었을 경우, 공격자는 제한된 시간 동안만 이를 사용할 수 있습니다. 원활한 사용자 경험을 위해 리프레시 토큰을 사용하여 재인증의 불편함을 최소화할 수 있습니다.
• 토큰 블랙리스트: 중요한 경우(예: 사용자 로그아웃, 비밀번호 변경)에는 취소된 토큰 목록인 블랙리스트를 유지합니다. 서버는 들어오는 토큰을 이 블랙리스트에 대해 검사하고 일치하는 경우 거부합니다. 이 접근법은 효과적이지만, 이는 JWT의 상태가 없는 특성과는 상충하며 목록이 너무 커지면 비효율적으로 작동할 수 있습니다.
• 취소 엔드포인트: 토큰(e.g., 리프레시 토큰)을 무효화할 수 있는 인증 서버에 취소 엔드포인트를 도입합니다. 리프레시 토큰이 취소되면, 그것으로부터 발급된 모든 액세스 토큰은 더 이상 갱신되지 않습니다. 이 방법은 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과 OIDC를 사용하여 안전한 클라우드 기반 애플리케이션을 작성하는 방법에 대한 자세한 설명을 공유하며, 액세스 토큰 및 ID 토큰에 대한 JWT 형식을 사용하는 것이 좋습니다.

• 모바일 애플리케이션

  모바일 앱은 보통 JWT를 선호합니다, 이는 토큰이 장치에 안전하게 저장되고 각 API 요청 시 함께 전송될 수 있기 때문입니다. 안드로이드 / 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는 확장 가능한 아이덴티티 엑세스 관리 인프라로, 클라우드 서비스와 오픈 소스 버전 모두를 제공하여 완전한 아이덴티티 솔루션을 제공합니다.