Re: [OAUTH-WG] Recommended OpenId Connect Flow for SPA with Microservices

[David Waite <[e-mail]>]

On Jun 10, 2019, at 2:06 AM, David Sautter <[e-mail]> wrote:

> I understood the following: Using a backend service for doing the exchange of the auth code for the token with the IdP is considered more secure, because one cannot trust the browser to store the tokens securely. The drawback is that you will have to create your own session state between your backend and your frontend SPA (e.g. using a cookie).

Security-wise your risks include both token exfiltration and arbitrary code execution. A proxying backend that holds the token might prevent XSS from exfiltrating the token, but by default does not limit the impact of someone driving the user’s browser directly instead.

There can certainly be other implementation/architectural benefits of this approach, however. You can limit actions taken by the SPA, provide a bridge to a remote domain for an API that doesn’t advertise CORS support, enforce rate limiting of APIs which may be charged upstream, and so on. You could also use this to enforce a common processing layer across user-facing components.

> I am in a scenario where I do not have "the one backend", but a bunch of microservices running on Kubernetes, so they could die and respawn at any given time. Do I need a API-Gateway for dealing with the Authorization Code Flow? Which ones would be recommended (standard compliant)?

The standards mostly focus on the protocols between client, AS/IDP, and protected resource. The products which say help you implement just the client don’t necessarily have standards to leverage between your code and theirs. Leveraging OIDC for web access is mostly pain free for traditional applications, but SPA applications are more like API clients and take some of the passive browser behaviors that you would leverage here (such as potentially redirecting for authentication on new page request).

> Or is the alternative of handling the complete Authorization Code Flow + PKCE in the Browser considered a safe scenario?

This is what we are recommending by default for https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps 

Content Security Policy is recommended for preventing XSS in that document. Subresource integrity isn’t explicitly called out, but is also invaluable.

To prevent exfiltration, the options are limited. 
- Token Binding will work, but only currently has support in Edge.
- Mutual TLS will work, but has a poor experience unless you are deploying alongside group policy.
- DPoP was written specifically for the browser use case (such as letting you use WebCrypto for non-exportable tokens). It is an early draft but has some initial implementations already.

You can also have risk and fraud analsyis against both. XSS would need to be detected by usage behavior, while Exfiltration could use environmental detection like address and user agent changes.
> 
> I have been doing a lot of research but having trouble to clarify this. Thanks for your help!

Hope this helps!

-DW