인증과 같은 상황에서 세션보다 JWT를 사용하면 어떤 이점이 있습니까?
독립 실행 형 접근 방식으로 사용됩니까 아니면 세션에서 사용됩니까?
인증과 같은 상황에서 세션보다 JWT를 사용하면 어떤 이점이 있습니까?
독립 실행 형 접근 방식으로 사용됩니까 아니면 세션에서 사용됩니까?
답변:
JWT는 "세션"을 사용하는 것보다 이점이 없습니다. JWT는 서버에서 수행하는 대신 클라이언트에서 세션 상태를 유지하는 수단을 제공합니다.
사람들이이 질문을 할 때 종종 의미하는 것은 " 서버 측 세션 을 사용하는 것보다 JWT를 사용하는 것의 이점 "입니다.
서버 측 세션을 사용하면 세션 식별자를 데이터베이스에 저장하거나 메모리에 유지하고 클라이언트가 항상 동일한 서버에 연결되는지 확인해야합니다. 둘 다 단점이 있습니다. 데이터베이스 (또는 기타 중앙 집중식 스토리지)의 경우 병목 현상이 발생하고 유지 관리해야합니다. 본질적으로 모든 요청에 대해 수행해야하는 추가 쿼리입니다.
인 메모리 솔루션을 사용하면 수평 확장이 제한되고 세션은 네트워크 문제 (WiFi와 모바일 데이터 사이를 로밍하는 클라이언트, 서버 재부팅 등)의 영향을받습니다.
세션을 클라이언트로 이동하는 것은 서버 측 세션에 대한 종속성을 제거하는 것을 의미하지만 자체 문제 세트를 부과합니다.
이러한 문제는 JWT 및 기타 클라이언트 측 세션 메커니즘에서 모두 공유됩니다.
특히 JWT는 이들 중 마지막을 다룹니다. JWT가 무엇인지 이해하는 데 도움이 될 수 있습니다.
약간의 정보입니다. 사용자 세션의 경우 사용자 이름과 토큰이 만료되는 시간을 포함 할 수 있습니다. 그러나 세션 ID 또는 사용자의 전체 프로필 등 무엇이든 될 수 있습니다. (하지만 그렇게하지 마십시오) 악의적 인 당사자가 가짜 토큰을 생성하는 것을 방지하는 보안 서명이 있습니다. 쿠키 또는 Authorization헤더가 전송 되는 것처럼 모든 요청과 함께 전송합니다. 사실 그들은 일반적으로 HTTP Authorization헤더로 전송 되지만 쿠키를 사용하는 것도 좋습니다.
토큰이 서명되어 서버가 출처를 확인할 수 있습니다. 서버가 안전하게 서명 할 수있는 자체 능력을 신뢰한다고 가정합니다 (표준 라이브러리를 사용해야합니다. 직접 시도하지 말고 서버를 올바르게 보호하십시오).
토큰을 안전하게 전송하는 문제에 대한 대답은 일반적으로 암호화 된 채널 (일반적으로 httpS)을 통해 전송하는 것입니다.
클라이언트에 토큰을 안전하게 저장하는 것과 관련하여 악당이 토큰에 접근 할 수 없도록해야합니다. 이것은 (주로) 나쁜 웹 사이트의 JS가 토큰을 읽고 토큰을 다시 보내는 것을 방지하는 것을 의미합니다. 이는 다른 종류의 XSS 공격을 완화하는 데 사용되는 것과 동일한 전략을 사용하여 완화됩니다.
JWT를 무효화해야하는 경우이를 달성 할 수있는 확실한 방법이 있습니다. "다른 세션을 종료"하도록 요청한 사용자만을 위해 사용자 별 시대를 저장하는 것은 아마도 충분히 좋은 매우 효율적인 방법입니다. 애플리케이션에 세션 별 무효화가 필요한 경우 세션 ID를 동일한 방식으로 유지 관리 할 수 있으며 "종료 된 토큰"테이블은 전체 사용자 테이블보다 훨씬 작게 유지 관리 할 수 있습니다. 허용되는 가장 긴 토큰 수명.) 따라서 토큰을 무효화하는 기능은이 세션 종료 상태를 유지해야한다는 점에서 클라이언트 측 세션의 이점을 부분적으로 무효화합니다. 이것은 원래 세션 상태 테이블보다 훨씬 작은 테이블 일 가능성이 높으므로 조회는 여전히 더 효율적입니다.
JWT 토큰을 사용하는 또 다른 이점은 예상 할 수있는 모든 언어로 제공되는 라이브러리를 사용하여 구현하는 것이 합리적으로 쉽다는 것입니다. 또한 초기 사용자 인증 체계와 완전히 분리되어 있습니다. 지문 기반 시스템으로 전환하는 경우 세션 관리 체계를 변경할 필요가 없습니다.
더 미묘한 이점 : JWT가 "정보"를 전달할 수 있고 클라이언트가이 정보에 액세스 할 수 있기 때문에 이제 몇 가지 현명한 작업을 시작할 수 있습니다. 예를 들어 사용자에게 로그 아웃하기 며칠 전에 세션이 만료 될 것임을 상기시켜 토큰의 만료 날짜를 기준으로 재 인증 옵션을 제공합니다. 당신이 상상할 수있는 무엇이든.
요약하자면 JWT는 다른 세션 기술의 몇 가지 질문과 단점에 답합니다.
JWT는 보안 저장 또는 전송과 같은 다른 문제에 답하지 않지만 새로운 보안 문제를 소개하지는 않습니다.
JWT 주변에는 많은 부정적 요소가 존재하지만 다른 유형의 인증과 동일한 보안을 구현하면 괜찮습니다.
마지막 참고 사항 : 또한 쿠키 대 토큰이 아닙니다. 쿠키는 정보 비트를 저장하고 전송하기위한 메커니즘이며 JWT 토큰을 저장하고 전송하는 데에도 사용할 수 있습니다.
짧은 대답은 없음입니다.
더 긴 버전은 다음과 같습니다.
GraphQL 문서 에서이 권장 사항을 읽은 후 세션 관리를 위해 JWT를 구현했습니다 .
이러한 인증 메커니즘에 익숙하지 않은 경우 향후 유연성을 희생하지 않고 간단하므로 express-jwt를 사용하는 것이 좋습니다.
구현은 약간의 복잡성 만 추가했기 때문에 실제로 간단했습니다. 그러나 얼마 후, 나는 (당신처럼) 혜택이 무엇인지 궁금해하기 시작했습니다. 이 블로그 게시물에서 자세히 설명하는 것처럼 세션 관리가 진행되는 한 JWT에 대해 매우 적거나없는 것으로 나타났습니다.
내 2 센트는 joepie91의 유명한 블로그 게시물과 대조를 이룹니다.
현재 (그리고 미래의) 애플리케이션이 (대부분) 클라우드 네이티브
라는 점을 고려하면 애플리케이션이 확장됨에 따라 확장되는 Stateless JWT 인증 에는 경제적 이점
이 있습니다 . 클라우드 애플리케이션은 숨을 쉴 때마다 비용이 발생합니다 .
이 비용은 사용자가 더 이상 세션 저장소 "에 대해"인증 할 필요가 없을 때 줄어 듭니다.
처리
세션 저장소를 연중 무휴로 운영하려면 비용이 듭니다.
포드는 일시적이기 때문에 K8S의 세계에서 메모리 기반 솔루션을 사용할 수 없습니다.
고정 세션은 똑같은 이유로 잘 작동하지 않습니다.
스토리지
데이터 저장에는 비용이 듭니다. SSD에 데이터를 저장하는 데 더 많은 비용이 듭니다.
세션 관련 작업은 신속하게 해결해야하므로 광학 드라이브는 옵션이 아닙니다.
I / O
일부 클라우드 제공 업체는 디스크 관련 I / O에 대해 비용을 청구합니다.
대역폭
일부 클라우드 공급자는 서버 인스턴스 간의 네트워크 활동에 대해 요금을 부과합니다.
이는 API와 세션 저장소가 별도의 인스턴스라는 것이 거의 확실하기 때문에 적용됩니다.
세션 저장소 클러스터링
비용은 앞서 언급 한 모든 비용을 더욱 증가시킵니다.
사용자 인증을 위해 JWT와 토큰 + 캐시 중에서 비슷한 질문을했습니다.
이 기사를 읽은 후 JWT가 약속하는 이점이 그것이 가져 오는 문제를 능가하지 못한다는 것이 분명합니다. 그래서 token + cache (Redis / Memcached)가 저를위한 방법입니다.