My intent wasn’t to suggest that tokens *must* be origin constrained, just to point out if you are using TLS-based sender constrained tokens then you may also want to consider that aspect.
In some cases you may be comfortable that protections against in-browser token theft are adequate without any sender/origin constraint. Sometimes a plain old bearer token is fine. — Neil > On 29 Nov 2018, at 01:22, Richard Backman, Annabelle <richa...@amazon.com> > wrote: > > In some cases, the resource server will need to support CORS in order to > support SPA clients that are on different origins. In this case, the resource > server must optimistically allow the CORS request to be made, then validate > that the request origin is appropriate for the access token provided in the > request. To my knowledge, I haven't seen "origin-constrained access tokens" > raised as a requirement anywhere, but here we are. > > -- > Annabelle Richard Backman > AWS Identity > > > On 11/26/18, 2:34 AM, "OAuth on behalf of Neil Madden" > <oauth-boun...@ietf.org on behalf of neil.mad...@forgerock.com> wrote: > > 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
