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
