RESTベースのアプリケーションのJWT認証のエンタープライズパターン？

JWT仕様では、ペイロードとその送信方法のみが記述されていますが、認証プロトコルは開いたままになっているため、柔軟性が得られますが、残念ながら柔軟性により、アンチパターンや設計ミスが発生する可能性があります。

私はJWT認証のためによく考えテストされたエンタープライズパターンを探しています。これは使用または適応できますが、完全なものを見つけることができませんでした。

私が考えていたのは：

• Authorizationヘッダーが満たされていない場合、またはJWTトークンが無効であるか、期限切れの場合は、HTTP 401を送信します。
• 認証するには、/ login RESTチャネルを使用し、JSONオブジェクトとしてユーザー名とパスワードを送信します
• トークンを存続させるには、/ keepalive RESTチャネルを使用し、N（5）分ごとに呼び出し、新しいJWTトークンを受け取り、呼び出しごとに既存のトークンを置き換えます（トークンはM（15）分後に期限切れになります）。

ただし、私を邪魔するのは、その/ keepaliveチャネルの必要性です。一方、ユーザーが不在の場合（キープアライブが必要かどうかの決定がまだ満たされていない場合）であっても、認証が期限切れになるのを防ぐ必要があります。もちろん、これらは追加の呼び出しであり、プロトコルの追加の複雑さです。興味深いのは、サーバーが自動的にトークンを延長することです。セッションベースの環境では、タイムスタンプをリセットすることで発生しますが、ここではサーバーが新しいトークンを送信する必要があります。毎回ではなく、トークンがR（たとえば10）分で期限切れになると送信されます。ただし、応答本文に配置することは、JSON応答プロトコルを変更することを意味し（したがって、ソリューションは侵襲的で透過的ではありません）、クライアントが処理できる追加のHTTPヘッダーを配置することは、必ずしも良いパターンであるとは限りません。私'

私のオープンポイントに答える、すぐに使えるエンタープライズパターンはありますか？プロトコルドラフトは信頼できるアイデアですか？ゼロからデザインするよりも、すぐに使えるものを使いたいです。

JWT（Intro to JSON Web Token）は単なるトークン形式であり、認証はその仕様の範囲から完全に外れたものです。これは確かに認証システム内で一般的に使用されていますが、完全に異なるシナリオで使用することもできるため、その仕様に認証固有の制約を含めないことは理にかなっています。

認証に関するガイダンスを探している場合は、OpenID Connectファミリーの仕様を参照してください。さらに、システムがHTTP APIで構成されていて、それらのAPIへの委任アクセスを独自のアプリケーションまたはサードパーティのクライアントアプリケーションに提供することに関心がある場合は、OAuth 2.0仕様を参照する必要があります。

SAMLやWS-Federationのような追加の認証関連プロトコルがあり、エンタープライズシナリオでまだ広く使用されていますが、実装が非常に複雑です。

特定のオープンポイントについて：

• ベアラートークン認証方式はRFC 6750で定義されており、リクエストの実行方法と考えられるエラーコードに関する指示が含まれています。
• OAuth2とOpenID Connectはどちらも可能性を考えており、ユーザー名/パスワードをトークンと交換する方法を定義しています。
• 自己完結型/値によるトークン（JWT）の存続期間を延長する問題は、OpenID ConnectとOAuth2内で、リフレッシュトークンを使用して対処されます。

OAuth2とOpenID Connectは、以前のバージョンよりも実装が簡単であるように見えますが、かなり複雑なので、ある程度の注意を払う必要があり、かなりの時間とリソースを費やす気がある場合にのみ自分で実装します。これは、通常、負荷のかかるサードパーティのライブラリまたはサービスを使用する方が適切なオプションです。

最後に、これらのプロトコルは多くのシナリオをカバーしているため、状況によってはやり過ぎになる場合があります。

キープアライブチャネルは必要ないと思います。ペイロードには、ログイン時にトークンが生成されたときに、サーバーによって（expキーごとに、標準に従って）提供される有効期限情報を含めることができます（推奨されます）。有効期限が切れたトークンが使用された場合（これは明らかにサーバーによって決定され、署名が検証された場合にのみトークンの内容を信頼します）、サーバーはHTTP 401でトークンを拒否するだけで、クライアントに再認証を求めます。

一方、クライアントはプロアクティブになることができます。ペイロードセクションは暗号化されていません。クライアントはそれを読み取ることができるので、クライアントはリクエストが期限切れのトークンで送信されることを確認でき/login、トークンが期限切れの場合は再度呼び出します。

または、RESTではハイパーメディア情報を「状態のエンジン」として送信できるため、必要に応じて、実際にJWTを1回限りの使用で、有効期限も指定できます。次に、すべての要求が新しいJWTを生成します。このJWTは、hapi-auth-jwt2と同様に、クライアントへの応答で返されます。