Re: [whatwg/fetch] CORS: why is Authorization request header forcing preflight? (#770)

@sleevi It's a general question, but specific problem that comes to mind is access token in OAuth2. There's a clear misconnect b/w https://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.3 that says:

> Don't pass bearer tokens in page URLs:  Bearer tokens SHOULD NOT be passed in page URLs (for example as query string parameters). Instead, bearer tokens SHOULD be passed in HTTP message headers or message bodies for which confidentiality measures are taken. Browsers, web servers, and other software may not adequately secure URLs in the browser history, web server logs, and other data structures.  If bearer tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations.

Vs https://tools.ietf.org/html/rfc6750#section-2.3:
> When sending the access token in the HTTP request URI, the client adds the access token to the request URI query component as defined by "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986], using the "access_token" parameter.

There are countless services relying on OAuth2 and using access_token query parameter. Many of these services also accept access token as an Authorization header, but it's essentially useless in the browser given the CORS preflight requirements.

The access_token URL query parameter is a practical solution and it does help in testing, etc. But given this standard it simply appears to move something that belongs in headers into the query string. And, of course, it also theoretically could be used for enumeration. But practically it's a non-issue given strong cryptography and a limited life time.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/770#issuecomment-399191076