まず最初に、OAuth2.0 による認証に関するこの記事をチェックしてください。背景によっては、OAuth と OpenID Connect 自体を読む必要がある場合があります。
ただし、サーバー側のセッションを署名および暗号化された JWT に保持したいだけであれば、それも問題ありません。JWT には、いくつかのクレームが必要です。少なくともいくつかは次のことを示しています。
- セッションがいつ作成されたか (iat)
- セッションがまだ有効な時間 (exp)
- 誰がセッションを作成したか、それがあなたの認証システム (iss) です
- 誰がこのセッションで認証されているか、それはあなたのユーザーIDか何か(サブ)です
後で、オーディエンスとできれば nonce を追加できます。ただし、すべてを暗号化している場合は、ナンスなしでそれを行うこともできます.
一般に、OIDC コア仕様で提案されているクレームを参照することをお勧めします。
そして、ここが難しいところです。基本的に 2 つのオプションがあります。サーバー側で文字列を生成できます。これは、すべてのアプリケーションに対して完全に不透明であり、セッションになります。次に、クライアントがこの文字列を送信して上記のクレームを取得できるトークン イントロスペクション エンドポイントを提供します (さらに、セッションにマップすることを決定したすべての追加クレーム)。これは、これらの不透明な文字列がマップ先のユーザー クレームと共に永続化されるストレージが必要になることも意味します。
または、束全体に署名 (およびオプションで暗号化) して、ネットワーク経由で送信することもできます。ユーザーをログアウトできるようにする必要がある場合にのみ、トークンの ID が必要です。トークンへの署名は、アプリケーションだけが知っている秘密鍵で行われ、クライアントでの検証は、アプリケーションが JWKs エンドポイントを提供するなどして共有できる公開鍵によって行われます。
JWT に入れるクレームによっては、暗号化する必要がまったくない場合もあります...ただし、暗号化する場合は、暗号化用のキーも管理する必要があります。
また、トークン認証とは何かについての非常に優れた概要については、この記事を確認してください。