Conceptual question regarding proper configuration and flow

Confirm you’ve already contributed to this project or that you sponsor it

• I confirm I’m a sponsor or a contributor

Version

4.x

Question

Hello,

This is related to #1699 to keep matters separate and properly explain my setup. I’ll try to keep things conceptually abstract and independent from the specifities of any cloud provider but I would canonically use Google Cloud with this setup.

My initial need was to create an app’s backend that would be secure (obviously). Over time I extracted part of this app into its own service. This setup raised the need for a centralized authentication server.

I have a made a conceptual diagram of my setup here. Dotted lines and boxes indicate possible future components / conceptual relationships. As you can see services do not know about the gateway or even other services and applications ; they are self-contained. The point I’m trying to make is that I do not want to use [Authorize] tags or even check authentication in my apps & services. It should be handled by the gateway as a single entry-point and ideally this gateway would itself act as the authentication server.

Anoter thing of note is that in this context (in my setup) applications refer only to back-ends. Front-ends (React apps, that’s my preferred JS framework) would be hosted either in VMs or more likely in the Cloud as serverless instances (in Cloud Run in GCP, equivalent to Azure App Engine) and would be more or less independent from the whole walled garden setup for my back-ends and services. Front-ends would be almost entirely pure presentation ; in fact even the login screen would be served by the gateway using Razor Pages.

The authentication server would be multi-tenant, as we discussed in #1699, using the hostname, for example:

• tenant.auth.domain.com
• tenant.app1.domain.com

Now my question is not architectural nor infrastructure related, although I would welcome opinions if you have any. But since I’m not too experienced with OIDC I’m not sure anymore which flow I should use and what the whole setup would look like. I initially went with authorization code flow but my setup is not exactly a SPA. The idea is that the user could access apps (not services, at least not directly) in two ways:

1. app1.domain.com
2. tenant.app1.domain.com

In both scenarios the gateway would check authentication before forwarding the request, and if that fails redirect the user to the login screen with the callback uri the user tried to access. For instance app1.domain.com => auth.domain.com?callback=app1.domain.com. The only difference is that in 1. the login screen would include a “tenant” field, where in 2 the redirection would happen at tenant.auth.domain.com and the login screen would not include a tenant field since we already know it. But I’m not sure what happens after that and how it all fits together. In #1699 you mentioned two possibilities and I think the second one is what I’m looking for but I’d like confirmation from you with more context, as well as a more detailed explanation of each step in the flow.

As a side note, but this is more architectural and shouldn’t be an issue, but the apps need to know the gateway as well to retrieve user information, and even administer users, groups, etc

Thanks for your feedback ; I hope it is clear. If it is not do not hesitate to ask for more information that I will gladly provide.

[CorentinBrossutti1]

Yeah, tho’ you generally don’t even need to wait for the 401 response to be returned by the API: the client already knows the user hasn’t completed an authentication dance yet as it doesn’t have any valid tokens (typically stored in localStorage for a SPA).

Yes that’s true

For a SPA, the authorization code is ideally returned as part of the fragment part of the callback URI (response_mode=fragment) or as part of the query string (response_mode=query). Any OIDC client stack will generally handle extracting it from the callback request for you. Yep (except it’s sent to the token endpoint, not to the authorization endpoint). I’d strongly recommend using an OIDC JS stack to handle that for you instead of rolling your own one using Axios. You have fairly good options, like https://github.com/AxaGuilDEv/react-oidc, https://github.com/FormidableLabs/react-native-app-auth (for native React apps) or https://github.com/openid/AppAuth-JS (not specific to React).

Yes I’ll take a look at those, thanks. Yes it was the token endpoint I mixed them up.

The identity/tokens stored in local storage are indeed specific to each SPA clients, but the authorization server itself persists the user identity in its own authentication cookie: when a second SPA needs to authenticate the user and redirects the browser to the identity provider, the user is already logged in there so the login screen can be avoided

Yes because SignIn with cookie authentication scheme has already been called in the post-login endpoint, I see…

It was very clear thanks! Now the only thing left is implementing it properly. Thanks a lot!

[kevinchalet]

Doing some housecleaning, but feel free to reopen if you need additional details 😃