更新トークンとアクセストークンの両方として同じトークンを使用することは安全ですか？
OAuthで理解している限り、更新トークンとアクセストークンがあります。アクセストークンは取り消すことはできませんが、有効期間が短く、次の更新アクセスではアクセストークンはありません。取り消されました。自分でトークンを発行し、1つのアプリケーション（モバイルとWebの両方、ただし同じAPI）で自分自身を消費する単純なアプリケーションがあるため、複雑なOAuthまたはOpenIdConnectは必要ありません。 3Dパーティ向け。単純にするために、このスキームを1つのトークンだけで使用したいが、パフォーマンス上の理由から（各呼び出しの失効をチェックしないように）スキームも更新したい：
- クライアントはユーザー名とパスワードを特別なエンドポイントに提供し、署名されているが暗号化されていないJWTを受信します（私が理解している限り、ユーザーは読み取ることができますが偽造はできません）。 .NETのJwtSecurityTokenHandlerを使用して、OauthまたはOpenIdConenctサーバーなしでトークンを発行します。トークンは、RSAを使用して署名されていますSHA 256作成した証明書トークンは、たとえば1時間など、有効期間が短いです。
- すべてのAPI呼び出しはベアラー認証で修正され、サーバーでトークンを読み取り、署名と有効期限を確認します（オーディエンスなど、他のものはありません）。サーバーはこのトークンを信頼し、失効をチェックしません。
- サーバーがトークンの有効期限が切れたことを検出すると、トークンを更新するようにクライアントに通知するために、40xを返します。 （トークンは一部のサーバー呼び出しを保存するために暗号化されていないため、クライアントは有効期限自体の事前検証を行うことができます）。
- トークンの有効期限が切れている場合、クライアントは更新を呼び出し、同じトークンをトークンに渡します。違いは、今回は失効ステータスが確認されることです（トークンごとではなく、ユーザーポリシーのすべてのトークンを簡単に失効させます）。更新で変更されない初期問題の追加のタイムスタンプを確認し、設定されているユーザーのタイムスタンプよりも大きいことを確認します。ユーザーがパスワードを変更したとき。結果は、同じタイプの別のトークンで、初期タイムスタンプは同じで、有効期限はあと1時間です。取り消された場合、ユーザーは再度ログオンする必要があります。
パフォーマンス上の理由から本当に更新する必要があるのですが、何か不足していて、トークンが1つしかないこの単純化されたフローで、セキュリティの問題やその他の問題が発生しているのではないでしょうか。
クライアントとサーバーの両方を制御していて、両方のトークンが常に安全に送信されることを確認できる場合、両方に同じトークンを使用しても問題はありません。
通常、更新トークンは、アプリケーションへの無期限のアクセスを可能にするため、保護する重要なトークンです。これが送信されるトランスポートを制御するのも簡単です。ただし、あなたのケースでは、アクセストークンに同じセキュリティを適用できる場合、それらが同じであるという余分なリスクはありません。
また この回答を参照 。