こんにちはJS APIチーム、
私たちのSSOは強化されたセキュリティ対策を適用しており、意図的に`window.opener`をクリアする問題に直面しています。
現在、ArcGISプラグインを提供するOctave（別名EAM）との統合に取り組んでいます。彼らのクライアントアプリケーションはEsriが提供するサンプルとドキュメントに従っていますが、その結果として統合が現在壊れています：認証は成功しますが、`window.opener`が利用できないため、コールバックがOAuthレスポンスを親アプリケーションに返せなくなっています[1]。
EAM／Octaveを責めるべきではないと思います。彼らはドキュメント全体で参照されている[2],[3] `oauth-callback-html` [1]を使用したSDKが提供する最も直接的な方法に従っているからです。
セキュリティチームと調査した結果、この状況は必ずしも私たちのSSO特有のものではありません。Cross-Origin-Opener-Policy（COOP）などの最新のブラウザ分離メカニズムも、ポップアップ／オープナー関係を意図的に切断することがあります。
したがって、SDKはより堅牢になり、現在のセキュリティ慣行により適合させるために、window.opener が利用できない環境もサポートするよう改善できるようです。
一つの代替案としては、同一オリジンの BroadcastChannel をコールバックページとアプリケーション間で使用し、window.opener が利用できない場合のフォールバックとして機能させる方法があります。例えばMicrosoft MSAL Browserは、COOP対応環境でのポップアップ認証をサポートするために類似のアプローチを使用しています[4]。
OAuthポップアップログインフローがこのような環境をサポートするよう強化されると素晴らしいです。ArcGISと統合する外部ベンダーは公式サンプルに従う可能性が高く、それ以外の場合は認証フロー全体でwindow.opener が常に利用可能であるという前提を引き継いでしまうかもしれません。
ご検討いただきありがとうございます！
参考文献：
[1]
https://github.com/Esri/jsapi-resources/blob/main/oauth/oauth-callback.html
[2]
https://developers.arcgis.com/javascript/latest/references/core/identity/OAuthInfo/#popup
[3]
https://developers.arcgis.com/javascript/latest/sample-code/identity-oauth-basic/
[4]
https://learn.microsoft.com/en-us/entra/msal/javascript/browser/login-user
追伸：ケース番号04242886で問い合わせ中で、こちらに投稿することを勧められました。
