Am 21.11.18 um 10:09 schrieb Neil Madden: >> If a page from origin A includes a third-party script from origin B, that >> external script runs in origin A and has access to all cookies and the >> JavaScript context of the page. >> >> The SPA from origin A would be compromised. That is why we need things such >> as Subresource Integrity. > I think we’re talking about different things. I am talking about scripts from > places like ad servers that are usually included via an iframe to enforce the > SOP and sandbox them from other scripts. If they get access to an access > token - e.g. via document.referrer or a redirect or some other leak, then > they still act within the same TLS context as the legitimate client.
Thanks for the clarification! I see that you highlight an important point there. The protection that would be required essentially boils down to something similar to a CSRF protection for the resource server. Luckily, CORS covers this: You can't set the Authorization header cross-origin unless the appropriate CORS headers are set. So while the third party origin would be able to send a request through the browser using the TLS context, it would not be able to attach the access token. (Unless, of course, that third party origin is whitelisted, or if the bearer token is sent in a different way, e.g., as a URL parameter.) As a side note, interestingly, this would leave an authorization code unprotected, if the sender authentication would be mTLS or token binding. PKCE on the other hand is fine.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
