リフレッシュ・トークンをクライアントのどこに保存すればよいですか？

しかし、リフレッシュ トークンはどうでしょうか なぜなら、(1)リソースサーバへのすべてのリクエストで送信され、CSRFにも脆弱になり、(2)同一の攻撃ベクトルでアクセス/リフレッシュの両方のトークンを送信することになるからです。

私が考えることができる3つのソリューションがあります。

1) メモリ内の JavaScript 変数にリフレッシュ トークンを保存する。これは 2 つの欠点があります。

• a) XSS に対して脆弱である (ただし、ローカル/セッション ストレージほど明白ではないかもしれない)。
• b) ユーザーがブラウザのタブを閉じると、quot;session" が失われる。

特に後者の欠点は、悪い UX になってしまうでしょう。

2) アクセストークンをセッションストレージに格納し、それを Bearer access_token 認可ヘッダーでリソースサーバーに送信します。そうすると httpOnly クッキーをリフレッシュ・トークンのために使うことができます。これには、私が考えることができる1つの欠点があります。

• a) リフレッシュ トークンは、リソース サーバーに行われるすべてのリクエストで CSRF にさらされます。

3) トークンを両方とも httpOnly クッキーに格納します。これは、両方のトークンが同じ攻撃ベクトルにさらされるという前述の欠点があります。

もしかしたら他の方法があるかもしれませんし、私が述べた欠点以上のものがあるかもしれません（教えてください）。 クライアント側で私のリフレッシュ トークンをどこに保存するか。 ? それは httpOnly クッキーなのか、それともメモリ内のJS変数なのでしょうか？前者であれば、アクセストークンをどこに置けばいいのでしょうか？

このトピックに精通している人々から、これを行うための最良の方法についての手がかりを得ることができれば、超嬉しいです。

どのように解決するのですか？

暗号化されたトークンを安全に保存するには HttpOnly クッキーに格納することができます。

https://medium.com/@sadnub/simple-and-secure-api-authentication-for-spas-e46bcea592ad

Refresh Tokenの寿命が気になる場合。保存を省略し、一切使用しないことも可能です。Access Tokenをメモリ上に保持し、Access Tokenの有効期限が切れた時点でサイレントサインインを行えばよいのです。

使用しない Implicit のフローは 廃止 .

SPA の認証で最も安全な方法は PKCEによる認証コード .

一般的には、既存のライブラリをベースにした oidc-client をベースにした既存のライブラリを使用するのが良いでしょう。