Hi there. I’m new to federated auth so pardon my ignorance.
My situation is like this: a SPA+API which I will call–as a whole–the App. This App is actually deployed/instanced per user (think Wordpress).
I thought I would get an access token from auth0 with the SPA (frontend/js). Then the SPA would send the API (server backend, nodejs) the access token for every request. The API would use its secret to validate the token with auth0, and if valid, would return a 200 response. Is this accurate?
As for getting a secret, it sounds like I will need to use auth0’s Management API to dynamically create… something (an app plus API? or just one?) for each deployment/instance. Is this the case? Or can I simply add to the callback URL whitelist for one app since they are instances of the same app?
You are correct about the first part. You wouldn’t get the secret via Management API though.
To verify an access token, there are two ways to approach it, or two algorithms we support, HS256 and RS256. We recommend to use RS256 though, which works asymmetrically using public/private key concept; especially when there is no way to securely store a secret on the client side (SPA).
When you talk about secret, you are then probably referring to the HS256 approach. Here are the docs and blog post that describe the two approaches.
Thanks! I think I get it… So for my SPA+API, once my API gets the token (JWT), my API will verify the JWT the SPA sends with every request according to the link you attached which I think says uses my tenant’s JWKS. Correct?
To do that last part, it looks like I need to configure both the SPA and the API in the dashboard. But for my situation where I dynamically deploy new instances for every user, does that mean I have to use the Management API to add each new instance’s URLs (callback, origin, etc) to the whitelist for the SPA?
To do that last part, it looks like I need to configure both the SPA and the API in the dashboard.
Yes, correct. You’re also right about the JWKS.
But for my situation where I dynamically deploy new instances for every user,
Are you offering a kind of SaaS solution? Sounds like a multi-tenancy scenario, is that right? For this, I recommend to take a look at the blog post around this.
But you are right, in case you are going that route you described, the dynamic registration would be done via management API. Though doing this for every single user doesn’t sound very common; there should be other mechanisms you can use to separate authorization and access to data per user, depending on our use case. Take a look at the blog post to see what matches your use case best.
Yes it’s uncommon. According to that blog post, my platform is a single-tenant app, but I’m still confused with the auth flow now. Each single-tenant app (“instance” hereon) has its own custom domain, but it pulls from the same Auth0 user database. So I should be able to use one Auth0 dashboard application and update that one application’s whitelists whenever a new instance is deployed, right? (Is the management API only available to Developer accounts?)
If that’s the case, then I think each instance’s SPA would get a token from that one application (after being whitelisted) and hand it to the instance’s API. There would only be one Auth0 dashboard API for all instances as well but they don’t have whitelists, so each instance simply validates the token using my domain’s JWKS. Is this still correct?
The goal is to have users of each instance be able to login to other instances (if given permission) as well, using their same email/pass (or social login).
is the custom domain full on custom, like mydomain.com and yourdomain.com, or is it a subdomain like instance1.maindomain.com and instance2.maindomain.com? If it’s the latter, you can add a wildcard to the callback urls. I’m not sure about the origin urls, we’ve not got that configured in our subdomained tenant