Learn-json-web-tokens: README의 위험하고 잘못된 정보

일부 사람들은 리포지토리를 보기 시작한지 ​​얼마 되지 않은 사람으로서 생각할 거리를 확실히 제공하고 있는 우려 사항을 잘 생각하고 명확하게 표현했습니다. Node.js로 JWT 인증 작업 예제를 만드는 빠른 예제를 찾고 있었습니다. JWT에 대한 저의 관심은 CORS 문제를 피하면서 REST API 및 js 클라이언트 모두에 대한 세션 관리에 대한 최신 모범 사례 접근 방식을 제공하는 것입니다. 나는 보안에 약간 관심이 있지만 이것은 OAUTH와 같은 보다 포괄적인 보안 접근 방식에서 토큰이 할 수 있는 역할에 감사하지만 JWT를 사용하는 동기는 아닙니다. 이 리포지토리를 처음 읽었을 때 JWT 사용 등에 대한 지식을 쌓으면서 저자가 수집한 많은 메모가 포함되어 있는 것처럼 보였습니다. 이 리포지토리에 대한 투자는 거의 없지만 일부 지원 도구, 참조와 함께 플랫폼별, 로그인/로그아웃의 최소한의 작업 예제를 위한 장소입니다. 온보딩 기술의 기초로서 그리고 초보자로서 저는 이 리포지토리의 목표가 좋다고 생각하지만 아마도 README는 이러한 유형의 JWT 사용 목적에 대해 진지하게 다시 작성하고 다시 집중해야 할 필요가 있을 것입니다. 뭔가 제안하려고 하면 기쁩니다 .. joepie91 - 당신은 분명히 문제를 잘 이해하고 있습니다 .. 이런 종류의 JWT 사용의 진정한 이점이 실제로 무엇인지에 대한 몇 가지 생각을 제공할 수 있습니까?

안녕하세요 @joepie91님 , 우리는 JWT에 대한 우리의 노트를 _읽고_ 발견한 _stoked_입니다!
시간을 내어 이 문제를 열어 우려 사항을 제기해 주셔서 감사합니다. ❤️
귀하의 우려 사항을 _별도의_ 문제로 나누거나 최소한 번호를 매겨 논의하기 쉽도록 해주시면 _기쁩니다_.

우리는 이 메모의 내용이 "_Dangerous_"라는 것에 _정중히_ 동의하지 않습니다 .

_ 쿠키 _ > EU ePrivacy 지침 Recital 25 , cookies _ 명시적으로 _ 5번

보다:
https://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electronic_Communications#Cookies
또는:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX :32002L0058:EN:HTML

물론 _많은_ 웹사이트/앱(_타사 추적 쿠키 를 사용하지 않음_)은 ‘strictly necessary for the delivery of a service requested by the user’ ...에 속합니다. 이것이 쿠키 를 https://github.com/dwyl/hapi-auth-jwt2#want -to-sendstore-your-jwt-in-a-cookie

우리가 세션 데이터를 저장하는 /에 토큰 것을 _agree_ 동안 _> _localStorage에 JWT를 저장 localStorage 자바 스크립트를 _required 있음을 의미 _we 우리는 점진적 개선을 선호 하나 같이하지 않습니다 (_, 이것은 다른 옵션을주의하는 의미되었다 ..._). localStorage 는 BaaS가 일반적으로 쿠키를 허용하지 않기 때문에 "_Backend-as-a-Service_"로 구축된 _ 모든 _ 애플리케이션이 만들어지는 방법입니다... Google Firebase를 사용하는 50만 개발자가 그것을 "_잘못_"하고...? (_이것은 훌륭한 - 별도의 토론이 될 것입니다...!_)

상태 비저장 세션 은 기본 제공 exp (_만료 시간 _) 옵션이 있기 세션 ID ( jti ) _inside_ Redis 스토어에서 조회되는 JWT 는 JWT가 검증된 _후_입니다. 즉, 사용자가 로그아웃하거나 장치를 도난당하여 활성 세션을 취소해야 하는 경우 세션을 _ 무효화 _할 수 있습니다.

예, JWT의 _primary_ 목적은 pass claims between parties in web application environment 하는 것입니다. 바로 이것이 우리가 JWT를 사용하는 _정확히_입니다.

세션 ID 또는 토큰은 단순히 서버 측에서 검사되는 임의의 문자열일 수 _수 있지만_ JWT를 사용하여 세션 데이터를 _형식_ 및 _서명_하기로 _결정_했습니다.

결론: readme를 _clarify_로 업데이트합시다. 👍

@nelsonic 이 제안한 대로 제기된 문제를 일련의 문제로 분할하기보다는 구현의 의도와 목적이 README의 범위에서 명확해야 한다는 데 동의하는 경향이 있습니다. 나는 @joepie91 의 문제를 웹 애플리케이션의 맥락에서 JWT 사용에 대한 비판이나 쿠키 지원이 우월하다고 읽지 않습니다. 오히려 JWT에 대한 설명이 JWT를 선택한 이유를 과장하거나 잘못 표현하는 방식으로 제시된다는 비판을 받습니다.
#55(JWT가 암호화가 아님을 명확히 하세요...)에도 같은 우려가 나타납니다.

저에게는 만료되는 공통 클레임을 사용하여 Firebase와 자체 서비스를 운영할 수 있으면 충분합니다. 어떤 경우에는 일부 상태를 포함하도록 확장할 수 있고 다른 경우에는 포함하지 않을 수 있으며 여전히 쿠키 또는 이전 액세스 제어 http 인증 방식을 사용하는 방식을 선호합니다.
보다 정교한 접근 방식의 일부로 JWT 토큰을 사용할 수 있다는 점이 마음에 들지만 여전히 README의 이점에 초점을 맞추는 것이 덜 견고한 기반을 벗어나지 않고 해결하려는 문제에 초점을 맞춰야 한다는 데 동의합니다. README에 있는 참조 자료의 대부분은 토론 자료로 메모나 Wiki로 분류될 수 있습니까?

README가 위험하다고 필연적으로 말할 수 있을지 모르겠습니다. 약간 강한 것 같습니다.

쿠키 > EU ePrivacy 지침 Recital 25에서 쿠키가 명시적으로 5번 언급되었습니다.

죄송합니다. 제가 다소 모호하게 표현한 것 같습니다. 텍스트에 "쿠키"라는 단어가 여러 곳에 포함되어 있지만 입법화해야 할 특정 개념으로 식별되지는 않습니다. 오히려, 그것은 예시로 제공됩니다(따라서 내 요점의 나머지 부분은 여전히 ​​적용 가능하며 "쿠키를 사용하지 않음"은 동의의 필요성을 마술처럼 제거하지 않습니다).

localStorage는 BaaS가 일반적으로 쿠키를 허용하지 않기 때문에 "Backend-as-a-Service"로 구축된 모든 애플리케이션이 만들어지는 방식입니다...

이것은 관련이 없으며 해당 서비스의 문제입니다. 그것은 당신의 애플리케이션에서 세션에 JWT를 사용하는 것을 정당화하지 _않습니다_.

Google Firebase를 사용하는 50만 명의 개발자가 "잘못"하고 있다고 제안하는 건가요...?

Firebase가 극도로 열악하게 엔지니어링되었다는 사실을 제외하고, 이것은 권위에 호소하는 것이며 기술 토론에서 설 자리가 없습니다. 특정 제품에 대한 특정 회사의 결정에 대해 논의하는 데 관심이 없습니다. 주어진 접근 방식의 장점과 단점을 논의하는 데만 관심이 있습니다.

Stateless 세션은 내장된 exp(만료 시간) 옵션이 있기 때문에 JWT에서 가능하지만, 우리는 세션을 상태 비저장으로 만들지 않고 대신 JWT 내부에서 조회되는 세션 ID(jti)를 저장하도록 선택/선호합니다. JWT가 확인된 후 Redis 저장소입니다. 즉, 사용자가 로그아웃하거나 장치를 도난당하여 활성 세션을 취소해야 하는 경우 세션을 무효화할 수 있습니다.

이 시점에서 더 이상 JWT를 사용하면 실질적인 이점이 없습니다. express-session 또는 스택에 맞는 다른 전투 테스트 및 동료 검토 세션 솔루션을 사용하지 않는 이유는 무엇입니까? JWT에 대한 권장 사항은 여기에서 의미가 없습니다. 왜냐하면 사람들은 _처음부터 자신의 세션 관리를 실행해서는 안 되기 때문입니다.

세션 만료는 _서버 측_ 처리해야 하므로 JWT의 exp 는 본질적으로 쓸모가 없습니다.

예, JWT의 주요 목적은 웹 애플리케이션 환경에서 당사자 간에 클레임을 전달하는 것입니다. 이것이 바로 우리가 사용하는 것입니다.

JWT는 "웹 애플리케이션 환경"과 조금도 관련이 없습니다.

세션 ID 또는 토큰은 단순히 서버 측에서 확인되는 임의의 문자열일 수 있지만 JWT를 사용하여 세션 데이터를 형식화하고 서명하기로 결정했습니다.

다시 말하지만 스택에 대해 전투 테스트를 거친 세션 구현을 사용하십시오. 여기서 JWT는 잘못된 권장 사항 입니다.

우리는 이 메모의 내용이 "위험하다"는 점에 정중하게 동의하지 않습니다.

당신은 동의하지 않을 수 있지만 그것이 바로 그것입니다. JWT를 잘못 사용하는 방법은 너무 많습니다. 이 중 몇 가지는 이 저장소의 README에 의해 언급되어 있습니다. 네, 해롭습니다.

@pscott-au: joepie91 - 당신은 분명히 문제를 잘 이해하고 있습니다 .. JWT의 이러한 종류의 사용의 진정한 이점이 실제로 무엇인지에 대한 몇 가지 생각을 제공할 수 있습니까?

Reddit 규모로 실행하지 않는 한 표준 웹 애플리케이션에 JWT를 사용하면 이점이 없습니다. JWT가 유용한 경우의 몇 가지 일반적인 예:

• Single Sign-On 메커니즘(JWT가 대상 애플리케이션의 세션에 대해 사용자가 교환하는 일회성 인증 토큰으로 사용되는 경우),
• URL을 공유할 수 있는 비공개 이미지에 대한 임시 액세스 토큰,
• 기본적으로 서로를 신뢰하는 두 시스템이 서로 직접 접촉하거나 백엔드를 공유하지 않고 신뢰할 수 없는 당사자를 통해 약간의 데이터를 교환해야 하는 모든 시나리오입니다.

표준 웹 애플리케이션 세션의 경우 사용 중인 스택에 대해 잘 테스트된 세션 구현을 사용해야 합니다(예: Express를 사용할 때 express-session ).

내 경험의 일부에 실제로 도전하기 때문에 이 토론을 하는 것이 좋습니다. 아마도 JWT 사용에 대한 개인적인 관심에 대한 몇 가지 맥락일 것입니다(내가 조사할 열악한 엔지니어링 문제를 배우는 데 관심이 있는 Firebase를 사용한다는 사실을 제외하고). 모바일 앱/SPA를 만들 때, 특히 여러 서버/도메인에서 제공되는 서비스를 사용할 때 JWT가 잘 어울리는 단일 사인온 기능이 필요한 경우가 많습니다. 내 이해는 브라우저와 JS 공간에서 보안이 강화되고 CORS의 도입이 이에 대한 예외를 처리하도록 진화한 기간 동안 세션 쿠키의 사용이 진화했다는 것입니다. .
수년 동안 쿠키 세션 접근 방식은 원래 기본 및 다이제스트 http 인증보다 훨씬 더 나은 접근 방식을 제공했으며 웹 기반 앱에 쿠키 세션 관리 솔루션을 사용하는 경우가 많습니다.
하지만 .. 지금 만들고 있는 대부분의 앱은 모바일 또는 SPA이며 REST API를 많이 사용합니다. 쿠키 처리 항목을 묶거나 세션을 설정하기 위한 여러 요청을 처리하지 않고 간단한 컬 요청으로 쉽게 테스트할 수 있는 것을 좋아합니다. 그래서 JWT를 사용할 때만 작동하는 API를 빠르게 구현한다는 것을 알게 되었습니다. 내 직감으로는 JWT를 쿠키보다 오래 실행하는 세션에 사용하는 것이 더 적절하다고 생각하지만 좋은 직관보다 게으름일 수 있으므로 이에 대해 반추하겠습니다. 필요한 경우 OAUTH 라인을 따라 보안을 확장할 수 있으며 더 철저하게 보안을 유지하고 싶지만 세션이 이 수준의 보안이 필요하다고 판단되는 것이 아닌 경우가 많습니다. 나에게 중요한 것은 JWT 기반 인증 접근 방식이 향후 아키텍처 변경과 관련하여 제공하는 유연성입니다. JWT 인증을 옵션으로 제공하기 위해 이전 코드가 리팩터링되었으며 이로 인해 유지 관리 복잡성이 놀라울 정도로 거의 없었지만 대부분의 경우 향후 개발이 간소화되었으며 쿠키 세션보다 본질적으로 열등한 부분이 보이지 않습니다.
사실 특히 모바일 장치에서 JWT 시간 제한 기능을 사용하면 이점이 있으며 일부 지원 라이브러리에서는 이를 사용합니다. 예를 들어 장치가 네트워크에 연결되어 있지 않을 때 이 시간 제한을 기반으로 앱에서 사용자를 로그아웃시키거나 로그인 상태로 둘 수 있습니다.
저에게는 세션 쿠키에 비해 JWT의 확장성 이점에 대한 설득력 있는 주장이 별로 없습니다.
쿠키에는 자체 시간 초과 기간(완전히 관리되는 서버 측이 아님)이 있기 때문에 JWT를 세션 쿠키로 사용할 수 있고 이 쿠키를 결합하면 혼란스러울 수 있다고 제안하는 사람들이 있습니다.
많은 최신 JS 프레임워크는 쿠키보다 JWT에 대한 지원을 더 많이 제공하고 있습니다. 이는 스택에 대해 테스트를 거친 동료 검토 솔루션이 실제로 많은 애플리케이션에서 JWT를 지향할 수 있음을 시사합니다. 웹 서비스에 대한 JWT의 인기는 기술적인 논쟁이 아니지만, 모든 것이 똑같이 잘못된 것이기 때문에 관련이 없다고 무시하는 것입니다. Express는 내가 아는 한 dwyl 그룹에서 사용하는 스택의 핵심 요소가 아니므로 이에 맞출 이유가 없습니다.
나는 여전히 우려하고 있지만 당신의 주장에 완전히 확신하지 못하기 때문에 당신이 동의할 수 있는 내 의도의 일부가 있기를 바랍니다.
나는 README에 심각한 점검이 필요하고 주요 README가 아닌 배경 토론 텍스트로 더 잘 제거되거나 뒤로 밀려나는 라인이 있다는 데 동의할 것입니다.

(내가 조사할 열악한 엔지니어링 문제를 배우는 데 관심이 있는 Firebase를 사용한다는 사실을 제외하고)

문제 중 일부는 JS 클라이언트 라이브러리가 비공개 소스이고 다소 도움이 되지 않는 오류 출력으로 난독화되어 있으며 "배열"과 같은 것이 없으며 클라이언트 라이브러리에 응답을 받지 못할 수 있는 이상한 버그가 많이 있다는 것입니다. 불명확한 이유, ACL 시스템은 자체 편집기에서도 지원하지 않는 비표준 JSON 변형을 사용하고 JS API는 일반 콜백 API가 아닌 의사 이벤트 API를 사용해야 합니다(그러나 일관되게 작동하지 않음). 곧.

모바일 앱/SPA를 만들 때, 특히 여러 서버/도메인에서 제공되는 서비스를 사용할 때 JWT가 잘 어울리는 단일 사인온 기능이 필요한 경우가 많습니다. 내 이해는 브라우저와 JS 공간에서 보안이 강화되고 CORS의 도입이 이에 대한 예외를 처리하도록 진화한 기간 동안 세션 쿠키의 사용이 진화했다는 것입니다. .

정확하지 않습니다. 애플리케이션과 타사 API는 인증 요구 사항이 다르며 서로 다릅니다. 토큰 기반 인증 시스템은 타사 API와 통신할 때 응용 프로그램에서 의미가 있을 수 있지만 SPA인 경우에도 자체 응용 프로그램에는 의미가 없습니다. 이는 동일한 로그인 서비스를 사용하는 여러 최종 사용자 서비스를 나타내는 "싱글 사인온"과도 관련이 없습니다.

CORS는 별도의 문제이며 실제로 이와 관련이 없습니다.

하지만 .. 지금 만들고 있는 대부분의 앱은 모바일 또는 SPA이며 REST API를 많이 사용합니다. 쿠키 처리 항목을 묶거나 세션을 설정하기 위한 여러 요청을 처리하지 않고 간단한 컬 요청으로 쉽게 테스트할 수 있는 것을 좋아합니다. 그래서 JWT를 사용할 때만 작동하는 API를 빠르게 구현한다는 것을 알게 되었습니다.

개발 중에는 특정 테스트 요구 사항이 있을 수 있지만 이러한 요구 사항은 프로덕션에서 취하는 접근 방식에 영향을 주지 않습니다. SPA인 대부분의 것들이 처음부터 SPA가 되어서는 안 된다는 사실을 제외하고(SPA는 웹사이트가 아니라 웹앱을 위한 것입니다!), 세션을 사용할 수 없는 이유는 없습니다.

그 외에도 cURL은 쿠키를 잘 지원하며 httpie 또는 http-prompt 와 같은 더 나은 API 테스트 클라이언트가 많이 있습니다.

필요한 경우 OAUTH 라인을 따라 보안을 확장할 수 있으며 더 철저하게 보안을 유지하고 싶지만 세션이 이 수준의 보안이 필요하다고 판단되는 것이 아닌 경우가 많습니다.

세션은 애플리케이션의 가장 중요한 측면 중 하나입니다. 충분히 안전하지 않으면 애플리케이션이 본질적으로 손상되고 완전히 취약합니다. 그렇기 때문에 예를 들면. LocalStorage에 JWT를 저장하는 것은 끔찍한 생각입니다.

나에게 중요한 것은 JWT 기반 인증 접근 방식이 향후 아키텍처 변경과 관련하여 제공하는 유연성입니다. JWT 인증을 옵션으로 제공하기 위해 이전 코드가 리팩터링되었으며 이로 인해 유지 관리 복잡성이 놀라울 정도로 거의 없었지만 대부분의 경우 향후 개발이 간소화되었으며 쿠키 세션보다 본질적으로 열등한 부분이 보이지 않습니다.

여기에는 99.99%의 개발자가 필요로 하는 유연성이 도입되지 않았으며, 이미 부실 데이터 및 토큰 무효화 불가능과 같이 도입되는 문제 중 일부를 강조했습니다.

사실 특히 모바일 장치에서 JWT 시간 제한 기능을 사용하면 이점이 있으며 일부 지원 라이브러리에서는 이를 사용합니다. 예를 들어 장치가 네트워크에 연결되어 있지 않을 때 이 시간 제한을 기반으로 앱에서 사용자를 로그아웃시키거나 로그인 상태로 둘 수 있습니다.

이것은 JWT에만 해당되는 것은 아닙니다. 서버 측 세션으로 이 작업을 수행할 수 있습니다. 사실, JWT는 (복잡한) 상태 저장 아키텍처를 도입하지 않고는 무효화될 수 없으므로 세션이 실제로 여기에서 승리합니다.

저에게는 세션 쿠키에 비해 JWT의 확장성 이점에 대한 설득력 있는 주장이 별로 없습니다.

확장성 이점은 모든 세션을 보유하는 단일 정식 서버가 필요하지 않다는 것입니다(데이터를 토큰에 직접 저장할 수 있기 때문에). 즉, 병목 현상을 제거할 수 있습니다. 그러나 내가 말했듯이 거의 어떤 개발자도 실제로 이 문제를 겪지 않을 것입니다. 매우 큰 규모의 프로젝트에만 유용합니다.

많은 최신 JS 프레임워크는 쿠키보다 JWT에 대한 지원을 더 많이 제공하고 있습니다. 이는 스택에 대해 테스트를 거친 동료 검토 솔루션이 실제로 많은 애플리케이션에서 JWT를 지향할 수 있음을 시사합니다.

세션 쿠키를 지원하지 않는 프레임워크는 아직 보지 못했습니다.

Express는 내가 아는 한 dwyl 그룹에서 사용하는 스택의 핵심 요소가 아니므로 이에 맞출 이유가 없습니다.

그것이 그들의 문제입니다. Express는 하나의 예일 뿐이며 기본적으로 일반적으로 사용되는 모든 프레임워크에 대해 잘 테스트된 세션 구현이 존재합니다.

결론은 이 리포지토리를 읽고 있는 모든 개발자에게 JWT의 실제 이점은 정확히 0이고 몇 가지 단점이나 보안 문제가 있다는 것입니다. 그것은 단지 건전한 기술적인 선택이나 권장 사항이 아니며, 그것으로 정말 끝입니다.

@joepie91 나는 당신이 우리의 리포지토리/노트를 찾았고 그것을 읽고 피드백을 주기 위해 시간을 투자했다는 것에 얼마나 _기뻐_했는지 말할 수 없습니다! 진심으로, 내가 당신을 직접 만나면 당신이 좋아하는 음료의 _팔레트_를 줄 것입니다! 🍺

내가 당신을 이 리포지토리의 기고자로 만들면 _개선_을 위한 내 끌어오기 요청을 검토하시겠습니까? 📝

또한 @AshleyPinner , @alfiepates , @sunny-g _여러분_ 여러분은 이 _특정_ 토론을 어떻게 우연히 발견했습니까? Redit/Hackernews에서 문제가 공유되었습니까? (_사람들이 우리 게시물을 어떻게 찾는지 궁금합니다..._)

나는 며칠 동안 이것을 씹어 보았고 현대 SPA 및 모바일 앱의 기존 세션 쿠키보다 JWT를 기본 선택으로 사용하는 것에 반대하는 많은 논쟁에 참여할 수 없습니다.
특정 요구 사항에 대한 쿠키/JWT 인증 접근 방식의 장단점을 평가하기 위해 결정 매트릭스를 구성하거나 README를 다시 작성하기 전에 일련의 사용 사례에 걸쳐 장단점을 자세히 설명하려고 했습니다. 복잡한 앱을 구축할 때 사람들이 직면하는 많은 실제 문제는 대부분 덜 우아하게 해결되거나 최소한 쿠키 세션을 사용하여 문제가 있는 것 같습니다. 문제 포스터가 만드는 인식은 JWT가 최신 앱에 적합하지 않은 일부 해킹된 신뢰할 수 없는 미성숙 기술이며 이 주장은 아마도 사용자를 인증하기 위해 완전히 작동하는 예제를 제공하는 것보다 훨씬 더 위험할 수 있다는 것입니다.
이 OATH 기사가 도움이 되었습니다 . 나는 이 리포지토리에 대한 강력한 반응을 촉발한 것 중 하나라고 생각하지만 문제 보고자는 JWT를 사용하는 쿠키 세션에서 일반적으로 예상되는 기능에 대한 논의로, 주로 JWT의 핵심 이점을 손상시킵니다. 무국적자가 될 수 있습니다. 영구 저장소를 통합하여 상태를 도입하십시오. JWT의 주요 사용 사례 중 하나를 제거하고 쿠키를 사용하여 성숙한 것을 다시 구현합니다.
즉, 복잡한 앱은 단일 HTTP 요청의 수명을 넘어서 처리되는 작업에 대한 트랜잭션 요청의 경우에도 일부 상태 찾기를 요구하는 경향이 있습니다. 이것은 JWT의 사용을 배제해서는 안 되지만 JWT가 트랜잭션에서 어떤 역할을 하는지 고려할 수 있도록 잠시 멈춰야 합니다. 리소스에 대한 액세스 권한을 부여하는 JWT와 서비스에 대한 액세스를 거부하는 사용자에 대한 리소스 상태가 있는 것이 괜찮다고 생각합니다. 이 경우 만료되어야 하는 것은 JWT가 아니라 JWT를 사용하여 서비스에 액세스하는 사용자의 상태입니다.

전송 메커니즘으로 쿠키를 사용하도록 추가로 확장하면 다른 이점이 제거되고 쿠키를 다시 사용하게 되지만 일반적인 라이브러리 기능을 무시하고 처음부터 기능을 다시 작성하여 중복 시간 초과 등으로 끝나기 때문에 모호성이 더 생깁니다. 앞서 CORS에 대해 언급했을 때 아마도 쿠키와 함께 여러 도메인을 사용하는 어려움을 지적하는 것이 더 나을 것입니다. 물론 와일드카드 도메인을 설정할 수 있지만 충분히 다른 경우 기존 세션 쿠키가 빠르게 다루기 어려워집니다. 대부분의 개발자는 여러 도메인의 보호된 리소스에 액세스하기 위해 인증된 클라이언트가 필요하지 않다고 주장할 수 있지만 이는 특이한 경우보다는 훨씬 더 일반적인 관행이 되고 있습니다.
인증된 세션 관리를 탐색하기 시작하는 새로운 사람으로서 나는 이것이 웹 앱의 리소스에 대한 액세스를 인증된 사용자에게 가장 간단한 의미로 제한하는 방법에 대해 배우는 적절한 방법이 아닐 수 있다는 점에 감사합니다. JWT는 인증된 세션의 출발점으로 더욱 부각될 것이므로 세션 쿠키를 오랫동안 사용해왔기 때문에 이를 무시하는 것만으로는 모든 사람이 세션 쿠키로 시작하고 JWT에 대해서만 배우고 사용해야 한다고 믿기에는 충분하지 않습니다. 도메인 간에 쿠키를 공유할 수 없거나 타사 API에 액세스해야 하거나 서버를 확인하지 않고 만료를 확인할 수 있어야 하거나 모바일 장치 등에 사용자 로그인 자격 증명의 저장에 대해 질문할 때 .

상위 계층의 인신매매 사이트를 운영하지 않는 한 상태 비저장 토큰의 이점을 무의미한 것으로 과소평가하는 것은 옳지 않습니다. 새로운 상태 계층을 도입하여 문제를 복잡하게 만들더라도 서버에서 세션을 분리하면 많은 이점이 있습니다.

@nelsonic 4744cd1bb8991bc4057c749f86007fcecac19d1d를 보면 훨씬 더 명확한 표현처럼 보입니다. 그러나 헤더 는 변경 사항을 반영하지 않는 것 같습니다.

@pscott-au: 최신 SPA 및 모바일 앱에서.

이것은 세션 메커니즘의 선택과 _완전히_ 직교합니다. 오늘날 SPA인 대부분의 것들이 그렇지 않아야 한다는 것은 말할 것도 없습니다. 웹 사이트에 SPA를 사용하면(웹 앱과 반대) 웹이 중단됩니다.

복잡한 앱을 구축할 때 사람들이 직면하는 많은 실제 문제는 대부분 덜 우아하게 해결되거나 최소한 쿠키 세션을 사용하여 문제가 있는 것 같습니다.

와 같은?

문제 포스터가 만드는 인식은 JWT가 최신 앱에 적합하지 않은 일부 해킹된 신뢰할 수 없는 미성숙 기술이라는 것입니다.

아니요, 그렇지 않습니다. 기술로서의 JWT는 끔찍하지 않습니다(사양에 의심스러운 결정이 _are_ 있더라도). 세션은 의도된 목적이 아니며 해당 사용 사례에 적합하지 않습니다.

도구가 나쁘다는 것이 아니라 잘못 사용하고 있다고 말하는 것입니다.

이 주장은 아마도 다음보다 훨씬 더 위험할 것입니다.

그것에 대한 당신의 근거는 무엇입니까?

이 OATH 기사가 도움이 되었습니다.

요점별로 해결:

• Stateless, Scalable and Decoupled: 나는 이것이 이론적 이점이지만 실제로는 거의 아무도 실제로 필요로 하지 않는 이점이라는 것을 이미 인정했습니다. 또한 Auth0에 기득권이 있다는 점을 고려해야 합니다. 이 이익은 개발자에게 _not_ 도움이 되지 않습니다. _"Auth0과 같은 타사 서비스는 토큰 발행을 처리할 수 있으며 서버는 토큰의 유효성만 확인하면 됩니다. "_ 인증을 아웃소싱하는 것은 _끔찍한_ 아이디어입니다.
• 교차 도메인 및 CORS: 완전하고 말도 안되는 소리입니다. 이것은 토큰이 세션 데이터를 _포함하는지 여부와 완전히 별개인 _저장 방법_에 대해 이야기합니다. 세션 ID를 수동으로 보내거나 JWT를 쿠키에 저장할 수 있습니다. JWT 대 세션과는 아무 관련이 없습니다. "쿠키 대 토큰"을 비교하는 것은 _처음부터 의미가 없기 때문에 기사 작성자의 편견/무지를 보여줍니다. 또한 이 보안 문제를 완전히 무시
• JWT에 데이터 저장: 기능이 아닙니다. 세션에도 동일하게 적용됩니다. 그건 그렇고, 쿠키.
• 성능: 이것은 "상태 비저장" 지점의 반복일 뿐입니다. 대부분 - 암호화 검증이 세션 데이터 처리 성능에서 Redis와 같은 것을 능가할 수 있는지 여부가 _전혀_ 분명하지 않다는 사실을 제외하고(RDBMS와의 비교는 비현실적입니다) , 또한 거의 모든 웹 앱에 대해 완전히 미미한 성능 최적화입니다. 이것을 "조기 최적화"라고 하며 매우 타당한 이유로 널리 권장되지 않습니다.
• 모바일 지원: 말도 안되는 소리. HTTP 라이브러리가 쿠키를 지원하지 않으면 _더 나은 HTTP 라이브러리를 찾으세요_. 쿠키는 잘 지원되며 HTTP 헤더일 뿐입니다.

아니요, 그 기사는 내가 아직 다루지 않은 JWT의 새로운 이점을 가져오지 않습니다. 그것은 때때로 이익(무국적자)을 모든 애플리케이션에 적용되는 것으로 잘못 표현하고(그렇지 않음), 무의미한 비교를 하고 나머지 세션 성능을 과도하게 강조합니다.

나는 이 리포지토리에 대한 강력한 반응을 촉발한 것 중 하나라고 생각하지만 문제 보고자는 JWT를 사용하는 쿠키 세션에서 일반적으로 예상되는 기능에 대한 논의로, 주로 JWT의 핵심 이점을 손상시킵니다. 무국적자가 될 수 있습니다.

내가 말했듯이, 이것은 실제로는 거의 이득이 되지 않습니다. 동일한 무국적 상태를 계속해서 반복할 수 있지만 더 이상 유효하거나 적용 가능하지 않습니다. 그것은 _절대적으로 아닙니다_ 범용 요구 사항입니다.

리소스에 대한 액세스 권한을 부여하는 JWT와 서비스에 대한 액세스를 거부하는 사용자에 대한 리소스 상태가 있는 것이 괜찮다고 생각합니다. 이 경우 만료되어야 하는 것은 JWT가 아니라 JWT를 사용하여 서비스에 액세스하는 사용자의 상태입니다.

이 경우 일종의 일반 세션 ID에 비해 이점이 없습니다.

[...] 앞서 CORS에 대해 언급했을 때 쿠키와 함께 여러 도메인을 사용하는 것의 어려움을 명시적으로 지적하는 것이 더 나았을 것입니다. 물론 와일드카드 도메인을 설정할 수 있지만 충분히 다른 경우 기존 세션 쿠키가 빠르게 다루기 어려워집니다.

이것은 또한 요점과 완전히 직교합니다. 이것은 순전히 식별자가 세션 데이터를 _포함_했는지 여부가 아니라 식별자를 _저장_하는 위치에 관한 것입니다. 그리고 다시, 보안 위험 .

그러나 JWT의 사용은 인증된 세션의 시작점으로서 더욱 두드러질 것입니다.

그리고 그 두드러진 사용은 무지와 과대 광고에 기반을 두고 있으며 많은 보안 문제를 수반하기 때문에 그것이 저를 크게 우려합니다. 이것은 중요한 후퇴입니다.

그래서 우리는 오랫동안 세션 쿠키를 사용했기 때문에 이것을 무시합니다.

나는 그런 종류의 말을 한 적이 없습니다. 세션 관리에서 JWT가 _객관적으로 열등한 이유에 대해 몇 가지 _매우__명확한 이유를 제공했습니다.

도메인 간에 쿠키를 공유할 수 없는 경우에만 JWT에 대해 배우고 사용합니다.

이 경우 보안 문제 . 쿠키는 _선택 사항이 아닙니다_.

또는 타사 API에 액세스해야 하는 경우

세션과 관련이 없습니다.

또는 서버를 확인하지 않고 만료를 결정할 수 있어야 합니다.

서버가 세션을 명시적으로 무효화하는 기능을 유지해야 하기 때문에 불가능합니다. 사용자가 비밀번호를 변경하거나 다른 세션을 강제로 닫을 때.

또는 모바일 장치 등에 사용자 로그인 자격 증명의 저장에 대해 질문하십시오.

쿠키. 완료.

상위 계층의 인신매매 사이트를 운영하지 않는 한 상태 비저장 토큰의 이점을 무의미한 것으로 과소평가하는 것은 옳지 않습니다. 새로운 상태 계층을 도입하여 문제를 복잡하게 만들더라도 서버에서 세션을 분리하면 많은 이점이 있습니다.

그러나 당신은 내가 아직 다루지 않았고 내 결론에서 고려하지 않은 것들에 대해 언급하지 않았습니다. 죄송합니다. 그러나 당신은 새로운 접근 방식을 위해 새로운 접근 방식을 옹호하고 있으며 다른 접근 방식의 _객관적, 기술적 속성_을 완전히 무시하고 있습니다.

그것이 "과대 광고"라고 불리는 것이며 매우 해롭습니다.

Stateless: 앱이 오프라인으로 작동하고 어떤 종류의 의미를 유지해야 할 때 중요합니다.

오프라인 애플리케이션은 인증이 _전혀_ 필요하지 않습니다. 정의상 다른 시스템과의 상호 작용은 없습니다.

교차 도메인 자격 증명 인증: 여러 서버를 사용하여 애플리케이션을 마이크로서비스로 분할하는 경우 중요

옳은. 그러나 이 경우 JWT를 _세션 메커니즘으로_ 사용하지 않고 세션에 대해 _교환_할 수 있는 일회용 토큰으로 사용합니다. 이 둘 사이에는 매우 큰 차이가 있으며 그것이 제시하는 절충안이 있습니다.

( 편집 : 물론 이것은 _stateful_ 마이크로 서비스를 가정하고 'stateful'을 사용하면 세션이 아니라 서비스 자체를 참조하는 _입니다. 상태 비저장 작업을 수행하는 마이크로 서비스의 경우 세션을 전혀 사용하지 않고 _일회용 토큰으로 충분합니다. 애플리케이션 서버에서 일회용 토큰을 발행하는 경우 마이크로 서비스와 통신하는 애플리케이션 서버의 경우 JWT도 괜찮습니다. 여기에 "세션"이라는 개념이 없으며 서명 키를 변경하여 토큰 해지를 수행할 수 있습니다.)

JWT의 유용성을 계속 거부할 수 있습니다.

다시 말하지만, 나는 그런 일을 하지 않습니다. 이것은 전적으로 당신의 말씀입니다.

내가 더 자세한 정보를 제공하려고 할 때 당신은 내 사건을 부적절하거나 나쁜 관행으로 치부합니다. 제 생각에는 그렇게 잘못되었습니다.

그런 다음 "그게 틀리다!"라고 말하는 것이 아니라 _왜_ 잘못된 것인지 자세히 설명해 주시기 바랍니다. 그리고 내가 그것을 액면 그대로 받아들이기를 기대하십시오. 나는 당신이 정확하게 이 이유에 대해 제공하는 모든 요점을 구체적으로 언급하고 있습니다.

iOS 로그인 세션을 관리하기 위해 쿠키에 의존하는 것은 기본적으로 최상의 솔루션이 아닙니다.

왜요?

쿠키가 오용될 수 있습니다.

빈말입니다. 오용 _어떻게_? 그리고 이것이 어떻게 Local Storage에 저장된 값에 적용되지 않습니까? "쿠키"가 세션 메커니즘이 아니라 저장 방법이라는 점을 감안할 때 이것이 JWT와 _전혀_ 관련이 있습니까? "JWT 대 쿠키"를 비교하는 것은 사과와 오렌지를 비교하는 것입니다. 그들은 심지어 같은 부류가 아닙니다!

세션 관리를 위한 JWT의 사용은 쿠키 세션과 다르며 속성이 다릅니다. 이것은 열등하지 않지만 적절한 솔루션을 설계하는 데 있어 다른 운영 매개변수 기준을 가질 뿐입니다. 쿠키를 사용하려면 쿠키를 사용하십시오. - 요구 사항을 충족하는 경우 쿠키를 사용하십시오. - 다른 사람이 다른 접근 방식을 고려하지 못하도록 하는 이유는 무엇입니까?

난 아니에요. JWT가 올바른 솔루션인 경우 _매우 명확하게_ 표시된 예외가 있습니다. 나는 또한 JWT가 범용 세션 메커니즘

영구 저장소가 있는 웹 서버에 대해 인증하는 데만 가치가 있는 로그인 세션의 개념은 동일한 JWT의 유효성을 검사하고 새 쿠키를 만들 필요가 없는 대체 공급자가 제공하는 일부 데이터 서비스를 원할 수 있다는 사실을 무시합니다. . 이것은 어떤 면에서 세션과 관련이 없나요???

다른 목적으로 JWT와 세션을 _모두_ 사용할 수 없는 이유가 없기 때문입니다. 이를 위해 모든 것을 단일 메커니즘으로 구부리려는 것은 _완전히_ 잘못된 것입니다. 적절한 도구를 사용하십시오. "새 쿠키를 생성할 필요가 없음"은 완전히 임의적인 측정 기준이며 실제로는 귀하가 의미하는 이점이 아닙니다.

보안 문제가 보이면 이를 식별하고 플래그를 지정하십시오. 이러한 문제는 눈에 띄지 않을 수 있지만 결정을 내릴 때 알아두면 유용할 수 있습니다. 당신은 세션 쿠키가 모든 http 앱에 사용되어야 한다고 계속 주장하기 때문에 이것을 인정하지 않거나 가능성을 고려하지도 않습니다.

다시. 아니다. 나는 말했다. 내 입에 말 좀 그만 넣어.

암호 변경 시 종료와 같은 특정 규칙을 적용하거나 서비스 제한을 관리하기 위한 세션의 역할에 대해 언급한 예는 세션 쿠키의 내장 기능이 아니라 이 접근 방식에서 일반적으로 사용되는 기능일 뿐입니다.

이는 구조적으로 일종의 상태 저장 세션을 _필요로 하는_ 기능입니다. 나는 이것이 세션 쿠키에 의해 제공된다고 주장하는 것이 아닙니다. 나는 그것이 무상태 토큰으로 _불가능_하다고 주장하고 있습니다.

솔루션이 세션의 수명 동안 리소스에 액세스하기 위해 db를 확인하지 않고 인증된 액세스를 제공하는 것이 매우 편안하다면 이것이 이 접근 방식의 실패라고 주장하는 이유는 무엇입니까?

다시 말하지만, 내가 말한 것이 아닙니다.

특정 컨트롤(종료 가능한 세션이 필요한 경우)이 필요에 따라 도입될 수 있다고 제안할 때 쿠키에는 다른 접근 방식을 시도해서는 안 되는 내장된 기능이 있다고 응답합니다. 이러한 종류의 제어를 구현하는 것은 쿠키에 대한 JWT 인증 세션을 배제하는 것과 같은 심각한 오버헤드가 아닙니다.

요점은 오버 헤드가 아닙니다. 요점은 잘 작동하는 것으로 알려진 검증된 솔루션을 사용하는 것 입니다. 자신의 보안을 다시 구현하는 것은 _어떤_ 상황에서도 끔찍한 생각이며, 여기에는 이러한 상황이 포함됩니다.

쿠키에 대한 요청 수를 무시하고 유일한 성능 고려 사항은 조회라고 제안합니다. 새로 고침 등을 조정하고 ..에 의존해야 하는 필요성은 신경쓰지 마세요... (여기서 포기)

무슨 얘기를 하는 겁니까? 쿠키 "새로 고침"은 새 쿠키를 전송하여 HTTP 응답에서 인라인으로 처리됩니다. Redis 예제에서 이미 다룬 세션 저장소를 업데이트하는 것 외에 추가로 관련된 것은 없습니다. 다른 성능 고려 사항이 있다고 생각되면 _ 나열하십시오_.

쿠키가 도메인으로 제한되어 있고 도메인 간 사용을 허용하면 쿠키 사용을 방해하는 보안 문제가 발생한다고 생각할 수 있습니다. 괜찮습니다. 저는 그렇지 않습니다.

다시 말하지만, 내가 말한 것이 아닙니다.

JWT는 다음으로 모든 세션 쿠키를 대체하는 것은 아니지만 당신이 지적한 것처럼 (세션을 관리하는 데 사용되는 경우) 심각한 혐오스러운 것도 아닙니다.

예, 그렇습니다. 세션에 JWT를 사용하려는 유일한 이유는 대안이 더 나쁘거나 불가능하기 때문이며 이는 _매우_ 드문 경우입니다.

필요한 경우 이 접근 방식에 대한 다양한 개선 사항과 기존 세션 기반 접근 방식과 비교하여 진화의 복잡성에 대한 언급 없이 보안을 절대적인 것으로 취급합니다.

저는 보안이 절대적일 때만 절대적 보안을 _is_ 취급합니다. 나는 또한 그것을 해결할 수 있는 가능한 방법을 다루었고 _그리고_ 최종 결과가 여전히 더 나빴기 때문에 세션과 비교하여 좋은 솔루션이 아니라는 것을 설명했습니다. 내가 누락된 사례나 솔루션이 있다고 생각되면 언급하십시오. 실제로 무엇인지 설명하지 않고 "다른 옵션"을 막연하게 암시하지 마십시오. 지금 내가 말할 수 있는 한, 당신은 허세를 부리고 있습니다.

과장이 아님 - 무지에 근거한 것이 아니라 기술이 제공할 수 있는 가장 엄격한 보안을 제공하는 것을 목표로 하지 않는 서비스에 대해 교차 인증이 필요한 하이브리드 앱을 구축할 때 정기적으로 직면하는 문제에 대한 유효한 솔루션이며 타당한 이유가 있음 - 매우 실용적 - 매우 광범위함 채택 - 모든 것을 쓰레기로 만들지 않습니다.

당신의 주장을 반복한다고 해서 더 이상 사실이 되는 것은 아닙니다. 나는 이것이 왜 거짓인지 이미 다루었고 과대 광고를 이유로 보안을 타협하는 것은 용납

쿠키가 제공하는 것보다 더 세밀하게 세션을 제어할 수 있는 유연성이 있는 우리 중 일부에게는 더 큰 유연성을 제공합니다. 사용 사례가 보이지 않으면 괜찮습니다. 당신이 제시하는 몇 가지 요점에 대한 반론을 나보다 더 잘 표현할 수 있을 것입니다.

"더 큰 유연성"은 _is_ 없습니다. 다시 말하지만, 있다고 생각되면 방법을 설명하십시오.

어쨌든 - 당신은 나보다 훨씬 더 유창하고 당신의 입장에서 분명히 흔들리지 않습니다.

아니요. 누군가가 내 견해를 바꾸고 싶다면 견고하고 잘 논의되고 기술적으로 올바른 주장을 해주기를 기대합니다. 당신은 그렇게하지 않았습니다.

내가 마지막으로 접근 방식에 대해 그토록 끈질긴 애착을 갖고 있었던 것은 누군가 다이제스트 인증이 세션 쿠키로 대체되어서는 안 된다고 주장했을 때였습니다.

... 그리고 그것은 그러한 오류의 완벽한 예가 될 것입니다.

결론은 당신의 진술의 절반이 내가 결코 말하지도, 암시하지도, 의도하지도 않은 말을 내 입에 넣고 있다는 것입니다. 나머지 절반은 보안의 불필요한 타협을 주장하거나 더 이상 언급하지 않고 "다른 이점" 또는 "다른 솔루션"이 있다고 손으로 흔드는 주장을 합니다.

솔직히 말해서, 나는 이것에 지쳤습니다. 나는 이 토론이 건설적인 방향으로 갈 것이라고 생각하지 않으며, 그것은 실을 흐리게 만들고 있습니다. 내가 계속 응답하는 유일한 이유는 사람들이 당신의 논거가 아닌 것으로 인해 잘못된 정보를 받을 위험이 있기 때문입니다.

JWT가 그 개념을 뒷받침하는 기술적 논거가 없음에도 불구하고 계속해서 성배라고 믿고 싶다면 그것이 선택입니다. 그러나 _실제 기술적 논거를 제시하고 동일한 주장을 계속 반복하지 않는 한 _나를 설득하지 못할 것입니다. 그리고 다시는 누구에게도 도움이 되지 않을 것입니다.

전체 토론을 훑어보는 사람들을 위해 제 요점을 요약하자면 다음과 같습니다.

• JWT는 세션용으로 설계되지 않았지만 일반적으로 일회용으로 서명된 청구를 전송하기 위해 설계되었습니다.
• JWT는 토큰 무효화 불가능, 오래된 데이터 문제, 작동하도록 테스트되지 않은 구현을 작성해야 하기 때문에 세션에 적합하지 않습니다. 보안 문제입니다.
• "쿠키 대 JWT"는 유효한 비교가 아닙니다. 하나는 저장 메커니즘이고 다른 하나는 토큰 형식입니다. 쿠키는 JWT를 사용하는지 여부에 관계없이 _무관한_ 선택 사항 이 아닙니다. 쿠키 외부에 모든 종류의 토큰을 저장하는 것은 보안 문제입니다.
• 때때로 당신은 매우 큰 규모로 운영하고 있기 때문에 상태 저장 세션을 사용할 수 _없습니다_. 그런 경우 JWT는 '가장 덜 나쁜' 옵션이 될 수 _수_ 있습니다. 그러나 이러한 경우는 드물고, Reddit, 당신은 그들과 마주치지 않을 것입니다.

(그런데 Reddit은 상태 저장 세션을 사용합니다.)

이 리포지토리의 목적은 모바일 하이브리드 SPA 구현을 위한 길을 닦는 것이며 쿠키 세션을 대체하기 위해 JWT를 사용하는 것이 일반적이고 거의 표준적인 접근 방식이라고 생각합니다.
이에 대한 동인 중 하나는 SPA가 실제로 서로 다른 플랫폼의 여러 도메인에 있는 마이크로 서비스에 대한 액세스를 요구할 수 있는 경우 쿠키가 도메인에 바인딩되는 문제입니다. JWT는 이러한 맥락에서 쿠키의 한계에 대한 깔끔한 접근 방식입니다. OAUTH 또는 OAUTH2 접근 방식을 사용하면 보안 관점에서 더 강력하지만 많은 애플리케이션에 필요하지 않을 수 있는 복잡성이 도입됩니다. AUTH 토큰 협상에 의존하지 않는 JWT 전달자 세션은 JWT의 오용이 아니라 단순성을 얻기 위해 그리고 더 많은 보안이 제공하는 추가 보안보다 빠른 구현에서 더 많은 것을 얻을 수 있는 애플리케이션을 위해 덜 안전한 접근 방식을 적용하는 것입니다. 강력한 접근 방식. 신속한 구현을 간소화함과 동시에 다른 접근 방식보다 일회용 토큰으로 더 명확한 마이그레이션 경로를 제공합니다.
세션 쿠키를 대체하기 위해 JWT Bearer 토큰 헤더를 사용하는 것에 대한 일부 반발과 비판은 실제로 일부 사람들이 쿠키를 보다 광범위하게는 쿠키에 대한 진화 또는 개선으로 제시하는 것에 기반을 두고 있지만 사실이 아니라는 데 동의합니다. 제 사용 사례와 쿠키를 사용하여 접근하는 방법을 고려하시기 바랍니다.
인증 세션 관리를 위해 JWT를 사용하는 것은 주의해서 수행해야 하고 결함을 명시해야 하지만 컨텍스트에서 항상 사용되는 쓸모없는 과대 광고로 무시하는 것은 오해의 소지가 있고 잘못된 것입니다.
JWT를 사용하면 클라이언트가 서버에 접속할 때마다 쿠키를 새로 고칠 필요가 없습니다. 세션 쿠키를 사용하는 것처럼 이 검사를 확장하는 것이 쉽지만 데이터베이스를 검사하지 않고도 합리적인 확신을 가질 수 있습니다.
JWT를 사용한다는 것은 쿠키가 차단된 클라이언트가 숨겨진 게시물 변수 등을 백필로 사용하도록 강제로 대체되지 않는다는 것을 의미합니다.
여러 서비스에서 JWT를 사용하면 인증이 필요하지 않지만 JWT로 래핑되어 전달할 수 있는 uid와 같은 간단한 데이터 필드의 유효성에 대한 일부 표시를 원하는 서비스가 허용됩니다.
JWT 접근 방식은 보다 정교한 OAUTH 접근 방식에 적합합니다.
JWT REST 요청은 자격 증명을 게시하거나 REST/SPA 구현을 단순화할 수 있는 서비스에 액세스하기 전에 쿠키 요청을 요구하지 않고 만들 수 있습니다.
전달자 헤더 또는 쿠키 헤더를 사용하는 것은 보안과 관련하여 크게 다르지 않습니다. 보안이 더 나쁘다)
모바일 애플리케이션과 같이 장기간의 부재가 일반적이거나 예상되는 경우 쿠키는 JWT 접근 방식보다 덜 바람직할 수 있습니다. 자격 증명 자체 검사에 대한 더 명확한 경로가 있으면 서버에 체크인하지 않고도 동작을 용이하게 할 수 있습니다.
오프라인 기간이 길어질 수 있는 세션에 대한 사용 사례가 있음을 인정하면 세션이 반드시 상태 저장이 되지는 않습니다.
클라이언트와 서버의 관점에서 세션이 여러 상태로 성공적으로 존재할 수 있다는 것을 받아들일 수 있다면 아마도 서버와 장기간 연결되지 않는 기간을 포함하는 사용 사례에 더 가까이 다가갈 수 있습니다(예: 일괄 업데이트를 위해 사용자 데이터 수집 재연결 시). 세션이 만료되었고 새로 고침이 필요하다는 사실을 알고 클라이언트가 더 효과적으로 작동할 수 있는 경우 다른 데이터 계층을 관리하지 않아도 됩니다. 또한 비밀번호가 변경된 후에도 JWT를 세션 유효성 검사로 사용할 수 있다는 것은 데이터가 비즈니스 로직 계층에 전달되고 요청을 수락하는 방법을 결정하도록 하는 데 유용할 수 있습니다.
귀하는 쿠키가 브라우저 등의 구현을 암시하는 것으로 가정하는 안전하다고 계속 말씀하셨습니다. 브라우저 외부에서는 쿠키가 본질적으로 더 안전한 이유를 알지 못합니다. 자세히 설명할 수 있습니까?
SPA/하이브리드 앱에서 쿠키에 대한 의존이 반드시 유일한 시작 위치는 아닙니다. 브라우저에서 쿠키를 처리하는 것에 의존한다고 해서 네이티브에 가까워지는 것은 아니지만 UIWebView 또는 무엇이든 의존하게 되며 저는 항상 그럴 것이라고 확신하지 않습니다. 내 예상대로 행동하십시오.
토큰은 반드시 유지되지 않고 앱의 실행 수명 동안 메모리에 유지될 수 있습니다. 이는 실제로 쿠키의 무결성에 의존하는 것과는 다릅니다. iOS에는 최소한 브라우저 너머에 존재하는 저장 권한에 대해 더 세분화된 제어가 있습니다. 이것은 브라우저 스토리지 접근 방식에 구속되는 것보다 더 적절하다고 생각합니다.
쿠키는 실제로 선택 사항입니다. 쿠키만 사용해야 한다는 법은 없습니다.
서버에서 세션을 분리하는 것이 어떤 경우에는 나쁜 것일 수 있지만 항상 그런 것은 아닙니다. JWT 사용을 포함한 현대적인 접근 방식은 새로운 문제를 야기하지만 새로운 유연성도 가져오고 이러한 유연성에는 가장 나쁜 접근 방식이 포함되지 않습니다.

내 입장을 요약하자면:
인증 세션 솔루션의 일부로 JWT를 사용하는 경우 세션 쿠키가 항상 중요한 것은 아닙니다.
JWT는 이점을 알고 있고 단순한 무효화를 요구하지 않는 이유가 있는 경우 세션에 적합합니다.
쿠키가 유일한 해결책은 아닙니다.
대규모가 상태 비저장 세션의 유일한 사용 사례는 아닙니다. JWT 헤더를 사용하여 도메인/서비스 전체를 인증하는 것은 세션 쿠키의 대안으로 JWT 헤더를 사용하는 유효한 이유입니다.

제 사용 사례와 쿠키를 사용하여 접근하는 방법을 고려하시기 바랍니다.

확신하는.

JWT를 사용하면 클라이언트가 서버에 접속할 때마다 쿠키를 새로 고칠 필요가 없습니다.

이는 세션 쿠키, JWT 포함 쿠키, _및_ JWT 토큰 자체에 대해서도 동일합니다. 만료 예정인 경우에만 명시적으로 '새로고침'하면 됩니다. 여기에는 차이가 없습니다.

JWT를 사용한다는 것은 쿠키가 차단된 클라이언트가 숨겨진 게시물 변수 등을 백필로 사용하도록 강제로 대체되지 않는다는 것을 의미합니다.

쿠키를 차단하는 사용자는 거의 확실하게 로컬 저장소 및 기타 지속성 측정도 차단합니다(쿠키를 차단하는 것과 정확히 같은 이유로). 개인 정보 보호 확장도 마찬가지입니다. 다시 말하지만, "JWT 대 쿠키"는 _유효한 비교가 아니며_ 사용자가 쿠키를 차단하면 토큰을 _어쨌든_ 유지할 수 없습니다. JWT 여부는 중요하지 않습니다.

(사용자가 쿠키를 도매로 차단하면 이미 데이터 지속성을 유지하지 않기로 선택하므로 쿠키를 차단하는 사용자에 대한 인증을 지원하려는 것은 약간의 손실 원인입니다. 이것이 함께 제공되는 절충점이며 완전히 기술적으로 합리적입니다. 거래.)

여러 서비스에서 JWT를 사용하면 인증이 필요하지 않지만 JWT로 래핑되어 전달할 수 있는 uid와 같은 간단한 데이터 필드의 유효성에 대한 일부 표시를 원하는 서비스가 허용됩니다.

분산 아키텍처에서 일회용 토큰을 다루는 내 이전 게시물(세 번째 단락)의 편집을 참조하십시오. 이것들은 세션이 아니며 지속되어서도 안 됩니다. 따라서 제가 설명한 문제는 거기에 적용되지 않습니다.

JWT 접근 방식은 보다 정교한 OAUTH 접근 방식에 적합합니다.

OAuth는 일회용 토큰을 사용합니다. 세션을 대체하는 것은 아닙니다. 다시, 내 이전 게시물의 편집을 참조하십시오.

JWT REST 요청은 자격 증명을 게시하거나 REST/SPA 구현을 단순화할 수 있는 서비스에 액세스하기 전에 쿠키 요청을 요구하지 않고 만들 수 있습니다.

그들은 할 수 없습니다. 여전히 JWT _somehow_를 얻어야 합니다. 즉, 서버에서 발행해야 하므로 서버에 요청해야 합니다. 서버가 쿠키를 반환하는지 아니면 다른 헤더나 값을 반환하는지 여부는 중요하지 않습니다. 그리고 다시 "쿠키 대 JWT"는 유효한 비교가 아닙니다.

베어러 헤더 또는 쿠키 헤더를 사용하는 것은 보안과 관련하여 크게 다르지 않습니다(유효하게 바람직하지 않을 수 있는 도메인 제한 제외).

여기에서 논쟁을 볼 수 없습니다.

모바일 애플리케이션과 같이 장기간의 부재가 일반적이거나 예상되는 경우 쿠키는 JWT 접근 방식보다 덜 바람직할 수 있습니다. 자격 증명 자체 검사에 대한 더 명확한 경로가 있으면 서버에 체크인하지 않고도 동작을 용이하게 할 수 있습니다.

이것은 이익이 아닙니다. 어쨌든 서버와 통신할 의도가 있을 때까지는 토큰이 _필요하지 않습니다_. 따라서 요청을 시도하고 403이 발생했을 때 처리할 수 있습니다. 본질적으로 서버와 통신하는 것(즉, 인증된 요청 만들기)과 관련된 것을 서버에 요청하지 않으려는 시도는 이치에 맞지 않습니다.

말할 것도 없이 세션이 만료되었는지 미리 알고 싶다면 이에 대해 별도의 쿠키를 보내면 됩니다. 응용 프로그램에 대한 UX 힌트일 뿐이므로 정품 여부를 확인할 필요도 없습니다. 또한 시계 왜곡과 변경된 서명 키 때문에 _어쨌든_ 예기치 않은 인증 실패를 처리해야 합니다.

SPA/하이브리드 앱에서 쿠키에 대한 의존이 반드시 유일한 시작 위치는 아닙니다. 브라우저에서 쿠키를 처리하는 것에 의존한다고 해서 네이티브에 가까워지는 것은 아니지만 UIWebView 또는 무엇이든 의존하게 되며 저는 항상 그럴 것이라고 확신하지 않습니다. 내 예상대로 행동하십시오.

그렇지 않습니다. 브라우저이든 아니든 합리적인 HTTP 라이브러리는 쿠키를 지원합니다. 쿠키는 _절대_ 브라우저 전용이며 다른 것과 마찬가지로 HTTP 기능입니다.

서버에서 세션을 분리하는 것이 어떤 경우에는 나쁜 것일 수 있지만 항상 그런 것은 아닙니다. JWT 사용을 포함한 현대적인 접근 방식은 새로운 문제를 야기하지만 새로운 유연성도 가져오고 이러한 유연성에는 가장 나쁜 접근 방식이 포함되지 않습니다.

아직까지 그러한 '유연성'의 구체적인 예를 보지 못했습니다.

세션 솔루션의 일부로 JWT를 사용하는 경우 세션 쿠키가 항상 중요한 것은 아닙니다.

그것은 매우 모호한 진술입니다. JWT를 솔루션의 _일부_로 사용하는 것과 세션 쿠키를 _전체_ 솔루션으로 사용하는 것을 비교하고 있습니다. 이는 반대가 아닙니다. 예를 들어 SSO 시스템 또는 분산 아키텍처의 경우 많은 복잡한 아키텍처에는 세션 쿠키와 일회용 JWT 토큰의 조합이 필요합니다.

JWT는 이점을 알고 있고 단순한 무효화를 요구하지 않는 이유가 있는 경우 세션에 적합합니다.

아니요. JWT 토큰은 세션 쿠키로 요구 사항을 충족할 수 없을 때 _최후의 수단_입니다.

쿠키가 유일한 해결책은 아닙니다.

기술적으로 정확합니다.

대규모가 상태 비저장 세션의 유일한 사용 사례는 아닙니다.

내가 알고 있는 유일한 사용 사례이며 이 스레드 전체에서 언급된 다른 유효한 사례는 본 적이 없습니다. 나는 _일반적으로_ 상태 비저장 토큰이 아니라 상태 비저장 _세션_에 대해 구체적으로 이야기하고 있음을 명심하십시오.

3가지 다른 서비스(아마도 다른 컨테이너 인프라 등)를 사용하는 애플리케이션을 배포하고 세션 쿠키에 의존하는 앱에 통합하려면 어떻게 해야 하나요? 인증 서비스를 설정하고 다른 서비스에서 분리하려는 경우 공유 프록시 쿠키 세션 처리기를 실행하는 가장 좋은 방법은 무엇입니까? 엣지 케이스인가요?
쿠키는 어떻게 내 세션을 추적하기 위해 장기 실행 JWT를 사용하는 것보다 더 나은 보안, 유연성, 표준 준수를 제공합니까? 요청 시 세션을 종료할 수 있는 것을 원하지 않거나 신경 쓰지 않는다고 가정하면(비록 쿠키의 고유한 이점이 아니라 요청 처리에 있음) 모든 게시물과 응답에 Bearer 헤더를 사용하고 있습니다. 모든 헤더에 포함될 세션 JWT를 얻기 위한 인증 프롬프트/포스트 실패 - 내가 바보일 수도 있지만 이것이 얼마나 덜 안전한지 모르겠습니까? 쿠키 세부 정보는 토큰과 마찬가지로 하이브리드 앱에서 사용할 수 있지만 지속성에 대한 제어가 덜합니다. 왜 이것이 그렇게 나쁜 접근 방식인지 이해하지 못하는 것 같습니다. 물론 JWT를 얻으려면 자격 증명을 제공해야 하지만 각 서비스에서가 아니라 한 번만 수행합니다.

3가지 다른 서비스(아마도 다른 컨테이너 인프라 등)를 사용하는 애플리케이션을 배포하고 세션 쿠키에 의존하는 앱에 통합하려면 어떻게 해야 하나요?

3 서비스가 수행하는 작업에 따라 다릅니다. 자세히 설명해 주시겠습니까?

인증 서비스를 설정하고 다른 서비스에서 분리하려는 경우 공유 프록시 쿠키 세션 처리기를 실행하는 가장 좋은 방법은 무엇입니까? 엣지 케이스인가요?

인증 서비스가 성공적인 인증을 나타내는 일회용 JWT 토큰을 발행하도록 하고 선택적으로 아키텍처에 따라 사용자에 대한 '프로필 정보'를 포함합니다. 그런 다음 애플리케이션에 따라 다음을 수행합니다.

1. 일반 웹사이트인 경우: 인증 서비스는 애플리케이션 서버의 인증 페이지로 리디렉션됩니다. JWT 토큰을 쿼리 매개변수로 전달합니다. 응용 프로그램 서버는 토큰의 유효성을 검사하고 사용자에게 세션 쿠키를 제공합니다.
2. SPA인 경우: 인증 서비스는 생성된 토큰을 (JSON?) 응답으로 반환합니다. 프론트엔드 애플리케이션은 토큰을 매개변수로 포함하여 애플리케이션 서버의 인증 끝점에 HTTP 요청을 하고 애플리케이션 서버의 유효성 검사 후 교환으로 세션 쿠키를 받습니다.
3. 독립 실행형 애플리케이션(데스크톱 또는 모바일)인 경우: SPA와 유사하지만 브라우저의 프론트엔드 애플리케이션이 아닌 쿠키를 지원하는 HTTP 라이브러리를 사용합니다.

두 경우 모두 JWT 토큰은 약 5분 동안만 유효하며(클럭 왜곡을 설명하기 위해) 한 번만 사용하여 애플리케이션 서버의 세션과 교환합니다. 토큰에 프로필 정보를 포함하면 인증 서비스가 애플리케이션에서 완전히 분리된 상태로 유지됩니다.

편집: 독립 실행형 애플리케이션 케이스를 추가했습니다.

SPA/하이브리드 모바일 앱 개발 시나리오에 있다고 가정하겠습니다. 또한 인증 및 전달자 토큰이 있는 OUATH가 아닌 세션에 JWT를 사용하고 있다고 가정하고 로그인하고 전달자 토큰을 받습니다.
각 세션이 5-15초마다 3개의 서비스 모두에 요청하는 실시간 애플리케이션이 있다고 상상해 봅시다. 많은 사용자가 빠른 상태 확인을 위해 로그인하거나 GIS 데이터 등을 게시하여 평균 사용 시간이 1분 미만이지만 앱을 시작하고 싶어합니다. 앱을 닫고, 자격 증명 없이 3일 후에 다시 시작합니다. 쿠키를 멀리하게 만드는 것들)

예를 들어 그래프 쿼리 서비스, 도커 랙스페이스의 매핑 또는 GIS 서비스, 사용자 프로필 데이터를 관리하기 위해 postgres db에 대한 REST 인터페이스를 사용하여 AWS 서비스를 생성했다고 가정해 보겠습니다. 모든 REST 서비스에 대한 헤더 요청에서 동일한 JWT를 사용하고 JWT의 공유 유효성 검사가 한 번 발행되도록 공통 비밀에 대해 유효성을 검사할 수 있습니다.
그것들이 그들 자신의 컨텍스트 내에서는 stateful이지만 공유 컨텍스트에서만 느슨하다고 가정합시다.
이것은 JWT를 세션 토큰으로 Bearer Token으로 사용하는 내 제안된 솔루션과 일치하는 문제 사양이며 유사한 환경에서 비교할 수 있도록 세션 쿠키를 사용하여 접근하는 방법을 묻고 있습니다.

사용자가 자신이 누구인지에 대한 합리적인 확신이 모두 필요하다고 가정해 보겠습니다.
내 솔루션은 인증을 위해 HTTP 헤더 내의 모든 서비스에서 사용되는 자격 증명 게시물에 대한 응답으로 JWT 토큰을 생성하는 것입니다. 모든 서비스에서 공유 JWT 비밀로 유효성 검사가 수행됩니다.
인증 서비스는 토큰을 생성하고 로그인 시 반환합니다. 토큰은 다른 도메인의 다른 모든 서비스에 대한 헤더 요청에 포함됩니다. 쿠키를 사용하는 경우 각 도메인에 대해 새 쿠키를 설정해야 합니다. JWT에 자신 있게 의존할 수 있는데도 수신된 각 http에 대해 쿠키를 확인하거나 얻기 위해 새 요청을 하는 서비스를 원하는 이유는 무엇입니까? 5개의 서비스가 있는 경우 이제 5개의 다른 세션 쿠키를 관리하고 이 모든 쿠키 간의 조정을 보장해야 합니다. 많은 경우에 이것이 올바른 접근 방식일 수 있지만 많은 경우 구현이 빠르고 간단하며 명확하게 볼 수 있는 심각한 보안 허점을 드러내지 않는 것에 대해 지나치게 복잡하다고 생각합니다.
JWT 기간을 제한하는 이유는 무엇입니까? 쿠키는 정기적인 서버 접속을 가정하기 때문에 전통적으로 수명이 짧습니다. 빨리 만료되고 싶지는 않지만 재인증의 절충안이 더 큰 위험이 있다고 판단하여 오래된 세션이 오래 지속되는 것을 기쁘게 생각합니다.

귀하의 상황을 올바르게 이해한다면 3 대신 매 기간마다 9 개의 요청이 수신됩니다. 설정된 세션을 확인하기 위해 인증 서버를 사용 중입니다. 더 많은 코드와 움직이는 부분이 있습니다. 각 기간마다 세션을 종료할 수 있다는 이점이 있지만 이것이 요구 사항이 아닌 경우에는 어떻게 합니까? 사용자가 종료된 후 48시간 동안 게시된 데이터를 수신하는 데 신경 쓰지 않고 새 요청에 대해 인증 서버를 사용하여 필요하지 않은 것을 필터링할 수 있는 경우 어떻게 합니까?

이 사용 사례에서 세션 세분성이 적절하게 설정되고 세션 쿠키와 마찬가지로 적절한 시간 초과 기간에 인증 서버를 통해 JWT를 새로 고치는 클라이언트를 구현하기 때문에 사소한 시간 왜곡은 관련이 없습니다. '프로필'이 진행되는 한 공유 uid를 공통 ID로 사용하고(올바르게 이해하는 경우) 서버 측 구현에는 JWT 서명/검증을 위한 공유 비밀이 포함되어 있습니다.

내가 제안한 아키텍처에서는 JWT 제한 시간이 제공하는 것보다 더 세부적으로 토큰을 취소할 필요가 없는데 세션 쿠키를 대신 사용해야 하는 이유는 무엇입니까?
내가 제안한 아키텍처에서 서비스 상태 간에 종속성을 만들 수 있지만 중앙 집중식에 의존하고 기본적으로 모든 것을 인증에 다시 연결해야 하는 것보다 이것을 설계할 수 있습니다. 핵심은 유연성입니다. 이는 종속성을 실현하는 비용으로 발생하지만 이는 처음부터 직면한 문제이며 모든 플랫폼에서 구현되지만 프레임워크 간에 다르게 처리되는 레이어가 아닙니다. 실제로 없이 node, php 및 이국적인 쿠키 세션 기본 처리가 있는 세션에 대한 쿠키 만료를 업데이트하는 것은 중요하지 않을 수 있으므로 인증 서버 요청을 직접 게시하는 것이 좋습니다. 요청이 있지만 클라이언트에 대한 요청은 3배입니다.

제안된 아키텍처와 일치한다면 실제로 여러 쿠키의 시간 제한을 해결해야 합니다. 예를 들어 클라이언트가 로그인하고 1시간 후에 만료되는 인증된 세션 쿠키를 수신하는 경우
그런 다음 40분 후에 이 세션 쿠키 값을 첫 번째 서비스에 게시한 다음 로컬 도메인 쿠키를 발행하기 전에 인증 서버를 쿼리합니다. 내부 원본 인증 쿠키 만료를 해킹하거나 서비스 쿠키의 시간 제한을 20분으로 설정합니까? 그리고 이것이 만료되면 인증 쿠키의 새로 고침을 트리거합니다. 명백한 솔루션을 놓치고 있지 않는 한 이것은 서비스 중 하나를 통해 새로 고칠 수 있는 단일 JWT를 사용하여 완전히 피할 수 있는 많은 스파게티 더미로 쉽게 변할 수 있습니다(이가 토큰을 확장하는 방법 이해 life ) 또는 인증 서버를 통해 새로 고침을 요구합니다.

부실 데이터에 대한 접근 방식에 대해 논의할 수 있지만 이 사용 사례의 문제 범위는 부실 자격 증명 무효화에 의존하지 않으므로(인증 서버의 관점에서) 관련이 없습니다.

JWT를 인증된 세션 관리 접근 방식으로 사용하는 것이 하이브리드 모바일 애플리케이션 내에서 실행될 교차 도메인 서비스에 대한 인증된 세션 관리 접근 방식으로 세션 쿠키를 사용하는 것과 비교하여 본질적으로 열등하고 부정확하다는 귀하의 주장에 대해 논의하고 있다는 것이 제 이해입니다. 자격 증명의 재공급 없이 간헐적으로 장치.

나는 당신이 제안된 접근 방식이 본질적으로 덜 안전하거나 어떤 식으로든 덜 '올바르다'고 주장할지 여부를 확인하려고 합니다. 내가 보기에 이 아키텍처의 단순성에는 상당한 이점이 있으며 더 간단한 아키텍처에 대해 고려되지 않고 절충되지 않은 모든 서비스에서 세션을 관리하는 데 필요한 더 무겁고 복잡한 솔루션이 제공하는 이점은 없습니다. 이 솔루션이 세션을 관리하기 위해 쿠키를 사용하여 경험하지 못한 문제를 경험하는 방법을 지적할 수 있다면 명시적으로 이해하는 데 정말 도움이 될 것입니다(즉, 보안이 어떻게 손상되는지)

서비스는 거의 중요하지 않습니다. 무엇을 암시하는지 확실하지 않습니까?

상태 저장 서비스와 상태 비저장 서비스에는 차이가 있습니다.

의 말을하자 [...]

이것은 문제가 무엇인지가 아니라 문제를 해결하는 방법을 설명합니다. 세션으로 접근하는 방법을 설명하도록 요청할 때는 유용하지 않습니다. 이미 세션을 사용하지 _않을_ 것이라고 가정하기 때문입니다. 대신 문제를 설명하십시오.

언제 JWT에 자신 있게 의존할 수 있습니까?

당신은 할 수 없습니다.

5개의 서비스가 있는 경우 이제 5개의 다른 세션 쿠키를 관리하고 이 모든 쿠키 간의 조정을 보장해야 합니다.

할 것 같지 않은. Stateful 대 Stateless 서비스에 대한 내 설명을 참조하십시오.

많은 경우에 이것이 올바른 접근 방식일 수 있지만 많은 경우 구현이 빠르고 간단하며 명확하게 볼 수 있는 심각한 보안 허점을 드러내지 않는 것에 대해 지나치게 복잡하다고 생각합니다.

특히 분산 아키텍처에서 인증 및 세션 관리는 _is_ 복잡합니다. 엔지니어들이 과거에 가능한 분산 아키텍처를 피한 데에는 이유가 있습니다. "Just use JWT"는 데이터 부실 및 세션 무효화를 완전히 무시함으로써 이를 간과하고 실제보다 더 쉬운 척합니다.

보안 구멍이 있고 설명하려고 여러 번 시도했습니다. 명확하게 볼 수 없다는 것은 명확하지 않은 부분에 대해 특정 질문을 하지 않는다면 제가 할 수 있는 일이 아닙니다. .

JWT 기간을 제한하는 이유는 무엇입니까?

내가 준 예에서? 영구 식별자가 아닌 일회용 교환 토큰으로 사용되기 때문입니다. 취소할 수 없기 때문에 영구 식별자를 원하지 않습니다.

쿠키는 정기적인 서버 접속을 가정하기 때문에 전통적으로 수명이 짧습니다. 빨리 만료되고 싶지는 않지만 재인증의 절충안이 더 큰 위험이 있다고 판단하여 오래된 세션이 오래 지속되는 것을 기쁘게 생각합니다.

세션을 새로 고칠 위험이 없습니다.

프로필 또는 시계 왜곡 무시 - 유사한 시나리오에 쿠키를 사용하는 경우 동일한 문제가 적용되므로 이 가상의 논의에 큰 영향을 미치지 않는 세부 사항.

이는 언급된 다른 모든 사항과 마찬가지로 강력한 인증 시스템의 중요한 부분입니다. 그들을 무시하는 것은 선택 사항이 아닙니다. 그리고 다시, 이것은 "쿠키"에 관한 것이 _아닙니다_, 이것은 세션에 관한 것입니다.

세션의 경우 아니오, 동일한 문제가 적용되지 _않습니다_. 중앙 집중식/상태 저장 세션 저장소는 데이터가 전혀 부실하지 않고 프로필 정보를 어느 시점에서든 검색할 수 있음을 의미하며 클록 스큐는 서로 다른 시스템 간에 교환되는 제한된 유효성 토큰의 문제입니다.

세션 관리 접근 방식이 요청당 취소가 필요한 세션 정의에 대한 첨부 파일로 귀결될 수 있기 때문에 JWT에 대한 귀하의 이의를 요약할 수 있는 것처럼 보입니다. 액세스) 및 새로 고침과 관련된 위험(도청되는 경우) . 분산 처리는 새로운 표준입니다. 다중 서비스는 매우 일반적입니다. 다중 서비스 아키텍처에 이러한 종류의 접근 방식을 사용하려면 결과를 완전히 이해해야 합니다. 분산 데이터베이스는 오랫동안 존재해 왔습니다. DNS와 같은 분산 데이터 저장소는 처음부터 존재했습니다. 때로는 아키텍처의 단순함이 설계 한계를 넘어 기존의 지배적인 표준을 압박하는 것보다 더 많은 이점을 제공합니다. 서비스 요청 세션에서 트랜잭션 ACID 문제를 알고 있다면 JWT 세션 관리 접근 방식을 채택하여 서비스를 인증하여 우리가 주장하는 경우 빠르게 복잡한 인프라가 되는 것에 제약을 받지 않고 가능성을 완전히 활용하지 말아야 할 이유가 없습니다. 엄격한 제약 조건에서 세션 쿠키를 슈혼(shoe-horn)하는 솔루션으로 시도하십시오.
@joepie91 - 적절한 경우 기본 인증에 대해 쿠키 세션 인증을 사용하고 JWT를 새로 고치도록 요구할 수 있습니다. 다시 - 도메인 간 세션 서비스 액세스를 위한 JWT의 사용은 솔루션의 일부로 사용될 수 있으며 적절한 경우 쿠키 세션도 사용됩니다. 요점은 세션 관리의 일부인 JWT가 서비스 하위 집합에 액세스하는 경우에도 역할이 없는 사악한 접근 방식이 아니라고 생각한다는 것입니다.
https 세션 쿠키에도 위험이 따릅니다. SSL을 통신할 때 SSL 플래그가 설정되지 않고 쿠키를 일반 텍스트로 전달하는 사이트가 얼마나 많은지 놀랍습니다. 쿠키 세션이 위험합니까?
내가 찾을 수 있는 가장 큰 위험은 코더가 토큰을 잘못된 서버로 보내도록 허용하고 토큰을 통해 제3자가 이러한 보조 사용자 리소스에 효과적으로 액세스할 수 있다는 것입니다. 이것은 어딘가에 큰 빨간 글자로 표시되어야 하며 이런 일이 발생하지 않도록 개발자에게 강력한 책임을 져야 합니다. 개발자는 필요한 보안 조치가 취해졌는지 확인하기 위해 적절한 조치를 취해야 하며 이와 같은 리포지토리는 이러한 접근 방식 중 일부를 설명하고 이를 예제에 포함해야 합니다. 내 생각에 이것은 중요하지 않은 서비스에 대한 교차 도메인 시간 제한 서비스 인증의 유연성에 대해 지불할 수 있는 수용 가능한 가격입니다.
복잡한 솔루션을 설계할 때 인증 끝에 세션 쿠키를 포함할 가능성이 있으며 적절한 경우 일회용 토큰 등을 포함하도록 확장될 수 있습니다. 요점은 이 일이 가능하고 잘못될 수 있고 위험을 노출할 수 있는 곳이 있지만 많은 경우에 더 풍부하고 더 간결한 애플리케이션을 구축할 수 있는 기회를 제공한다는 것입니다. 이러한 이유로 저는 이 리포지토리가 제안된 대로 비닝되어야 한다고 생각하지 않습니다. 문제 로거에 의해.
JWT를 세션 문자열로 사용하여 두 세계의 장점을 모두 얻으려는 경향은 문제를 일으키는 것 같습니다. 가장 현저하게 충돌할 수 있는 시간 초과/TTL 기간입니다. 또한 처음에 피하려고 했던 것과 동일한 도메인 액세스 제한을 적용하므로 기본 예제에 넣으면 사람들이 처음에 JWT를 사용하는 이유를 묻게 될 것입니다.

종속성으로 JS를 사용하는 것은 아주 사소한 일입니다. 하이브리드 모바일 SPA의 맥락에서 JS 무료 클라이언트를 수용할 필요는 없을 것입니다. redis가 세션 저장을 위한 효율적인 옵션을 제공한다고 유사하게 주장하면서 이것이 문제라고 제안하는 것은 약간 모순되는 것처럼 보입니다.
JWT의 만료는 새로 고침(쿠키 세션이 새로 고쳐지는 것과 정확히 같은 방식)으로 처리되거나 재인증이 필요한 세션 시간 초과를 제공한다는 점에서 쓸모가 없습니다. JWT에 서명하면 변조되지 않았으므로 영구 저장소 서버 측 유효성 검사에 대한 절대 요구 사항이 제거되지만 원하는 경우 수행할 수 있으며 많은 의견이 있는 구현 없이 쿠키 세션과 동일한 결과를 얻을 수 있습니다. 적절한 경우 교차 도메인을 활용하는 능력. 하이브리드 모바일 앱에서 로컬 저장소에 쿠키 또는 JWT를 저장하면 더 많은 제어가 가능합니다. 브라우저 구현의 보안에 대한 로컬 스토리지 사용에 대한 반대는 공급업체에 대한 신뢰와 이러한 자격 증명 처리에 대한 승인의 문제입니다.
유연성은 많은 모바일 하이브리드 SPA 개발자에게 유용하지만 제한 사항에 대한 이해가 필요합니다.
JWT는 단순히 서명 키를 변경하여 무효화할 수 있으며 이는 다시 유연성을 제공합니다. 서비스 전반에 걸쳐 공통 공유 개인 서명 키를 사용하거나 사용자 세션당 무작위로 생성하고 세션 쿠키의 일종의 거부 이점을 실현할 수 있습니다.
거의 모든 최신 JS 프레임워크는 JWT를 지원하며 지원하지 않는 주요 플랫폼을 찾기가 어려울 것입니다. 일부는 그렇지 않을 수도 있습니다(Wordpress JWT 플러그인 .. 흠 .. 살펴보지 않았지만 저를 긴장하게 만듭니다).
JWT 사용에는 OAUTH에 대한 배경 지식과 쿠키 세션 사용의 장단점 및 이점이 포함되어야 합니다. 제게는 여러 서비스를 사용하는 일반 모바일 하이브리드 개발자에게 실질적인 업무상의 이점이 있지만 쉽게 빠지는 함정이 있습니다. 완전히 설명하려면 많은 예가 필요할 수 있습니다.

JWT를 인증용 토큰으로 사용하는 것에 대한 나의 _원래 추론_은 JWT가 CPU 바운드 인지 확인한다는 것입니다(_내 "이전" 랩톱은 초당 180k JWT를 확인할 수 있음_). 반면에 간단한 토큰을 사용하고 조회해야 한다면 메모리(또는 데이터베이스)에서 작업은 I/O 바운드 (_또는 더 나쁜 네트워크
http://stackoverflow.com/questions/868568/what-do-the-terms-cpu-bound-and-io-bound-mean

세션 관리 시스템 _first_는 JWT가 _서명된_ 키를 사용하여 JWT가 유효한지 확인하고, 그렇지 않은 경우 _조기_ 메시지를 거부하고, _then_ 세션이 아직 무효화되지 않았는지 확인합니다(예: 사용자 로그아웃). .

JWT가 Authorization 헤더의 토큰으로 사용되도록 _설계되지 않았을 수도 있다는 것을 알고 있습니다.

참고: 나는 여전히 "쿠키 없음" 각도가 이 추가 정보/자습서를 시작하는 올바른 방법이 아니라는 데 동의합니다. 👍