Multiple Apps, Single API, mixed oauth flows

[sjungers]

Hi, I’m trying to work through the documentation to set up our authorization architecture, and I’m struggling to figure out which of these options will be best.

We have 2 applications that currently share the same client information. They are both MVC applications and use OIDC + authorization_code flow.

We recently introduced a separate API that these applications will be called and is secured with RBAC (but we are currently not using the authorization extension in Auth0).

We are also introducing a new SPA that handles the administration of the new SPA + provides some APIs for the 2 existing applications to call.

Requirements are:

1. I can use machine-to-machine authorization to call the API with the right roles (scopes)
2. If an end-user is logged into one of the apps, the application can make the appropriate calls to the API with the roles the user has (we’re currently passing the user’s token through, I’m not sure if that’s right, though).
3. The user logged into the spa can call the APIs to administer the data for that application.

We started with a single API definition in Auth0 + a single application/client definition in Auth0, but users were forced to authorize the app in the SPA when they weren’t in the MVC apps. This is all a bit complicated, and I’m not sure if it makes sense to do it this way.

Any help would be greatly appreciated.

[dan.woda]

Hi @sjungers,

You should register each app separately (different client id/secret). Let’s say we have a regular web app for admin, a web app for employees, and a SPA for customers. Those would require you set up three different applications/clients in Auth0. Then, if they all send requests to the same API, you would register a single API with Auth0.

You also might want to set up a machine to machine application.

These docs might also help, although they use some outdated flows and SDKs.

Architecture Scenarios

[sjungers]

Thanks for the response @dan.woda. So, that’s the approach I was heading towards, but what I’m not sure about is how to do the token validation in the API. We’re using jwt for the access token, and I’m assuming we will want to do audience and signature validation in the API to ensure the token hasn’t been tampered with, right? How can I do that if each application uses a different client-id, client-secret? Would switching to RS256 instead of HS256 allow multiple apps to access the same API?

Sorry, I’ve been so deep in the docs that my eyes are going crossed. Every time I feel like I understand the solution, I come up with a different concern.

[dan.woda]

You won’t be able to user symmetric algos in a client side app. (i.e. you can’t use HS256 in a SPA).

Here is a good post that breaks it down:

JWT signing algorithms RS256 vs HS256

Both choices refer to what algorithm the identity provider uses to sign the JWT. Signing is a cryptographic operation that generates a “signature” (part of the JWT) that the recipient of the token can validate to ensure that the token has not been tampered with. RS256 (RSA Signature with SHA-256) is an asymmetric algorithm, and it uses a public/private key pair: the identity provider has a private (secret) key used to generate the signature, and the consumer of the JWT gets a public key to val…

In short: yes, you will need to use RS 256.