有名なやつ
まあ僕自身のケースで言うと、 OpenID Connect 経由で得られる ID Token (JWT) はログインのためだけに使い、伝統的なセッション管理を引き続き使いますよ、もしくは ID Token にセッション ID を含みますよ、で要件を満たせてしまいます (実際には OpenID Connect の Session Management における拡張仕様のどれかにも載っからないと各サービス間でのログアウト状態の整合性が取れないので頑張りが必要ですが)。
Twitter で拾ったもの
第三者サービスへの認可の委譲は OAuth 2 の一時的なアクセストークンで行うべきだし，自社サービスの認証は今まで通り Cookie でやるのが最善。後者にリフレッシュトークン持ち出してくるのは本当にセンスがない。
— 刺身食べたい (@mpyw) 2020年3月11日
第三者サービスへの認可の委譲は OAuth 2 の一時的なアクセストークンで行うべきだし，自社サービスの認証は今まで通り Cookie でやるのが最善。後者にリフレッシュトークン持ち出してくるのは本当にセンスがない。
Qiita
セッション管理ではなくOAuth認証などに使うのは問題ない。一回認証したら終わりなので、有効期限を短くしておけば済む。「一人のために全員ログアウト」のような不便は発生しない。
StackOverflow
@user3601262 I would say that regardless of it's (prolific) popularity as an approach, it is not a best practice to give access tokens to a SPA frontend which ultimately will store those tokens in browser storage (which is not secure). The recommended approach is to introduce a middleware service (usually a BFF) that uses sessions and acts as an OAuth2 Client for stateless backend services. This also hides the backend architecture from the frontend, which is another good practice.
DeepL で翻訳
@user3601262 アプローチとしての（多くの）人気にかかわらず、SPAフロントエンドにアクセストークンを与えるのはベストプラクティスではない。推奨されるアプローチは、セッションを使用し、ステートレスバックエンドサービスのOAuth2クライアントとして動作するミドルウェアサービス（通常はBFF）を導入することです。これはまた、フロントエンドからバックエンドアーキテクチャを隠すことにもなり、これも良いプラクティスです。
実装するならこんな感じか：
