retrorocket
commented
1 year ago 79 で対応した。中間択として👇の案を採用してimplicit flowを使うのを止めた。
- サーバサイドでauthorization code flowを使う。
access_type=onlineでアクセストークンを発行する。＝リフレッシュトークンは発行しない。- クライアントには毎回認証認可してもらうことになるが、ブラウザにGoogleへのセッションが残っている場合は認証認可ステップはスキップされる。アカウントが複数ある場合はアカウント選択画面になる。
launchWebAuthFlowを採用すると毎回ログインから始まってしまうため、ウインドウを自分で生成する。
- バックエンドサーバーにトークン取得用のAPIを用意し、拡張から呼ぶ。呼び終わったあとはバックエンドサーバーとのセッションを終了する。
- CORSで拡張以外のアクセスはブロックできると思っていたが、
chrome-extension://から始まるページはpermissionを問わずCORSをガン無視してリクエストを飛ばすため、originをチェックする処理を追加した。
- CORSで拡張以外のアクセスはブロックできると思っていたが、
関連 #74
v3.31時点ではGoogleのドキュメントに倣ってimplicit flowを採用している。 クライアントサイド ウェブ アプリケーション用の OAuth 2.0 | Authorization | Google Developers
問題点
対応案
現状取っている案
これを直そうとするとやりたいことに対してコストが掛かりすぎるので諦めてこのままの運用で行く。 どうしようもないならChromiumのサポートは諦める。