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
