OAuth2アクセストークンはどこに保存すればよいですか？
モバイルアプリケーション用にREST APIバックエンドを構築しています。私たちの設計上の選択では、OAuth2プロバイダーにログインセキュリティを処理させることにしました。
ただし、OAuth2プロバイダーから取得したアクセストークンのベストプラクティスはわかりません。
状況は、ユーザーがログインすると、OAuth2プロバイダーからアクセストークンを取得することです。モバイルアプリケーションがバックエンドにリクエストを行うたびに、このトークンを使用する必要があります。そのため、OAuth2プロバイダーに対して検証して、トークンがまだ有効かどうかを確認できます。
JWTを作成し、それをモバイルアプリケーションに渡します。これは、リクエストを行うたびに使用されます。
私の質問は、OAuth2プロバイダーから取得したアクセストークンをクレームとしてJWT内に保存する必要があるかどうかです。
または、データベースに保存して、JWTクレームに保存するユーザーIDに接続する必要がありますか？
おそらく、JWTをJWEで暗号化することをお勧めしますか？その場合、リクエストごとに復号化すると、データベースのルックアップを行うのではなく（MongoDBまたはRedisを使用します）、パフォーマンスへの影響は同じですか？
My REST APIへの接続は、HTTPSを介して行われます。
サードパーティAPIへのリクエストがサーバー経由の場合は、ユーザーに関連付けられたデータベースにアクセストークンを保存し、環境変数として保存されているキーで暗号化します。データベースが危険にさらされている場合、トークンは安全です。 （ボーナス、生成されてモバイルアプリに保存されるキーでトークンを暗号化します。）
サードパーティAPIへのリクエストが直接モバイルアプリからのものである場合は、サーバーのデータベースに保存されている各ユーザーの一意のキーで暗号化されたアクセストークンを電話に保存します。機密情報の分散ストレージは、中央ストレージ（コンパートメント化）よりも安全です。電話が盗まれた場合、復号化キーを取得する前にサーバーへの認証が必要です。サーバーが危険にさらされている場合、トークンはそこにはありません。
私はJWTを使用していません。
アクセストークンは RFCによる アクセスが制限されているはずです。サーバーが危険にさらされている可能性がある場所に、価値の高い何かをどこに保存するかを心配するのではなく、単純にトークンへのアクセス期間を制限する方が良いでしょう。
これは、ベアラートークンのRFCで具体的に説明されています。
短期間有効なベアラートークンを発行する：トークンサーバーは、特に情報漏えいが発生する可能性のあるWebブラウザーまたはその他の環境内で実行されるクライアントにトークンを発行する場合、有効期間が短い（1時間以下）ベアラートークンを発行する必要があります。存続期間の短いベアラートークンを使用すると、リークされる影響を減らすことができます。