RESTベースのアプリケーションのJWT認証のエンタープライズパターン？
JWT仕様では、ペイロードとその送信方法のみが記述されていますが、認証プロトコルは開いたままになっているため、柔軟性が得られますが、残念ながら柔軟性により、アンチパターンや誤設計が発生する可能性があります。
私はJWT認証のためによく考えテストされたエンタープライズパターンを探しています。これは使用または適応できますが、完全なものを見つけることができませんでした。
私が考えていたのは：
- authorizationヘッダーが満たされていない場合、またはJWTトークンが無効であるか、期限切れの場合は、HTTP 401を送信します。
- 認証するには、/ login RESTチャネルを使用し、JSONオブジェクトとしてユーザー名とパスワードを送信します
- トークンを存続させるには、/ keepalive RESTチャネルを使用し、N（5）分ごとに呼び出し、新しいJWTトークンを受け取り、各呼び出しの後に既存のトークンを置き換えます（トークンはM（ 15分）
ただし、私を邪魔するのは、その/ keepaliveチャネルの必要性です。一方、ユーザーが不在の場合（キープアライブが必要かどうかの決定がまだ満たされていない場合）であっても、認証が期限切れにならないように強制します。もちろん、これらは追加の呼び出しであり、プロトコルの追加の複雑さです。興味深いのは、サーバーが自動的にトークンを延長することです。セッションベースの環境では、タイムスタンプをリセットすることで発生しますが、ここではサーバーが新しいトークンを送信する必要があります。毎回ではなく、トークンがR（たとえば10）分で期限切れになると送信されます。しかし、それを応答本文に配置することは、JSON応答プロトコルを変更することを意味し（したがって、ソリューションは侵襲的で透過的ではありません）、クライアントが処理できる追加のHTTPヘッダーを配置することは、必ずしも良いパターンであるとは限りません。選択する必要がある場合は、Authentication Bearer xxxTOKENxxxヘッダーをレスポンスに配置することを検討します...
私のオープンポイントに答える、すぐに使えるエンタープライズパターンはありますか？プロトコルドラフトは信頼できるアイデアですか？ゼロからデザインするよりも、すぐに使えるものを使いたいです。
JWT（ Intro to JSON Web Token ）は単なるトークン形式であり、認証はその仕様の範囲から完全に外れたものです。これは確かに認証システム内で一般的に使用されていますが、完全に異なるシナリオで使用することもできるため、その仕様に認証固有の制約を含めないことは理にかなっています。
認証に関するガイダンスを探している場合は、 OpenID Connect ファミリーの仕様を参照してください。さらに、システムがHTTP APIで構成されており、それらのAPIへの委任アクセスを独自のアプリケーションまたはサードパーティのクライアントアプリケーションに提供することに関心がある場合は、 OAuth 2. 仕様を参照する必要があります。
SAMLやWS-Federationのような認証関連のプロトコルが他にもありますが、エンタープライズシナリオではまだ広く使用されていますが、実装が非常に複雑です。
特定のオープンポイントについて：
- ベアラートークン認証方式は、RFC 675 で定義されています。これには、要求の実行方法と考えられるエラーコードが含まれています。
- OAuth2とOpenID Connectはどちらも可能性を考慮しており、ユーザー名/パスワードをトークンと交換する方法を定義しています。
- 自己完結型/値によるトークン （JWT）の存続期間を延長する問題は、OpenID ConnectおよびOAuth2内で リフレッシュトークン を使用して対処されます。
OAuth2とOpenID Connectは、以前のバージョンよりも実装が簡単であるように見えますが、かなり複雑なので、ある程度の注意が必要であり、かなりの時間とリソースを費やす気がある場合にのみ自分で実装します。これは、通常、負荷のかかるサードパーティのライブラリまたはサービスを使用する方が適切なオプションです。
最後に、これらのプロトコルは多くのシナリオをカバーしているため、状況によってはやり過ぎになる場合があります。
キープアライブチャネルは必要ないと思います。ペイロードには、ログイン時にトークンが生成されたときにサーバーによって（expキーに standard で）提供される有効期限情報を含めることができます（推奨されます）。有効期限が切れたトークンが使用された場合（これは明らかにサーバーによって決定され、署名が検証された場合にのみトークンの内容を信頼します）、サーバーは単にHTTP 401でそれを拒否し、クライアントに再認証を促します。
一方、クライアントはプロアクティブになることができます。ペイロードセクションは暗号化されていません。クライアントはそれを読み取ることができるため、クライアントはリクエストが期限切れのトークンで送信される時期を確認できるため、トークンが期限切れの場合は/loginを再度呼び出します。
または、RESTを使用すると、ハイパーメディア情報を「状態のエンジン」として送信できます。したがって、必要に応じて、実際にJWTを1回限りの使用で、有効期限も指定できます。次に、すべてのリクエストが新しいJWTを生成します。これは hapi-auth-jwt2 の場合と同様に、コンテンツ内、またはより可能性の高い応答ヘッダー内のいずれかで、クライアントへの応答で返されます。