OAuth2：ステートレスアプリケーションのどこにリフレッシュトークンを保存すればよいですか？
現在のアーキテクチャには、OpenID Connectを介してJWTトークンを提供する認証サーバーがあり、実装したコードフローを使用する任意のWebアプリケーションに接続しています。
認証済みのWebアプリケーションをステートレスにするために、OpenID Connectを実装する面倒に（主に authlib のおかげで）行きました。また、JWTを渡すことで、ユーザーを再認証せずにアプリ間でリクエストを行うこともできます。とても便利です...
今、私は次の問題に直面しています：上記のWebアプリケーションの1つがコードフロー全体をもう一度通過するのではなく、トークンを更新したい場合、バックエンドの安全な場所に更新トークンを格納する必要があります。
悲しいことに、これは私が探していたステートレス認証を壊し、そのため、最初は何も必要としなかったWebアプリケーションのそれぞれに何らかのソートデータベースをマウントする必要があります。
ステートレスな方法でJWTを更新する方法はありますか？または、私の質問を言い換えると、ステートレスアプリケーションのどこに更新トークンを保存できますか？
単に答えは「リフレッシュトークンを使用しない」です。これは、SPA、API、IDプロバイダーがある場合にシステムが機能することを想定していないためです。ドキュメントは、SPAが支配的になる前にずっと前に設計されたため、この点で少し混乱しています。主な問題は、最初はおそらくAPIサーバーを依存パーティと見なし、angularアプリケーションを単なる「フロント」と見なしたことです。少なくとも私が抱えていた問題でした。それは単にそうではありません。
ここでの要点は次のとおりです。
- SPAは依存パーティであり、flask APIsサーバーではありません。
- APIはJWTトークンを検証するだけでよく、認証フローに参加したり、更新トークンにアクセスしたりする必要はありません。
- リフレッシュトークンは主に「制御された」タイプのサービスで使用されるため、SPAはリフレッシュトークンを取得/使用する必要はありません。代わりに、openid connectの仕様にiframeロジックが含まれているため、現在のアクセストークンが検証の終了日時に近づいたときに、RPは新しいアクセストークンとIDトークンを取得できます。
次の質問は、どの承認付与フローを使用する必要があるかです。答えはPKCEです。既知のセキュリティ違反があるため、暗黙的に使用することは望ましくありません。クライアントシークレットをangularアプリに配置する必要があるため、従来のコードフローを使用することはできません。幸い、PKCEが作成されたのはまさにそのためです。 https：// tools .ietf.org/html/rfc7636
そしてそれを実装するには、2つのものが必要です。
- PKCEロジックを角度で実装しますが、誰かが既にほとんどの作業を行っています： https://manfredsteyer.github.io/angular-oauth2-oidc/docs/additional-documentation/code-flow-+-pcke。 html
- A python libは、受け取ったトークンを単にチェックして、apiレベルでユーザーを認証します。わからないflaskしかし、Django小さなlibを使用します： https://github.com/ByteInternet/drf-oidc-auth 。そのlibは基本的に1つのファイルです。ステートレスにしたいので、使用したいBearerの代わりにJWT。
そこに着くと、システムはおそらくあなたのニーズに合うでしょう：
- 長期実行認証はIPによって処理され、ユーザーがIPレベルでログインしている限り、iframeはアクセス/ IDトークンが最新であることを保証します。
- APIサーバーはステートレスであり、データベースを必要としません。