OpenID Connect Web Message Response Mode and XSS
When using the web message response mode spec with OpenID Connect for silent authentication, what prevents an attacker leveraging an XSS attack from registering a "message" listener and intercepting authorization messages (a code or token, depending on the flow)?
In the spec, going off the Simple Mode, the Main Window creates an "Authorized Window" iframe and sets the source of that iframe to the authorization endpoint. If the user is authenticated, the Authorized Window uses the HTML5 messaging API to post a message to the Main Window. That message contains an authorization code in the code flow, or an id_token (and possibly an access token) in the implicit flow.
If an attacker successfully leverages an XSS attack, is there any way to prevent that attacker from listening to message events and intercepting a code/token?
As an aside, Auth0 support the web message response mode which is what got me thinking about this scenario. It can be used in a single-page application to refresh access tokens without reloading the page. Auth0 and the security community in general recommend against storing access tokens in local storage specifically because of XSS attacks. Does the web message response mode present another XSS attack vector?
- Auth0's Silent Auth: https://auth0.com/docs/api-auth/tutorials/silent-authentication
- Web Response Mode Security benefits: What is the security benefit of using PostMessage instead of a callback URL in OAuth/OIDC?
- Auth0 on storing tokens: https://auth0.com/docs/security/store-tokens#single-page-apps
