Auth0.com - OAuth2 Implicit Grant SPA
Implicit Grantを非推奨とするOAuth 2.0 Security Best Current Practice (Draft)について、既存のアプリや今後開発するアプリでどのように対応していくべきかが解説されている。
A More Detailed Summary
- これからSPAを実装する場合は、Best Practiceに従いAuthorization Code Grant + PKCEを使うべきである。
- Implicit Grantを実装している既存のSPAについては、既知の問題に対するセキュリティ対策がされているのであれば、ベストプラクティスへの対応は任意である。
The Implicit Grant
- Implicit Grantには、Redirect URIの不十分な検証、Referer・ブラウザ履歴からのアクセストークン漏洩、Token Injectionといった問題がある。
- これらの問題にはToken Injectionを除けば確立された対策方法があるため、正しく実装すれば安全であるが、OAuth 2.0 Security Best Current Practiceでは実装不備によるセキュリティリスクを下げる別の手段が提示されている。
Renewing access tokens
- ブラウザは秘匿情報を安全に保管する機能を提供していないので、XSS等によりRefresh Token漏洩が起きやすく、SPAではClient Secretは露出するためRefresh Tokenの悪用が可能となる。
- Best Practiceでは、Refresh Tokenを安全に使うためにSender-Constraint Token（Token BindingもしくはMutual TLS）が推奨されるが、Token Bindingはブラウザがサポートする見通しがなく、Mutulal TLSは仕様に課題が残されている。
- Sender-Constraint Tokenが利用できない場合の受容可能な方式として、Refresh Token Rotationがあるが、トークンを共有するクライアントが複数あるときに問題となる。またToken RotationはMicrosoft、Google, Auth0ですらサポートされていない。
- Refresh Tokenを使わない方法として、非表示にしたiframeで
prompt=noneを指定してアクセストークンを再取得することもできるが、将来的にApple ITP2でiframeでのCookieアクセスが禁止され使えなくなる可能性がある。
Different SPA Topologies and Alternative Approaches
- Backendがあるのであれば、Frontend・Backend間の認証をSession Cookieで行い、トークン管理（もしくは取得のみ）を全てBackendで行うことで、Refresh TokenをFrontendで扱わないこともできる。（Cookieはブラウザによりオリジンの制御がされるため安全である。）