[OAUTH-WG] Binding Access Tokens is not enough!

[Daniel Fett <[e-mail]>]

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