Learn-json-web-tokens: READMEの危険で不正確な情報

いくつかの非常によく考えられ、明確に表現された懸念は、レポを見始めたばかりの人として確かに私に思考の糧を与えています。 Nodeを使用してJWT認証の動作例を作成する簡単な例を探していました。 JWTに興味があるのは、CORSの問題を回避しながら、RESTAPIとjsクライアントの両方のセッション管理に最新のベストプラクティスアプローチを提供することです。 私はセキュリティに少し興味がありますが、OAUTHなどのより包括的な安全なアプローチでトークンが果たすことができる役割には感謝していますが、これはJWTを使用する動機ではありません。 このレポジトリを最初に読んだとき、著者がJWTの使用法などの知識を構築しているときに収集したメモがたくさん含まれていることに気づきました。このレポジトリにはほとんど投資していませんが、いくつかのサポートツール、リファレンスを使用した、プラットフォーム固有の最小限のログイン/ログアウトの実例の場所。 オンボーディングスキルの基盤として、またスターターとして、このリポジトリの目的は良いと思いますが、おそらくREADMEは、この種のJWTの使用の目的に真剣に書き直して焦点を合わせる必要があります。 私は何かを提案しようと思っています..joepie91-あなたは明らかに問題をよく理解しています..JWTのこの種の使用法の本当の利点が実際に何であるかについていくつかの考えを提供できますか？

こんにちは@ joepie91 、私たちはあなたが見つけた_stoked_であり、JWTに関する私たちのメモを_読んで_います！
懸念を表明するためにこの問題を開くために時間を割いていただきありがとうございます。 ❤️
懸念事項をそれぞれ_個別の_問題に分割するか、少なくとも話し合いを容易にするために番号を付けていただければ、喜ばしく思います。

これらのメモの内容が「_Dangerous_」であることに_敬意をません。

_Cookies _> EU指令ePrivacyリサイタル25、でcookies 5回_明示的に言及した_are：

見る：
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

確かに、_多くの_ウェブサイト/アプリ（_サードパーティのトラッキングCookieを使用していない_）は‘strictly necessary for the delivery of a service requested by the user’該当します...これが、_プログレッシブエンハンスド_ウェブアプリケーションでCookieを_使用_する理由です。 参照： https ：

JWTを_localStorageに保存する_>セッションデータ/トークンをlocalStorage保存することは、 JavaScriptが_必須であることを_同意します_（_これも好きではありません。プログレッシブエンハンスメントをlocalStorage 、「_Backend-AS--あるSERVICE_NAME」で構築された_all _アプリケーションが作られる方法であるバースは、一般的にクッキーを許可していませんので...あなたはGoogleの使用して50万デベロッパーことを示唆しているFirebaseがありますそれを「_間違った_」...？ （_これは素晴らしい-別の-議論になるでしょう...！_）

ステートレスセッションは、組み込みのexp （_ expiration time_）オプションがあるため、 JWTで_セッションID （ jtiを保存する代わりに、セッションをステートレスにすることを_選択/優先_しませjti ）_inside_ JWTどのJWTが確認された_after_ Redisのストアで検索されます。 これは、ユーザーがログアウトしたとき、またはデバイスが盗まれてアクティブなセッションを取り消す必要がある場合に、セッションを_無効化_できることを意味します。

はい、JWTの_主な_目的はpass claims between parties in web application environmentにすることです。これは、私たちがJWTを使用している目的です。

セッションIDまたはトークンは、サーバー側でチェックされるランダムな文字列である可能性がありますが、JWTを使用してセッションデータをフォーマットおよび署名することを決定しました。

結論：Readmeを_clarify_に更新しましょう。 👍

@nelsonicが提案する@ joepie91の問題を、Webアプリケーション自体のコンテキストでのJWTの使用、またはCookieのサポートが優れていることに対する批判であるとは読みません。 むしろ私は、JWTの説明が、JWTを選択した理由を過大評価または誤って表現する方法で提示されているという批判を受け入れます。
同じ懸念が＃55でも表現されています（JWTが暗号化されていないことを明確にしてください...）

私にとっては、有効期限が切れる一般的な申し立てを使用してFirebaseと自分のサービスを操作できれば十分です。 私はそれを拡張して、ある場合にはある状態を含み、他の場合には含まないようにし、それでもCookieまたは古いアクセス制御http認証アプローチを使用するアプローチを好むかもしれません。
より洗練されたアプローチの一部としてJWTトークンを使用できるのは気に入っていますが、READMEの利点に焦点を当てるのは、堅固な立場に迷うのではなく、JWTトークンで解決しようとしている問題に焦点を当てるべきであることに同意します。 READMEの参考資料の多くは、ディスカッション資料としてメモやWikiに追いやられる可能性がありますか？

READMEが危険だと必ずしも言うかどうかはわかりません-少し強いようです

クッキー> EUeプライバシー指令リサイタル25では、クッキーは5回明示的に言及されています。

申し訳ありませんが、漠然と言ったようです。 テキストにはいくつかの場所に「クッキー」という単語が含まれていますが、それが法制化される特定の概念として特定されていません。 むしろ、それは例として提供されています（したがって、私のポイントの残りの部分は引き続き適用可能であり、「Cookieを使用しない」ことで同意の必要性が魔法のようになくなることはありません）。

localStorageは、「Backend-as-a-Service」で構築されたすべてのアプリケーションが作成される方法です。これは、BaaSは通常Cookieを受け入れないためです...

これは無関係であり、これらのサービスの問題です。 これは、独自のアプリケーションのセッションにJWTを使用することを正当化するものではありません。

Google Firebaseを使用している50万人の開発者が、それを「間違った」方法で行っていることを示唆していますか...？

Firebaseの設計が非常に不十分であるという事実を除けば、これは権威に訴えるものであり、技術的な議論の場にはなりません。 特定の製品に関する特定の会社の決定について話し合うことには興味がありません。 私は、与えられたアプローチの長所と短所について議論することにのみ興味があります。

ステートレスセッションは、組み込みのexp（有効期限）オプションがあるため、JWTで可能ですが、セッションをステートレスにしないことを選択/優先します。代わりに、セッションID（jti）をJWT内に格納することを選択します。 JWTが検証された後にRedisストア。 これは、ユーザーがログアウトしたとき、またはデバイスが盗まれてアクティブなセッションを取り消す必要がある場合に、セッションを無効にできることを意味します。

その時点で、JWTを使用することに実際のメリットはありません。 express-sessionや、スタックに適合する他の戦闘テスト済みのピアレビュー済みセッションソリューションを使用しないのはなぜですか？ JWTの推奨事項は、ここでは意味がありません。なぜなら、人々は_そもそも独自のセッション管理をロールするべきではないからです_。

言うまでもなく、セッションの有効期限は_server-side_で処理する必要があるため、JWTのexpは基本的に役に立ちません。

はい、JWTの主な目的は、Webアプリケーション環境の当事者間でクレームを渡すことです。これは、まさに私たちがJWTを使用している目的です。

JWTは、「Webアプリケーション環境」とは少しも関係がありません。

セッションIDまたはトークンは、サーバー側でチェックされるランダムな文字列である可能性がありますが、JWTを使用してセッションデータをフォーマットおよび署名することにしました。

繰り返しになりますが、スタックにバトルテスト済みのセッション実装を使用するだけです。 JWTは、ここで行うのは間違った推奨事項です。

これらのメモの内容が「危険」であることに、私たちは敬意を表して同意しません。

あなたは反対することができます、しかしそれはそれが何であるかです。 JWTを間違って使用する方法はたくさんありますが、そのいくつかはこのリポジトリのREADMEによってほのめかされているため、人々は自分の足を撃つことに「縛られ」ています。 はい、それは有害です。

@ pscott-au：joepie91-あなたは明らかに問題をよく理解しています..JWTのこの種の使用法の本当の利点が実際に何であるかについていくつかの考えを提供できますか？

Redditスケールで実行していない限り、標準のWebアプリケーションにJWTを使用するメリットはありません。 JWTが役立つ場合の一般的な例：

• シングルサインオンメカニズム（JWTは、ユーザーがターゲットアプリケーションのセッションと交換する1回限りの認証トークンとして使用されます）、
• URLが共有可能であることが意図されているプラ​​イベートイメージの一時アクセストークン、
• 基本的に、相互に信頼している2つのシステムが、相互に直接接触したりバックエンドを共有したりすることなく、信頼できないパーティを介してデータを交換する必要があるシナリオ。

標準のWebアプリケーションセッションの場合は、使用しているスタックに対して十分にテストされたセッション実装を使用する必要があります（たとえば、Expressを使用している場合はexpress-session ）。

私の経験の一部に本当に挑戦するので、この議論をすることは素晴らしいことです。 おそらく、JWTを使用することに個人的に興味があるというコンテキストがあります（Firebaseを使用しているという事実は別として、これから調査する貧弱なエンジニアリングの問題を学習することに興味があります）。 モバイルアプリ/ SPAを作成するとき、特に複数のサーバー/ドメインから提供されるサービスを使用するときは、JWTがうまく機能しているように見えるシングルサインオン機能が必要になることがよくあります。 私の理解では、セッションCookieの使用は、ブラウザーとJSスペースのセキュリティが強化された期間に進化し、CORSの導入は、これに対する例外を処理するために進化し、JWTが対処するためのかなりハッキーなソリューションを残しました。 。
何年もの間、Cookieセッションのアプローチは、元の基本的なダイジェストhttp認証よりもはるかに優れたアプローチを提供してきました。また、WebベースのアプリにCookieセッション管理ソリューションを使用することもよくあります。
しかし..私が現在構築しているほとんどのアプリはモバイルまたはSPAであり、RESTAPIを多用していることがわかりました。 Cookieを処理するものをバンドルしたり、セッションを確立するために複数のリクエストを処理したりすることなく、単純なcurlリクエストで簡単にテストできるのが好きです。 そのため、JWTを使用するときに機能するAPIを迅速に実装していることがわかりました。 私の直感では、Cookieよりも長時間実行されるセッションにJWTを使用する方が適切だと感じていますが、直感よりも怠惰である可能性があるため、これについては反論します。 必要に応じてOAUTHの方針に沿ってセキュリティを拡張でき、より完全にセキュリティを確保したいのですが、多くの場合、セッションはこのレベルのセキュリティが必要であると判断するものではありません。 私にとって重要なことは、将来のアーキテクチャの変更に関してJWTベースの認証アプローチが提供する柔軟性です。 古いコードがオプションとしてJWT認証を提供するようにリファクタリングされていることがわかりました。これにより、メンテナンスの複雑さが驚くほど少なくなりましたが、ほとんどの場合、将来の開発が合理化され、Cookieセッションより本質的に劣っているとは思われません。
実際、特にモバイルデバイスでJWTタイムアウト機能を使用することには利点があり、一部のサポートライブラリはこれを利用します。 たとえば、デバイスがネットワークに接続されていないときに、このタイムアウトに基づいてアプリにユーザーをログアウトさせたり、ログインしたままにしておくことができます。
私にとって、セッションCookieに対するJWTのスケールの利点についての説得力のある議論はあまり見られません。
JWTをセッションCookieとして使用できると示唆している人がいますが、Cookieには独自のタイムアウト期間（完全に管理されたサーバー側ではない）があり、これらを組み合わせると混乱する可能性があります。
最新のJSフレームワークの多くは、CookieよりもJWTのサポートが強化されています。これは、スタックのバトルテスト済みのピアレビューソリューションが、実際には多くのアプリケーションでJWTを使用する傾向があることを示しています。 WebサービスでのJWTの人気は技術的な議論ではありませんが、これらすべてが等しく誤りであるため、これを無関係であるとして却下します。 Expressは、私が知る限り、dwylグループが使用するスタックのコア要素ではないため、それに合わせる理由はありません。
私は懸念を抱いていますが、あなたの議論に完全には納得していないので、あなたが同意できる私の意図のいくつかのスレッドがあることを願っています。
READMEには深刻な見直しが必要であり、メインのREADMEではなく、背景のディスカッションテキストに削除またはプッシュバックすることをお勧めする行があることに同意します。

（私が調査する貧弱なエンジニアリングの問題を学ぶことに興味があるFirebaseを利用しているという事実は別として）

問題のいくつかは、そのJSクライアントライブラリがクローズドソースであり、かなり役に立たないエラー出力で難読化されていることです。「配列」などはありません。クライアントライブラリには、応答が返らない可能性のある奇妙なバグがたくさんあります。理由は不明ですが、ACLシステムは独自のエディターでもサポートされていない非標準のJSONバリアントを使用し、JS APIは通常のコールバックAPIではなく疑似イベントAPIを使用する必要があります（ただし、一貫して動作しません）。すぐ。

モバイルアプリ/ SPAを作成するとき、特に複数のサーバー/ドメインから提供されるサービスを使用するときは、JWTがうまく機能しているように見えるシングルサインオン機能が必要になることがよくあります。 私の理解では、セッションCookieの使用は、ブラウザーとJSスペースのセキュリティが強化された期間に進化し、CORSの導入は、これに対する例外を処理するために進化し、JWTが対処するためのかなりハッキーなソリューションを残しました。 。

正確ではありません。 アプリケーションとサードパーティのAPIは異なるものであり、認証要件も異なります。 トークンベースの認証システムは、サードパーティのAPIと通信するときにアプリケーションで意味をなしますが、SPAであっても、これは独自のアプリケーションでは意味がありません。 これは、同じログインサービスを使用する複数のエンドユーザーサービスを指す「シングルサインオン」とも関係ありません。

CORSは別の問題であり、実際にはこれとは関係ありません。

しかし..私が現在構築しているほとんどのアプリはモバイルまたはSPAであり、RESTAPIを多用していることがわかりました。 Cookieを処理するものをバンドルしたり、セッションを確立するために複数のリクエストを処理したりすることなく、単純なcurlリクエストで簡単にテストできるのが好きです。 そのため、JWTを使用するときに機能するAPIを迅速に実装していることがわかりました。

開発では、特定のテスト要件がある場合がありますが、これらは本番環境で採用するアプローチに影響を与えるべきではありません。 SPAであるほとんどのものは、そもそもSPAであってはならないという事実を除けば（SPAはWebサイトではなく、Webアプリ用です！）、それらとのセッションを使用できない理由はありません。

それとは別に、cURLはCookieを適切にサポートしており、 httpieやhttp-promptなどのより優れたAPIテストクライアントが他にもたくさんあり

必要に応じてOAUTHの方針に沿ってセキュリティを拡張でき、より完全にセキュリティを確保したいのですが、多くの場合、セッションはこのレベルのセキュリティが必要であると判断するものではありません。

セッションは、アプリケーションの最も重要な側面の1つです。 十分に安全でない場合、アプリケーションは本質的に壊れており、完全に脆弱です。 それが理由です。 JWTをLocalStorageに保存するのはひどい考えです。

私にとって重要なことは、将来のアーキテクチャの変更に関してJWTベースの認証アプローチが提供する柔軟性です。 古いコードがオプションとしてJWT認証を提供するようにリファクタリングされていることがわかりました。これにより、メンテナンスの複雑さが驚くほど少なくなりましたが、ほとんどの場合、将来の開発が合理化され、Cookieセッションより本質的に劣っているとは思われません。

ここでは、開発者の99.99％が必要とする柔軟性は導入されていません。また、古いデータやトークンを無効にできないなど、それがもたらす問題のいくつかをすでに強調しました。

実際、特にモバイルデバイスでJWTタイムアウト機能を使用することには利点があり、一部のサポートライブラリはこれを利用します。 たとえば、デバイスがネットワークに接続されていないときに、このタイムアウトに基づいてアプリにユーザーをログアウトさせたり、ログインしたままにしておくことができます。

これはJWTに固有のものではありません。 これは、サーバー側のセッションで問題なく実行できます。 実際、（複雑な）ステートフルアーキテクチャを導入せずにJWTを無効にすることはできないため、セッションは実際にここで勝ちます。

私にとって、セッションCookieに対するJWTのスケールの利点についての説得力のある議論はあまり見られません。

スケーリングの利点は、すべてのセッションを保持する単一の正規サーバーを必要としないことです（データはトークンに直接格納できるため）。つまり、ボトルネックを取り除くことができます。 しかし、私が言ったように、実際にこの問題に遭遇する開発者はほとんどいません。 これは、非常に大規模なプロジェクトにのみ役立ちます。

最新のJSフレームワークの多くは、CookieよりもJWTのサポートが強化されています。これは、スタックのバトルテスト済みのピアレビューソリューションが、実際には多くのアプリケーションでJWTを使用する傾向があることを示しています。

セッションCookieをサポートしないフレームワークはまだ見ていません。

Expressは、私が知る限り、dwylグループが使用するスタックのコア要素ではないため、それに合わせる理由はありません。

それが彼らの問題です。 Expressは単なる一例であり、十分にテストされたセッション実装は、基本的にすべての一般的に使用されるフレームワークに存在します。

肝心なのは、このリポジトリを読んでいる開発者にとって、JWTの実際の利点はまったくなく、いくつかの欠点やセキュリティの問題さえあるということです。 それは確かな技術的選択や推奨ではありません、そしてそれは本当にそれの終わりです。

@ joepie91あなたが私たちのレポ/メモを見つけて、それを読んでフィードバックを与えるためにあなたの時間を費やしたことを、私はあなたにどれほど_喜んでいるか_言うことができません！ 真剣に、もし私があなたに直接会ったことがあれば、あなたが飲みたいものの_パレット_をあなたにあげます！ 🍺

私があなたをこのリポジトリの寄稿者にした場合、それを_改善_するための私のプルリクエストを確認しますか？ 📝

また、晴れ-G @ @AshleyPinner、@alfiepatesは、どのようにこの_particular_協議のうえ_you_紳士つまずきましたか？ この問題はRedit / Hackernewsで共有されましたか？ （_私は人々が私たちの投稿をどのように見つけるのか興味があります..._）

私はこれを数日間かみ砕いていて、最近のSPAやモバイルアプリの従来のセッションCookieに先立って、デフォルトの選択肢としてJWTを使用することに反対する多くの議論に参加することができません。
READMEの書き直しを検討する前に、特定の要件に対するCookie / JWT認証アプローチの長所と短所を比較検討する決定マトリックスを作成するか、一連のユースケース全体の長所と短所を詳しく説明することを考えていました。 複雑なアプリを構築する際に人々が直面する現実の課題の多くは、ほとんどの場合、あまりエレガントに解決されていないか、少なくともCookieセッションを使用することで問題があるように思われます。 問題のポスターが作成する認識は、JWTは、最新のアプリには適さない信頼性の低い未熟な技術をハッキングしたものであり、この主張は、ユーザーを認証するためにJWTを使用する完全に機能する例を提供するよりもおそらくさらに危険です。
このOATHの記事は役に立ちました。 このレポジトリに対してこのような強い反応を引き起こしたものの1つだと思いますが、問題のレポーターは、JWTを使用したCookieセッションで通常期待される機能についての議論であり、JWTの主要な利点のいくつかを損なうものです。ステートレスにすることができます。 永続ストレージを組み込むことで状態を導入し、JWTの主なユースケースの1つを排除し、Cookieを使用して成熟したものを再実装します。
とは言うものの、複雑なアプリは、単一のHTTPリクエストの有効期間を超えて処理されるアクションのトランザクションリクエストの場合でも、状態の検索を必要とする傾向があります。 これにより、JWTの使用が妨げられることはありませんが、トランザクションでJWTが果たす役割を検討するために一時停止する必要があります。 リソースへのアクセスを許可するJWTがあり、リソースにはサービスへのアクセスを拒否するユーザーの状態があることは問題ないと思います。 この場合、期限切れが必要なのはJWTではなく、JWTを使用してサービスにアクセスしているユーザーの状態です。

トランスポートメカニズムとしてCookieを使用するようにさらに拡張すると、別の利点がなくなり、Cookieの使用に戻りますが、通常のライブラリ機能を無視し、機能を最初から書き直すと、タイムアウトなどが重複するため、さらにあいまいさが生じます。CORSについて前述したときおそらく、Cookieで複数のドメインを使用することの難しさを明確に指摘する方がよいでしょう。 もちろん、ワイルドカードドメインを設定することはできますが、それらが十分に異なる場合、従来のセッションCookieはすぐに扱いにくくなります。 ほとんどの開発者は、複数のドメインの保護されたリソースにアクセスするために認証済みクライアントを必要としないと主張できますが、これはエキゾチックなエッジケースではなく、はるかに一般的な方法になりつつあります。
認証されたセッションの管理を探求し始めた新しい人としての意味で、これはWebアプリのリソースへのアクセスを最も単純な意味で認証されたユーザーに制限する方法を学ぶための適切な方法ではないかもしれませんが、 JWTは、認証されたセッションの開始点としてより目立つようになるだけです。長い間セッションCookieを使用してきたため、これを却下するだけでは、誰もがセッションCookieから始めて、JWTについてのみ学習して使用する必要があると信じるには不十分です。ドメイン間でCookieを共有できない、サードパーティのAPIにアクセスする必要がある、サーバーを確認せずに有効期限を判断できる必要がある、モバイルデバイスでのユーザーログイン資格情報の保存などについて質問する必要がある場合など。 。

最上位のトラフィックサイトを実行していない限り、ステートレストークンの利点を無関係なものとして過小評価することは正しくありません。 新しい状態レイヤーを導入して問題を解決する場合でも、サーバーからのセッションの分離には多くの利点があります。

@nelsonic 4744cd1bb8991bc4057c749f86007fcecac19d1dを見ると、はるかに明確な表現のようです。 ただし、ヘッダーには変更が反映されていないようです。

@ pscott-au：最新のSPAおよびモバイルアプリ。

これは、選択したセッションメカニズムと_完全に_直交しています。 言うまでもなく、今日のSPAであるほとんどのものは、そうであるべきではありません。 （Webアプリではなく）WebサイトにSPAを使用すると、Webが破損します。

複雑なアプリを構築する際に人々が直面する現実の課題の多くは、ほとんどの場合、あまりエレガントに解決されていないか、少なくともCookieセッションを使用することで問題があるように思われます。

そのような？

問題のポスターが作成する認識は、JWTは、最新のアプリには適さない、信頼性の低い未熟な技術をハッキングしたものであるというものです。

いいえ、そうではありません。 テクノロジーとしてのJWTはひどいものではありません（仕様に疑わしい決定があったとしても）-セッションは意図された目的ではなく、そのユースケースには適していません。

私はツールが悪いと言っているのではなく、あなたがそれを間違って使っていると言っているのです。

そして、この主張はおそらくよりもさらに危険です

その理由は何ですか？

このOATHの記事は役に立ちました。

ポイントごとに対処する：

• ステートレス、スケーラブル、および分離：これは理論上の利点であることをすでに認識していますが、実際にはほとんど誰も必要としません。 また、Auth0には既得権があり、開発者としての利益にはならないことも考慮する必要があります。_ "Auth0などのサードパーティサービスはトークンの発行を処理できるため、サーバーはトークンの有効性を確認するだけで済みます。 "_ちなみに、認証のアウトソーシングは_ひどい_アイデアです。
• クロスドメインとCORS：完全でまったくナンセンス。 これは、トークンがセッションデータを_含む_かどうかとは完全に別の_storagemethod_について説明しています。 セッションIDを手動で送信することも、JWTをCookieに保存することもできます。 JWTとセッションとは何の関係もありません。これは、「Cookieとトークン」を比較することは_そもそも意味がないため_、記事の作成者の偏見/無知を示しています。 また、このセキュリティの問題を完全に無視します。
• JWTにデータを保存する：機能ではありません。 同じことがセッションにも当てはまります。 ちなみにクッキー。
• パフォーマンス：これは、ほとんどの場合、「ステートレス」ポイントの繰り返しです。ただし、暗号化検証がセッションデータ処理のパフォーマンスでRedisのようなものを必ずしも打ち負かすことができるかどうかはまったく明確ではありません（RDBMSとの比較は非現実的です）。 、これは、ほとんどすべてのWebアプリのパフォーマンスの最適化としてもまったく重要ではありません。 これは「時期尚早の最適化」と呼ばれ、非常に正当な理由から広く推奨されています。
• モバイル対応：ナンセンス。 HTTPライブラリがCookieをサポートしていない場合は、_より適切なHTTPライブラリを探してください_。 Cookieは問題なくサポートされており、HTTPヘッダーにすぎません。

いいえ、その記事には、私がまだ取り上げていないJWTの新しい利点は含まれていません。 それは、時々利益（無国籍）をすべてのアプリケーションに適用されるもの（そうではない）として誤って表現し、無意味な比較を行い、残りのセッションのパフォーマンスを強調しすぎます。

このレポジトリに対してこのような強い反応を引き起こしたものの1つだと思いますが、問題のレポーターは、JWTを使用したCookieセッションで通常期待される機能についての議論であり、JWTの主要な利点のいくつかを損なうものです。ステートレスにすることができます。

私が言ったように、これは実際にはほとんど利益になりません。 この同じ無国籍のポイントを何度も繰り返し続けることができますが、それはもはや有効または適用可能にはなりません。 これは、汎用要件ではありません。

リソースへのアクセスを許可するJWTがあり、リソースにはサービスへのアクセスを拒否するユーザーの状態があることは問題ないと思います。 この場合、期限切れが必要なのはJWTではなく、JWTを使用してサービスにアクセスしているユーザーの状態です。

この場合、ある種の通常のセッションIDに勝るメリットはまったくありません。

[...]先にCORSについて言及したとき、Cookieで複数のドメインを使用することの難しさを明確に指摘したほうがよいかもしれません。 もちろん、ワイルドカードドメインを設定することはできますが、それらが十分に異なる場合、従来のセッションCookieはすぐに扱いにくくなります。

これも、ポイントに完全に直交しています。 これは純粋に識別子をどこに保存するかについてであり、識別子がセッションデータを単独で含むかどうかについてではありません。 また、セキュリティリスク。

ただし、JWTの使用は、認証されたセッションの開始点としてより顕著になるだけです。

そして、それは私にとって非常に心配です。なぜなら、その顕著な使用は無知と誇大宣伝に基づいており、多くのセキュリティ問題を伴うからです。 これは大きな後退です。

長い間セッションCookieを使用してきたため、これを却下します

私はそのようなことは何も言わなかった。 JWTがセッション管理に関して_客観的に劣っている_理由について、いくつかの_非常に_明確な理由を提供しました。

ドメイン間でCookieを共有できないことがわかった場合にのみ、JWTについて学習して使用します

その場合、セキュリティの問題。 クッキーは_オプションではありません_。

またはサードパーティのAPIにアクセスする必要があります

セッションとは無関係です。

または、サーバーをチェックせずに有効期限を判別できる必要があります

サーバーはセッションを明示的に無効にする機能を保持する必要があるため、不可能です。 ユーザーがパスワードを変更したとき、または他のセッションを強制的に閉じたとき。

または、モバイルデバイスなどでのユーザーログインクレデンシャルの保存について質問します。

クッキー。 終わり。

最上位のトラフィックサイトを実行していない限り、ステートレストークンの利点を無関係なものとして過小評価することは正しくありません。 新しい状態レイヤーを導入して問題を解決する場合でも、サーバーからのセッションの分離には多くの利点があります。

しかし、あなたは私がまだ対処しておらず、私の結論で考慮に入れていないそれらのどれにも言及していません。 申し訳ありませんが、あなたは斬新なアプローチであるために斬新なアプローチを擁護し、さまざまなアプローチの_客観的で技術的な特性_を完全に無視しています。

それがいわゆる「誇大広告」であり、非常に有害です。

ステートレス：アプリがオフラインで機能し、何らかの意味を保持する必要がある場合に重要です。

オフラインアプリケーションは認証を必要としません、_まったく_。 定義上、他のシステムとの相互作用はありません。

クロスドメインクレデンシャル認証：複数のサーバーを使用してアプリケーションをマイクロサービスに分割する場合に重要

正しい。 ただし、この場合、JWTを_セッションメカニズムとして_使用せず、セッションと_交換_できる使い捨てトークンとして使用します。 この2つには非常に大きな違いがあり、トレードオフがあります。

（編集：もちろん、これは_stateful_マイクロサービスを前提としています。'stateful 'では、セッションを参照するのではなく、サービス自体を参照します。ステートレスタスクを実行するマイクロサービスの場合、セッションをまったく使用せずにシングルユーストークンで十分です。シングルユーストークンはアプリケーションサーバーによって発行されます。マイクロサービスと通信するアプリケーションサーバーの場合、JWTも問題ありません。ここには「セッション」の概念はなく、トークンの失効は署名キーを変更することで実行できます。）

JWTの有用性を否定し続けることができます

繰り返しますが、私はそのようなことはしていません。 これらは完全にあなたの言葉です。

私がより詳細を提供しようとすると、あなたは私のケースを無関係または悪い慣行として却下します..私の意見では間違っています。

それなら、「それは間違っている」と言うだけでなく、なぜそれが間違っているのかを詳しく説明することを期待します。 そして私がそれを額面通りに受け取ることを期待しています。 私はあなたが提供するすべての点に正確にこの理由で具体的に取り組んでいます。

iOSログインセッションを管理するためにCookieに依存することは、デフォルトでは最善の解決策ではありません。

どうして？

クッキーは悪用される可能性があります

それは空のステートメントです。 誤用された_方法_？ そして、これはローカルストレージに保存されている値にどのように適用されないのですか？ そして、「Cookie」がセッションメカニズムではなくストレージメソッドであるとすると、これはJWTと何の関係があるのでしょうか。 「JWTとCookie」を比較すると、リンゴとオレンジが比較されますが、同じクラスのものではありません。

セッション管理のためのJWTの使用は、Cookieセッションとは異なり、プロパティも異なります。これにより、JWTが劣ることはありませんが、適切なソリューションを設計する際の操作パラメーターの基準が異なります。 クッキーを使用したい場合はクッキーを使用してください-要件を満たしている場合はクッキーを使用してください-なぜ他の人が他のアプローチを検討するのを防ぎたいのですか？

私は違います。 JWTが適切なソリューションである場合、私は_非常に明確に_示された例外を持っています。 また、JWTが汎用セッションメカニズムとして不適切であることを_非常に明確に_示しました。 私の口に言葉を入れるのをやめなさい。

ログインセッションは、永続ストレージを備えたWebサーバーに対して認証するためだけに価値があるという考えは、同じJWTを検証し、新しいCookieを作成する必要がない代替プロバイダーによって提供されるデータサービスが必要な場合があるという事実を無視しています。 。 これはどのようにセッションとは無関係ですか？

さまざまな目的で、JWTとセッションの両方を使用できない理由はありません。 それのためにすべてを単一のメカニズムに靴べらしようとすることは、_完全に_誤った方向に進んでいます。 適切なツールを使用してください。「新しいCookieを作成する必要がない」というのは完全に恣意的な指標であり、現実的には、それが意味するメリットではありません。

セキュリティ上の問題が発生した場合は、それらを特定してフラグを立てます。これらはショーストッパーではない可能性がありますが、決定を下す際に知っておくと役立つ場合があります。 あなたは、セッションCookieをすべてのhttpアプリに使用する必要があると述べ続けているため、これを認めていないか、可能性を考慮していません。これはばかげています。

また。 いいえ。 I.言った。 私の口に言葉を入れるのをやめなさい。

パスワード変更の終了やサービス制限の管理などの特定のルールを適用するためのセッションの役割について引用した例は、セッションCookieの組み込み機能ではなく、このアプローチで通常使用される機能にすぎません。

これは、アーキテクチャ的に、ある種のステートフルセッションを_必要とする_機能です。 私はこれがセッションCookieによって提供されると主張しているのではありません-ステートレストークンでは_不可能_であると主張しています。

セッションの存続期間中、データベースをチェックせずに認証されたアクセスを提供するソリューションが非常に快適である場合、なぜこれがこのアプローチの失敗であると主張するのですか。

繰り返しますが、私が言ったことで

特定のコントロール（何らかの終了可能なセッションが必要な場合）を必要に応じて導入できると提案した場合、Cookieにはこれが組み込まれているため、他のアプローチを検討しないでください。 この種の制御を実装することは、Cookieを介したJWT認証セッションを妨げるほどの重大なオーバーヘッドではありません。

ポイントはオーバーヘッドではありません。 重要なのは、うまく機能することが知られている、実証済みのソリューションを使用することです。 独自のセキュリティを再実装することは、どのような状況でもひどい考えであり、これも含まれます。

Cookieのリクエスト数を無視し、パフォーマンスに関する唯一の考慮事項はルックアップであることを提案します。 リフレッシュなどを調整し、依存する必要があります..ああ気にしないでください...（ここで諦めました）

あなたも何について話しているのですか？ Cookieの「更新」は、新しいCookieを送信することにより、HTTP応答でインラインで処理されます。Redisの例ですでに説明したセッションストアの更新以外に、ここで特別なことは何もありません。 他にパフォーマンスに関する考慮事項があると思われる場合は、それらを_リストしてください_。

Cookieがドメインに制限されていることを気に入るかもしれませんが、Cookieをクロスドメインで使用できるようにすると、セキュリティ上の問題が発生し、Cookieの使用が妨げられると考えるかもしれません。

繰り返しますが、私が言ったことで

JWTは、すべてのセッションCookieを置き換える次のことではありませんが、（セッションの管理に使用される場合）あなたが示すほど深刻な嫌悪感でもありません。

はい、そうです。 セッションにJWTを使用したいと思う唯一の理由は、代替手段がより悪いか不可能であるためです。これは、非常にまれなエッジケースです。

必要に応じてこのアプローチに加えることができるさまざまな改良点や、その進化の複雑さが従来のセッションベースのアプローチとどのように比較されるかについては言及せずに、セキュリティを絶対的なものとして扱います。

私はセキュリティを絶対的なものとして扱っているのは、それが絶対的なものである場合だけです。 また、それを解決するための可能な方法についても説明しました。最終的な結果はさらに悪いため、セッションと比較して、それらがどのように適切な解決策ではないかを説明しました。 私が見逃しているケースや解決策があると思われる場合は、それについて言及してください。 「他のオプション」が何であるかを実際に説明することなく、漠然と「他のオプション」をほのめかすのはやめましょう。 今、私が知る限り、あなたはブラフしています。

誇大広告ではありません-無知に基づくものではありませんが、テクノロジーが提供できる最も厳格なセキュリティを提供することを目的としていないサービスの相互認証を必要とするハイブリッドアプリを構築するときに定期的に直面する問題に対する有効な解決策であり、正当な理由で-非常に実用的-非常に広く採用-すべてががらくたになるわけではありません。

アサーションを繰り返しても、それはもはや真実ではありません。 これが誤りである理由についてはすでに説明しましたが、誇大広告の理由でセキュリティを危険にさらすことは容認できません。

Cookieによって提供されるよりも細かい粒度でセッションを制御する柔軟性を持っている私たちの一部にとって、より大きな柔軟性が得られます-ユースケースが表示されない場合は問題ありません-多くのハイブリッドアプリを構築する場合は、おそらくあなたがそうするでしょう。私よりもあなたが提示するいくつかのポイントに対する反論をより明確に表現できるようになります。

「より優れた柔軟性」はありません。 繰り返しになりますが、あると思われる場合は、その方法を説明してください。

とにかく-あなたは私よりもはるかに雄弁であり、あなたの立場で明らかに揺るぎないです

いいえ。私の見解を変えたいのであれば、誰かがしっかりした、よく議論された、技術的に正しい議論を提供することを期待しています。 あなたはそうしていません。

私がこのような容赦ないアプローチへの執着を最後に持っていたのは、誰かがダイジェスト認証をセッションCookieに置き換えてはならないと主張していたときだったことを覚えています。

...そしてそれはそのような誤謬の完璧な例でしょう。

肝心なのは、あなたの発言の半分は、私が一度も発したことも、暗示したことも、意図したこともない言葉を私の口に入れているということです。 残りの半分は、セキュリティの不必要な妥協を主張するか、それ以上踏み込むことなく「他の利点」または「他の解決策」があることについて手に負えない主張をします。

率直に言って、私はこれにうんざりしています-この議論が建設的な方向に進むとは思わず、スレッドを混乱させています。 私が返答し続ける唯一の理由は、あなたの議論のないことによって人々が誤った情報を与えられるリスクがあるからです。

その概念をサポートする技術的な議論がないにもかかわらず、JWTが聖杯であると信じ続けたい場合は、それがあなたの選択です-しかし、_実際の技術的な議論_を考え出さない限り、_私を納得させることはできません_。そして何度も何度も誰も助けるつもりはありません。

議論全体にわたるスキミングについての私のポイントを要約すると、次のようになります。

• JWTはセッション用に設計されていませんが、署名されたクレームを転送するために設計されており、通常は使い捨てです。
• JWTは、トークンを無効にできないこと、古いデータの問題、およびそれを機能させるためにテストされていない実装を作成する必要があるため、セッションには適していません。 これらはセキュリティの問題です。
• 「CookieとJWT」は有効な比較ではありません。 1つはストレージメカニズムで、もう1つはトークン形式です。 JWTを使用しているかどうかに関係なく、Cookieはません。 Cookieの外部にあらゆる種類のトークンを保存することは、セキュリティの問題です。
• 非常に大規模に運用しているためにステートフルセッションを使用できない場合があります。その場合、JWTは利用可能な「最も悪い」オプションになる可能性がありますが、これらのケースはまれであり、主要なサイトで作業しない限り、 Reddit、あなたはおそらくそれらに遭遇することはないでしょう。

（ちなみに、Redditはステートフルセッションを使用しています。）

このリポジトリの目的は、モバイルハイブリッドSPAの実装への道を開くことであり、Cookieセッションの代わりにJWTを使用することは一般的でほぼ標準的なアプローチであると私は信じています。
この要因の1つは、SPAが実際には異なるプラットフォーム上の複数のドメインにわたるマイクロサービスへのアクセスを必要とする場合に、Cookieがドメインにバインドされる際の問題です。 JWTは、このコンテキストでのCookieの制限に対する適切なアプローチです。 OAUTHまたはOAUTH2アプローチを使用すると、セキュリティの観点からはより堅牢になりますが、多くのアプリケーションでは必要とされない複雑さが生じます。 AUTHトークンのネゴシエーションに依存しないJWTベアラーセッションは、JWTの誤用ではありませんが、シンプルさを実現するため、およびより多くのセキュリティによって提供される追加のセキュリティよりも迅速な実装から多くを得る必要があるアプリケーションのために、安全性の低いアプローチのアプリケーションです。堅牢なアプローチ。 迅速な実装を合理化すると同時に、他のアプローチよりも使い捨てトークンへのより明確な移行パスを提供します。
セッションCookieの代わりにJWTBearerトークンヘッダーを使用することに対する反発とビトリオールの一部は、実際、Cookieの進化または改善としてそれらを提示する一部の人々に基づいていますが、そうではないことに同意します。 私のユースケースと、Cookieを使用してそれらにどのようにアプローチするかを検討してください。
認証セッション管理にJWTを使用する場合は注意が必要であり、欠陥を明示する必要がありますが、コンテキスト外で常に使用されている役に立たない誇大広告は誤解を招き、正しくないため、それらを却下します。
JWTを使用すると、クライアントがサーバーに接続するたびにCookieを更新する必要がなくなります。 セッションCookieを使用するのと同じくらい簡単にこのチェックを拡張できますが、データベースをチェックしなくても、かなりの信頼性を保証できます。
JWTを使用すると、Cookieがブロックされているクライアントが、非表示の投稿変数などをバックフィルとして使用するように強制されることはありません。
複数のサービスでJWTを使用すると、認証を必要としないが、JWTにラップして渡すことができるuidなどの単純なデータフィールドの有効性を示す必要があるサービスが可能になります。
JWTアプローチは、より洗練されたOAUTHアプローチに適しています。
JWT RESTリクエストは、サービスにアクセスする前にクレデンシャルを投稿したり、Cookieのリクエストを要求したりすることなく行うことができるため、REST / SPAの実装を簡素化できます。
ベアラーヘッダーまたはCookieヘッダーの使用は、セキュリティに関しては劇的な違いはありません（ドメインの制限が正当に望ましくない場合を除きます）（注：私はあなたの口に言葉を入れていませんが、あなたがほのめかしていることを解釈しようとしていますセキュリティが悪い）
モバイルアプリケーションのように長期間の不在が一般的/予想される場合、CookieはJWTアプローチよりも望ましくない場合があります。 資格情報の自己検査へのより明確なパスがあると、サーバーにチェックインしなくても動作が容易になります。
オフライン期間が長くなる可能性のあるセッションのユースケースがあることに同意する場合、セッションは必ずしもステートフルではありません。
クライアントとサーバーの観点から、セッションが複数の状態で正常に存在できることを受け入れることができる場合は、サーバーとの接続が長期間ない期間を含むユースケースに近づくことができます（バッチ更新のためのユーザーデータの収集など）。再接続時）。 セッションが期限切れになり、データの別のレイヤーを管理せずに更新が必要であることを認識して、クライアントがより効果的に動作できる場合があります。 また、パスワードが変更された後などでもJWTをセッション検証として使用できると、データをビジネスロジックレイヤーに渡して、リクエストの受け入れ方法を決定できるようになる場合があります。
あなたは私がブラウザなどでの実装をほのめかしていると私が推測するクッキーは安全であると私に言い続けます-ブラウザの外ではなぜそれらが本質的により安全であるのか分かりません-おそらくあなたは詳しく説明することができますか？
SPA / Hybridアプリでは、Cookieへの依存が必ずしも唯一の開始位置ではありません-ブラウザーによるCookieの処理に依存しても、ネイティブに近づくことはできませんが、UIWebViewなどへの依存が導入され、常にそうなるとは確信していません。期待どおりに動作します。
トークンは、必ずしも永続化されることなく、アプリの実行期間中メモリに保持できます-これは、Cookieの整合性に依存することと実際には同じではありません-少なくともブラウザ以外に存在するストレージ権限については、iOSでよりきめ細かい制御がありますそしてこれは、ブラウザのストレージアプローチに縛られるよりも適切だと私は思います。
クッキーは確かにオプションです-クッキーのみを使用しなければならないという法律はありません。
サーバーからのセッションの分離は、場合によっては悪いことかもしれませんが、常にではありません-JWTの使用を含む最新のアプローチは、新しい懸念をもたらすだけでなく、新しい柔軟性ももたらします。この柔軟性には、最も悪いアプローチだけが含まれているわけではありません。

私の立場を要約すると：
認証セッションソリューションの一部としてのJWTの使用は、セッションCookieによって常に切り詰められるとは限りません。
JWTは、利点を認識していて、単純な無効化を必要としない理由がある場合にセッションに適しています。
クッキーだけが解決策ではありません。
ステートレスセッションのユースケースは大規模だけではありません。JWTヘッダーを使用してドメイン/サービス間で認証を行うことは、セッションCookieの代わりにそれらを使用する正当な理由です。

私のユースケースと、Cookieを使用してそれらにどのようにアプローチするかを検討してください。

もちろん。

JWTを使用すると、クライアントがサーバーに接続するたびにCookieを更新する必要がなくなります。

これは、セッションCookie、JWTを含むCookie、およびJWTトークン自体についても同じです。有効期限が近づいている場合にのみ明示的に「更新」する必要があります。 ここに違いはありません。

JWTを使用すると、Cookieがブロックされているクライアントが、非表示の投稿変数などをバックフィルとして使用するように強制されることはありません。

Cookieをブロックするユーザーは、ほぼ確実にローカルストレージやその他の永続性対策もブロックします（Cookieをブロックするのとまったく同じ理由で）。 プライバシー拡張機能も同じです。 繰り返しになりますが、「JWTとCookie」は_有効な比較ではありません_。ユーザーがCookieをブロックすると、トークンを_とにかく_永続化できなくなります。 JWTであるかどうかは関係ありません。

（ユーザーがCookieを大量にブロックする場合、とにかくデータの永続性を持たないことをすでに選択しているため、Cookieをブロックするユーザーの認証をサポートしようとすることは、少し失われた原因です。これは、それに伴うトレードオフであり、完全に技術的に合理的です。トレード・オフ。）

複数のサービスでJWTを使用すると、認証を必要としないが、JWTにラップして渡すことができるuidなどの単純なデータフィールドの有効性を示す必要があるサービスが可能になります。

分散アーキテクチャでの使い捨てトークンに対処する私の以前の投稿（3番目の段落）の編集を参照してください。 これらはセッションではなく、永続的であるべきではないため、私が説明した問題はそこには当てはまりません。

JWTアプローチは、より洗練されたOAUTHアプローチに適しています。

OAuthは使い捨てトークンを利用します。 セッションの代わりにはなりません。 繰り返しますが、私の前の投稿の編集を参照してください。

JWT RESTリクエストは、サービスにアクセスする前にクレデンシャルを投稿したり、Cookieのリクエストを要求したりすることなく行うことができるため、REST / SPAの実装を簡素化できます。

彼らはできません。 それでもJWTを_なんとか_取得する必要があります。つまり、サーバーによって発行される必要があります。つまり、サーバーにJWTを要求する必要があります。 サーバーがCookieを返すか、別のヘッダーまたは値を返すかは関係ありません。 繰り返しになりますが、「CookieとJWT」は有効な比較ではありません。

ベアラヘッダーまたはCookieヘッダーの使用は、セキュリティに関しては劇的な違いはありません（ドメインの制限が有効に望ましくない場合を除きます）。

ここで議論が見られない。

モバイルアプリケーションのように長期間の不在が一般的/予想される場合、CookieはJWTアプローチよりも望ましくない場合があります。 資格情報の自己検査へのより明確なパスがあると、サーバーにチェックインしなくても動作が容易になります。

これはメリットではありません。とにかくサーバーと通信するまでトークンは必要ありません。そのため、リクエストを送信して、発生したときに403を処理することができます。 本質的にサーバーとの通信を伴う（つまり、認証された要求を行う）ことをサーバーに要求することを避けようとすることは意味がありません。

言うまでもなく、セッションの有効期限が切れているかどうかを事前に知りたい場合は、このために別のCookieを送信するだけです。 これはアプリケーションのUXヒントにすぎないため、その信頼性を検証する必要はありません。また、クロックスキューや署名キーの変更による予期しない認証の失敗に対処する必要があります。

SPA / Hybridアプリでは、Cookieへの依存が必ずしも唯一の開始位置ではありません-ブラウザーによるCookieの処理に依存しても、ネイティブに近づくことはできませんが、UIWebViewなどへの依存が導入され、常にそうなるとは確信していません。期待どおりに動作します。

そうではありません。 ブラウザであろうとなかろうと、妥当なHTTPライブラリはCookieをサポートします。 Cookieは、ブラウザ専用ではありません。他のCookieと同様にHTTP機能です。

サーバーからのセッションの分離は、場合によっては悪いことかもしれませんが、常にではありません-JWTの使用を含む最新のアプローチは、新しい懸念をもたらすだけでなく、新しい柔軟性ももたらします。この柔軟性には、最も悪いアプローチだけが含まれているわけではありません。

そのような「柔軟性」の具体的な例はまだ見たことがありません。

セッションソリューションの一部としてのJWTの使用は、必ずしもセッションCookieによって切り詰められるとは限りません。

それは非常に曖昧な声明です。 ソリューションの_一部としてJWTを使用することと、ソリューション全体としてセッションCookieを使用することを比較しています。 これらは正反対ではありません。たとえば、SSOシステムや分散アーキテクチャの場合、多くの複雑なアーキテクチャでは、セッションCookieと使い捨てJWTトークンの両方を組み合わせる必要があります。

JWTは、利点を認識していて、単純な無効化を必要としない理由がある場合にセッションに適しています。

いいえ。JWTトークンは、セッションCookieで要件を満たすことができない場合の_最後の手段_です。

クッキーだけが解決策ではありません。

技術的に正しい。

ステートレスセッションのユースケースは大規模だけではありません。

これは私が知っている唯一のユースケースであり、このスレッド全体で言及されている他の有効なユースケースは見たことがありません。 ステートレストークンについてではなく、ステートレスセッションについて具体的に話していることに注意してください。

これをお願いします-3つの異なるサービス（おそらく異なるコンテナインフラストラクチャなど）を使用するアプリケーションをデプロイし、セッションCookieに依存してそれらをアプリに統合するにはどうすればよいですか？ 認証サービスをセットアップし、それを別のサービスから切り離したい場合は、共有プロキシCookieセッションハンドラーを実行するための最良のアプローチですか？ これはエッジケースですか？
長時間実行されるJWTを使用してセッションを追跡するよりも、Cookieによってセキュリティ、柔軟性、標準への準拠が向上する方法を教えてください。 オンデマンドでセッションを終了できることを望まない、または気にしないと仮定すると（ただし、これはCookieの固有の利点ではなく、リクエストの処理において）、すべての投稿でBearerヘッダーを使用して応答します。すべてのヘッダーに含まれるセッションJWTを取得するための認証プロンプト/投稿の失敗-私は愚かかもしれませんが、これがどのように安全性が低いのかわかりませんか？ Cookieの詳細は、トークンと同じようにハイブリッドアプリで利用できますが、永続性を制御することはできません...これがなぜこのような悪いアプローチであるのか理解できないと思います。 確かに、JWTを取得するには資格情報を提供する必要がありますが、各サービスではなく、一度だけ提供します。

これをお願いします-3つの異なるサービス（おそらく異なるコンテナインフラストラクチャなど）を使用するアプリケーションをデプロイし、セッションCookieに依存してそれらをアプリに統合するにはどうすればよいですか？

3つのサービスの機能によって異なります。 詳細を教えていただけますか？

認証サービスをセットアップし、それを別のサービスから切り離したい場合は、共有プロキシCookieセッションハンドラーを実行するための最良のアプローチですか？ これはエッジケースですか？

アーキテクチャに応じて、認証サービスが認証の成功を示す使い捨てのJWTトークンを発行し、オプションでユーザーの「プロファイル情報」を含めることができます。 次に、アプリケーションに応じて：

1. 通常のWebサイトの場合：認証サービスは、アプリケーションサーバーの認証ページにリダイレクトします。 JWTトークンをクエリパラメーターとして渡します。 アプリケーションサーバーはトークンを検証し、ユーザーにセッションCookieを提供します。
2. SPAの場合：認証サービスは、生成されたトークンを（JSON？）応答で返します。 フロントエンドアプリケーションは、パラメータとしてトークンを含めて、アプリケーションサーバーの認証エンドポイントにHTTPリクエストを送信し、アプリケーションサーバーによる検証後、セッションCookieを受信します。
3. スタンドアロンアプリケーション（デスクトップまたはモバイル）の場合： SPAと同様ですが、ブラウザーのフロントエンドアプリケーションではなく、CookieをサポートするHTTPライブラリを使用します。

どちらの場合も、JWTトークンは（クロックスキューを考慮して）5分間のみ有効であり、アプリケーションサーバー上のセッションと交換するために1回使用されます。 トークンにプロファイル情報を含めると、認証サービスはアプリケーションから完全に切り離されたままになります。

編集：スタンドアロンアプリケーションケースを追加しました。

SPA /ハイブリッドモバイルアプリ開発シナリオにいると仮定しましょう。 また、セッションにJWTを使用していると仮定します（認証トークンとベアラートークンを使用したOUATHではありません）。ログインしてベアラートークンを受信するだけです。
各セッションが5〜15秒ごとに3つのサービスすべてにリクエストを送信するリアルタイムアプリケーションがあると想像してみてください。 多くのユーザーがログインしてステータスをすばやく確認したり、GISデータなどを投稿したりするため、平均使用時間は1分未満ですが、アプリを起動し、閉じて、クレデンシャルなどなしで3日後に再起動します（ここではほとんど関係のない詳細を追加しますが、私をクッキーから遠ざける傾向があるもの）

例として、グラフクエリサービス、Dockerラックスペース上のマッピングまたはGISサービス、およびユーザープロファイルデータを管理するためのpostgresdbへのRESTインターフェイスを使用してAWSサービスを作成したとします。 すべてのRESTサービスへのヘッダーリクエストで同じJWTを使用し、共通のシークレットに対して検証して、JWTからの検証を1回発行することができます。
それらが独自のコンテキスト内でステートフルであるが、共有コンテキスト内では大まかにしかないと仮定しましょう。
これらは、JWTをセッショントークンとしてベアラートークンとして使用する提案されたソリューションと一致する問題の仕様であり、同様の環境を前提として、比較できるようにセッションCookieを使用してどのようにアプローチするかを尋ねています。

それらはすべて、ユーザーが本人であるという合理的な信頼を必要としているとしましょう。
私の解決策は、認証のためにHTTPヘッダー内のすべてのサービスで使用される資格情報の投稿に応答してJWTトークンを生成することです。検証は、すべてのサービスで共有されたJWTシークレットを使用して行われます。
認証サービスはトークンを生成し、ログイン時にそれを返します。 トークンは、異なるドメイン上の他のすべてのサービスへのヘッダーリクエストに含まれています。 Cookieを使用する場合は、ドメインごとに新しいCookieを確立する必要があります。 JWTに自信を持って依存できるのに、新しいリクエストを行うサービスが受信したhttpごとにCookieを検証または取得する必要があるのはなぜですか？ 5つのサービスがある場合、5つの異なるセッションCookieを管理し、これらすべての間の調整を確実にする必要があります。 多くの場合、これは正しいアプローチである可能性がありますが、多くの場合、実装が迅速で簡単で、はっきりと見える深刻なセキュリティホールを公開しないものには、過度に複雑だと思います。
なぜJWTの時間枠を制限するのですか？ Cookieは、サーバーとの定期的な接続を前提としているため、従来は短命でした。すぐに期限切れにしたくないが、再認証のトレードオフの方がリスクが高いと判断したため、古いセッションを長続きさせて満足している場合はどうでしょうか。

あなたの状況を正しく理解していれば、3つではなく9つのリクエストが毎回バウンスしています。確立されたセッションを確認するために認証サーバーが起動しています。 私はより多くのコードとより多くの可動部分を持っています。 期間ごとにセッションを終了できるという利点がありますが、それが要件でない場合はどうなりますか。 ユーザーが終了してからさらに48時間投稿されたデータを受信し、新しいリクエストに認証サーバーを使用することを気にしない場合でも、不要なものを除外できますか？

このユースケースでは、セッションの粒度が適切に設定されているため、わずかな時間の偏りは関係ありません。セッションCookieの場合と同様に、適切なタイムアウト期間に認証サーバーを介してJWTを更新するクライアントを実装します。 'profile'に関しては、共通IDとして共有uidを使用するだけでよく（私が正しく理解している場合）、サーバー側の実装にはJWTに署名/検証するための共有シークレットが含まれています。

提案されたアーキテクチャでは、JWTタイムアウトによって提供されるよりも細かい粒度でトークンを取り消す必要がないのに、代わりにセッションCookieを使用する必要があるのはなぜですか？
私が提案したアーキテクチャでは、サービスの状態間に依存関係を作成できますが、一元化され、デフォルトですべてを認証にブリッジする必要があることに依存するのではなく、これを設計できます。 重要なのは柔軟性です。依存関係を実現するという犠牲が伴いますが、これは最初からあなたの顔であり、すべてのプラットフォームに実装されているものの、フレームワーク間で異なる方法で処理されるものの上のレイヤーではありません。 node、php、およびエキゾチックなCookieセッションのデフォルト処理を使用してセッションのCookieの有効期限を実際に更新せずに更新することは簡単ではない可能性があるため、認証サーバー要求を直接投稿することをお勧めします。リクエストがありますが、クライアントのリクエストは3倍です。

私があなたの提案したアーキテクチャと一致するなら、私は確かに複数のクッキーにわたるタイムアウトに取り組む必要があります。 例として、クライアントがログインして、1時間で期限切れになる認証済みセッションCookieを受信した場合
そして40分後、彼らはこのセッションCookie値を最初のサービスに送信します。最初のサービスはローカルドメインCookieを発行する前に認証サーバーにクエリを実行します。内部の元の認証Cookieの有効期限をハックするか、サービスCookieのタイムアウトを20分に設定しますか。これが期限切れになると、認証Cookieの更新がトリガーされます。 明らかな解決策を見逃していない限り、これは簡単にスパゲッティの大きな山に変わる可能性があります。これは、いずれかのサービスを通じて更新できる単一のttlを持つ単一のJWTを使用することで完全に回避できます（これがトークンを拡張する方法を理解するライフ）または認証サーバーを介した更新を要求することによって。

古いデータへのアプローチについて説明することはできますが、このユースケースの問題の範囲は、（認証サーバーの観点から）古い資格情報の無効化に依存していないため、これは関係ありません。

認証されたセッション管理アプローチとしてJWTを使用することは、ハイブリッドモバイルアプリケーション内で実行されるクロスドメインサービスの認証されたセッション管理アプローチとしてセッションCookieを使用することと比較して、本質的に劣っており、正しくないというあなたの主張について話し合っていると私は理解しています。資格情報を再提供せずにデバイスを断続的に。

私は、提案されたアプローチが本質的に安全性が低いのか、それとも「正しくない」のかをあなたが主張するかどうかを確かめようとしています。 私が見ているように、このアーキテクチャの単純さには大きな利点があり、より単純なアーキテクチャとは見なされておらず、トレードオフされていないすべてのサービスにわたるセッションを管理するために必要な、より重いより複雑なソリューションによって提供される利点はありません。 このソリューションで、Cookieを使用してセッションを管理するのに経験したことのない問題がどのように発生するかを指摘できれば、それらを明示的に理解するのに本当に役立ちます（つまり、セキュリティがどのように危険にさらされているか）。

サービスはほとんど関係ありません-あなたが何をほのめかしているのかわかりませんか？

ステートフルサービスとステートレスサービスには違いがあります。

まあ言ってみれば [...]

これは、問題が何であるかではなく、問題をどのように解決するかを説明しています。 セッションでアプローチする方法を説明するように頼むときは、セッションを使用しないことをすでに想定しているため、役に立ちません。 代わりに問題を説明してください。

自信を持ってJWTに依存できるのはいつですか？

できません。

5つのサービスがある場合、5つの異なるセッションCookieを管理し、これらすべての間の調整を確実にする必要があります。

ありそうもない。 ステートフルサービスとステートレスサービスについての私の意見を参照してください。

多くの場合、これは正しいアプローチである可能性がありますが、多くの場合、実装が迅速で簡単で、はっきりと見える深刻なセキュリティホールを公開しないものには、過度に複雑だと思います。

認証とセッション管理、特に分散アーキテクチャでは、複雑です。 エンジニアが過去に可能な限り分散アーキテクチャを避けてきたのには理由があります。 「JustuseJWT」は、データの古さやセッションの無効化を完全に無視することで、これを理解し、実際よりも簡単なふりをします。

セキュリティホールはそこにあり、私はそれらを説明するためにいくつかの試みをしました-あなたがあなたに不明確な部分について特定の質問をしなければ、あなたがそれらをはっきりと見ることができないことは私が何もできることではありません。

なぜJWTの時間枠を制限するのですか？

私が与えた例では？ これらは、永続的な識別子ではなく、使い捨ての交換トークンとして意図されているためです。 それらを取り消すことはできないため、永続的な識別子にすることは望ましくありません。

Cookieは、サーバーとの定期的な接続を前提としているため、従来は短命でした。すぐに期限切れにしたくないが、再認証のトレードオフの方がリスクが高いと判断したため、古いセッションを長続きさせて満足している場合はどうでしょうか。

セッションを更新するリスクはありません。

プロファイルまたはクロックスキューを無視します-同様のシナリオでCookieを使用する場合に同じ問題が適用されるため、この仮説での説明に大きな影響を与えない詳細。

これらは、他のすべてのポイントと同様に、堅牢な認証システムの一部として重要です。 それらを無視することはオプションではありません。 繰り返しになりますが、これは「Cookie」についてではなく、セッションについてです。

セッションの場合、いいえ、同じ問題は適用されません。 一元化されたステートフルセッションストアは、データがまったく古くならず、プロファイル情報をいつでも取得できることを意味します。クロックスキューは、異なるシステム間で交換される有効性が制限されたトークンの問題です。

セッション管理アプローチは、リクエストごとの失効を必要とするセッションの定義への愛着に帰着する可能性があるため、JWTに対するあなたの異議を要約できるように見えます（および従来はユーザーが承認されていることを確認するための一部であった他のいくつかの機能アクセスする）およびそれらを更新することに関連する危険性（それらが傍受された場合）。 分散処理は新しい標準であり、複数のサービスが非常に一般的です。この種のアプローチをマルチサービスアーキテクチャに採用する場合は、その結果を完全に理解する必要があります。 分散データベースは長い間存在してきました。 DNSなどの分散データストアは当初から存在していました。 アーキテクチャの単純さは、既存の主要な標準を設計限界を超えて絞り込もうとするよりも多くの利点をもたらす場合があります。 サービスリクエストセッションでトランザクションACIDの問題を認識している場合、認証サービスにJWTセッション管理アプローチを採用して、主張するとすぐに複雑なインフラストラクチャになることに制約されることなく、可能性を十分に活用するべきではない理由はありません。厳しい制約に対処し、優れたソリューションとしてセッションCookieをシューホーン化してみてください。
@ joepie91-必要に応じて、プライマリ認証にCookieセッション認証を使用し、JWTを更新するためにこれを要求することができます。 繰り返しますが、クロスドメインセッションサービスアクセスにJWTを使用することは、ソリューションの一部として使用でき、必要に応じてCookieセッションも使用できます。 重要なのは、セッション管理の一部としてのJWTは、サービスのサブセットにアクセスする場合でも、役割のない邪悪なアプローチではないと私は信じているということです。
httpsセッションCookieにもリスクが伴います。SSLを通信するときにsslフラグが設定されておらず、Cookieをプレーンテキストとして渡すサイトがいくつあるかは驚くべきことです。 これはCookieセッションを危険にしますか？
私が見つけられると思われる最大のリスクは、コーダーがトークンを間違ったサーバーに送信することを許可し、トークンがサードパーティにこれらのセカンダリユーザーリソースへのアクセスを効果的に許可することです。 これはどこかに大きな赤い文字でフラグを立てる必要があり、これが起こらないようにするために開発者に強い責任を負わせます。 開発者は、必要なセキュリティ対策が講じられていることを確認するために適切な手順を実行する必要があり、このようなリポジトリは、これらのアプローチのいくつかを説明し、例に含める必要があります。 私の考えでは、これは、重要ではないサービスに対するクロスドメインの時間制限付きサービス認証の柔軟性に対して支払う許容可能な価格です。
複雑なソリューションを設計する場合、認証の最後にセッションCookieを含める可能性が高く、必要に応じて1回限りのトークンなどを含めるように拡張できます。 重要なのは、このようなことが可能であり、うまくいかずリスクを露呈する可能性がある場所もありますが、多くの場合、よりリッチでスリムなアプリケーションを構築する機会を提供します。このため、このリポジトリを提案どおりにビニングする必要はないと思います。問題ロガーによる。
私にとって、セッション文字列としてJWTを使用して両方の世界を最大限に活用しようとする傾向は、問題を引き起こしているようです。最も驚くべきことに、タイムアウト/ TTL期間が競合する可能性があります。 また、そもそも回避しようとしていたのと同じドメインアクセス制限が適用されるため、基本的な例にそれを入れると、そもそもなぜJWTを使用するのかと人々に尋ねられる可能性があります。

依存関係としてのJSの使用はごくわずかです。ハイブリッドモバイルSPAのコンテキストでは、JSフリークライアントに対応する必要はほとんどありません。 これが問題であることを示唆する一方で、redisがセッションストレージの効率的なオプションを提供すると同様に主張することは、少し矛盾しているように思われます。
JWTの有効期限は、更新（Cookieセッションが更新されるのとまったく同じ方法）によって処理するか、再認証を必要とするセッションタイムアウトを提供するという点で、役に立たないわけではありません。 JWTに署名することで、改ざんされていないことが保証され、永続ストレージサーバー側に対して検証するための絶対的な要件が排除されますが、これは必要に応じて行うことができ、多くの意見のある実装なしでCookieセッションと同じ結果を達成します。必要に応じてクロスドメインを利用する機能。 ハイブリッドモバイルアプリでは、ローカルストレージにCookieまたはJWTを保存することで、より詳細な制御が可能になります。 ブラウザ実装のセキュリティをめぐるローカルストレージの使用に対する異議は、ベンダーへの信頼と、これらのクレデンシャルの処理の受け入れの問題です。
柔軟性は多くのモバイルハイブリッドSPA開発者にとって有用ですが、制限が何であるかを理解する必要があります。
JWTは、署名キーを変更するだけで無効にできます。これにより、柔軟性が得られます。サービス間で共通の共有秘密署名キーを使用するか、ユーザーセッションごとにランダムに生成して、セッションCookieの一種の拒否の利点を実現できます。
最近のほとんどすべてのJSフレームワークはJWTをサポートしており、サポートしていない主要なプラットフォームを見つけるのは難しいでしょう。
JWTの使用には、OAUTHの背景と、Cookieセッションを使用することのトレードオフと利点を含める必要があります。 私にとって、複数のサービスを使用する平均的なモバイルハイブリッド開発者にとって実際の仕事上の利点はありますが、陥りやすい罠があります。 完全に説明するには、多くの例が必要になる場合があります。

承認のトークンとしてJWTを使用する私の_元の理由_は、単純なトークンを使用してそれを検索する必要がある場合とは対照的に、JWTがCPUバウンドであることを確認することです（_私の「古い」ラップトップは1秒あたり180kのJWTを確認できます_）。メモリ（またはデータベース）では、操作はI / Oバウンド（またはさらに悪いネットワークバウンド）になり、_かなり遅くなります_。
http://stackoverflow.com/questions/868568/what-do-the-terms-cpu-bound-and-io-bound-mean

セッション管理システムは、キーを使用してJWTが署名されていることを確認することで、JWTが有効であることを_最初に確認し、そうでない場合はメッセージを早期に拒否します。次に、セッションがまだ無効になっていないかどうかを確認します（ユーザーのログアウトなど）。 。

JWTがAuthorizationヘッダーのトークンとして使用されるように設計されていない可能性があることは知っていますが、他のセッション管理システムよりも高速であるため、なぜそれが「悪い考え」であるのかを完全に理解しているとは思いません。

注：「Cookieなし」の角度がこのreadme /チュートリアルを開始する正しい方法ではないことに同意します。 👍