JWTの思考

JWTは何ですか

JWT問題

練習のJWT

https://www.pingidentity.com/en/company/blog/posts/2019/jwt-security-nobody-talks-about.html

OpenIDの+ JWTs

私たちは前のOpenID Connectを使用してJWTで述べたように。プロバイダの問題クライアントにトークンのアイデンティティ。IDトークンは、ユーザーと認証の提供者の身元に関する情報が含まれています。JWTは、秘密鍵署名トークントークンアイデンティティ、プロバイダを使用することです。

OpenIDの接続はセキュリティがアイデンティティトークンを属性向上させるために多大な努力を費やしました。例えば、契約は「EXP」、「ISS」と「AUD」の文を使用する必要があります。また、トークンは、リプレイ攻撃を防ぐためにナンスが含まれています。そのため、これらの要件により、盗まれたIDトークンの悪用は非常に困難、不可能ではないになります。

OAuth 2.0のアクセストークンとしてJWTs

OAuth 2.0のJWTのアクセストークンは、別の良いユースケースです。このようなアクセストークンは、アクセスするクライアントアプリケーションに、このようなAPIとして保護されたリソースを、ことができます。自己完結型のトークン参照とトークン:OAuth 2.0のアクセストークンは2つの形で来ます。

  • サーバー側の基準点は、認証サーバによって保存されたメタデータトークン。これは、伝統的なセッション識別子のように、トークン識別子を参照するために類似しています。
  • トークンためJWTの形態に含まれます。これは、ペイロードすべてのメタデータを含みます。あなたのデータを保護するために、発行者は、プライベートキートークンを使用して署名しました。

伝統的なキャリアのOAuth 2.0トークンは、トークンです。人がけがをした場合、それはその無制限の使用があれば誰でもすることができます。参照することにより、認可サーバーのトークン撤退を破壊しました。トークンの自己完結型の場合、取り消しははるかに複雑です。

したがって、強く、できるだけアクセストークンのライフサイクルを短縮することをお勧めします。分または時間トークン寿命は非常に一般的です。利用日や生活の月にはお勧めしません。可能であれば、使用短期のアクセストークンとリフレッシュトークンは、セキュリティを向上させるために組み合わせる必要があります。

さらに、新仕様のコンテンツを保有機構の証拠を導入することにより、トークンプロパティベアラ処理します。

JWTsセッションオブジェクトとして

OpenIDを接続し、OAuth 2.0のプロトコル積極JWTsの弱点を解決しようとするような。残念ながら、我々はまた、多くのアカウントにこれらの予防措置を取らずに、アプリケーションJWTsそのアーキテクチャに組み込まれることを観察しました。

具体的な例では、クライアント上のストレージの許可JWTsアプリケーションの状態を使用することです。これは、非常に簡単に展開することになり非国家バックエンドの使用をサポートしています。

しかし、トークンを保持するトークンなどのクライアント。適切な短命または取り消し機構がなければ、この状況は非常に壊れやすいですように。

トークンの種類:

https://leastprivilege.com/2015/11/25/reference-tokens-and-introspection/

JWT一般的な使用とのセッション:

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

ステートレスJWT:セッションデータを含むA JWTトークンは、トークンに直接符号化されます。
ステートフルJWT:そのトークンA JWTは、セッションのためだけに参照またはIDが含まれています。セッションデータはサーバー側に保存されています。
セッショントークン/クッキー:Webフレームワークを長時間使用しているような標準(必要に応じて署名した)セッションID、。セッションデータはサーバー側に保存されています。

https://cheatsheets.pragmaticwebsecurity.com/cheatsheets/jwt.pdf

おすすめ

転載: www.cnblogs.com/victor2302/p/11776195.html