Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Neil Madden <[e-mail]>]

> On 21 Nov 2018, at 09:25, Daniel Fett <[e-mail]> wrote:
> 
> Am 21.11.18 um 10:09 schrieb Neil Madden:
>>> If a page from origin A includes a third-party script from origin B, that external script runs in origin A and has access to all cookies and the JavaScript context of the page.
>>> 
>>> The SPA from origin A would be compromised. That is why we need things such as Subresource Integrity.
>>> 
>> I think we’re talking about different things. 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.
> Thanks for the clarification! I see that you highlight an important point there.
> 
> The protection that would be required essentially boils down to something similar to a CSRF protection for the resource server.
> 
> Luckily, CORS covers this: You can't set the Authorization header cross-origin unless the appropriate CORS headers are set. So while the third party origin would be able to send a request through the browser using the TLS context, it would not be able to attach the access token. (Unless, of course, that third party origin is whitelisted, or if the bearer token is sent in a different way, e.g., as a URL parameter.)

Right. But two points here:

Firstly, this assumes the access token is actually passed in an Authorization header and not just sent in a URL parameter or a CORS-safe form POST body (e.g. application/x-www-form-urlencoded). This should probably be its own security best practice recommendation, but I haven’t seen it anywhere. I think most REST APIs already do this following RFC 6750, but we should spell out that it has security benefits.

Secondly, this means that we are relying on something other than (TLS-based) sender-constrained access tokens to prevent this, so we should clarify that in the document.

> 
> As a side note, interestingly, this would leave an authorization code unprotected, if the sender authentication would be mTLS or token binding. PKCE on the other hand is fine.

Right - that’s why I am glad to see the security topics draft recommending PKCE in all cases.

Why is PKCE so effective? In my opinion, you can view PKCE as a one-time PoP scheme for the auth code - you prove possession of the secret to the AS by simply giving it the secret along with the auth code. You could do something similar with the implicit flow, but I won’t share that scheme here as I am happy for the implicit flow to die ;-)

— Neil