I would perhaps clarify this a little, as it’s not really CORS that is doing the work here, but rather the same-origin policy (SOP) — which is actually *relaxed* by CORS.
It is the fact that there is a non-safe header (Authorization) on the request that triggers the SOP protections - and it would do so even in an old pre-CORS browser. Otherwise CORS wouldn’t even be involved as the request would be considered “safe”. For instance, if your (RS) API just requires an x-www-form-urlencoded POST body with the access token as one of the fields then I can always just create a form in a hidden iframe and submit it cross-origin with no problems, CORS or not. Adding the Authorization header prevents that - you can’t add a custom header to a form submission, and Ajax would not be allowed to make that request. What CORS changes is that things that would previously be blocked outright now produce a CORS preflight to allow the destination origin to override the SOP and allow a request to go ahead anyway. — Neil > On 26 Nov 2018, at 08:46, Daniel Fett <danielf+oa...@yes.com> wrote: > > Yes. Token Binding enforces that only the right browser can send the token; > in this browser, CORS enforces that only the correct origin can send the > token. > > Am 25.11.18 um 19:46 schrieb Torsten Lodderstedt: >> Does this mean the RS effectively relies on the user agent to enforce the >> sender constraint (via CORS policy)? >> >> >>> Am 23.11.2018 um 14:54 schrieb Neil Madden <neil.mad...@forgerock.com> >>> : >>> >>> Thanks for doing this Daniel, I think the proposed text is good. >>> >>> — Neil >>> >>> >>>> On 22 Nov 2018, at 14:42, Daniel Fett <danielf+oa...@yes.com> >>>> wrote: >>>> >>>> Hi all, >>>> >>>> I would like to discuss a text proposal for the security BCP. >>>> >>>> Background: >>>> >>>> Yesterday, Neil pointed out the following problem with binding access >>>> tokens using mTLS or token binding in SPAs: >>>> >>>> "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." >>>> >>>> The problem is that a browser's TLS stack will attach the proof of >>>> possession no matter which origin started a request. >>>> >>>> (This seems like a real downside of token binding - why does it not have >>>> the "same site" option that cookies nowadays have?) >>>> >>>> I prepared the following addition to the security BCP and would like to >>>> hear your opinions: >>>> >>>> "It is important to note that constraining the sender of a token to a web >>>> browser (using a TLS-based method) does not constrain the origin of the >>>> script that uses the token (lack of origin binding). In other words, if >>>> access tokens are used in a browser (as in a single-page application, SPA) >>>> and the access tokens are sender-constrained using a TLS-based method, it >>>> must be ensured that origins other than the origin of the SPA cannot >>>> misuse the TLS-based sender authentication. >>>> >>>> The problem can be illustrated using an SPA on origin A that uses an >>>> access token AT that is bound to the TLS connection between the browser >>>> and the resource server R. If AT leaks to an attacker E, and there is, for >>>> example, an iframe from E's origin loaded in the web browser, that iframe >>>> can send a request to origin R using the access token AT. This request >>>> will contain the proof-of-posession of the (mTLS or token binding) key. >>>> The resource server R therefore cannot distinguish if a request containing >>>> a valid access token originates from origin A or origin E. >>>> >>>> If the resource server only accepts the access token in an Authorization >>>> header, then Cross-Origin Resource Sharing (CORS) will protect against >>>> this attack by default. If the resource server accepts the access tokens >>>> in other ways (e.g., as a URL parameter), or if the CORS policy of the >>>> resource server permits requests by origin E, then the TLS-based token >>>> binding only provides protection if the browser is offline." >>>> >>>> >>>> The "summary" above this text reads as follows: >>>> >>>> "If access tokens are sender-constrained to a web browser, the resource >>>> server MUST ensure that the access token can only be used by the origin to >>>> which the access token was issued (origin binding). One solution for the >>>> resource server to accomplish this is to only accept the access token in >>>> an Authorization header (as described in RFC 6750) and to ensure that the >>>> active CORS policy prevents third parties from sending Authorization >>>> headers. See <xref target="pop_tokens"/> for details." >>>> >>>> What do you think? >>>> >>>> -Daniel >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
