Hey,
I’m currently building an api for external developers to use, similar to Plaid. As part of the API you get access to two environments sandbox and production. Each environment has a separate auth0 Tennant. When a user signs up I create an auth0 application for that user, in the respective environment(Tennant). I currently have two backend services (Router service and data-api, the data-api is replicated across two different instances one for sandbox one for prod).
There is a backend service which essentially handles the routing of the requests to the correct data-api. I.e. if the user requests prod vs sandbox. What is the best way to handle auth between the router service and data-api, is it to use an M2M token I assume? The data-api is currently setup to validate M2M tokens generated using the client credentials grant for the respective users Auth0 application.
Now I also have a frontend service which hits the routing service using the auth0 access token which was generated using the client_id and client_secret for the frontend service. Now using this access token, should I be validating the access token, getting the current user, fetching the correct credentials(client_id, client_secret) stored against that user and generate an M2M token using their client_id and client_secret to hit the data-api with?
This seems like the only way to do it currently, unless I’m missing something. Would love some advice on this, I’ve gone through the auth0 docs but struggling to find the right advice.
If this is the only way, can I store the M2M tokens to ensure that I don’t generate too many.
Hi @maitham
I would architect this a bit differently: I would not have your router service, instead I would have your prod data-api and your sandbox data-api. This is simpler, and the user’s access token can be used to access the data-api directly.
With the router service in the middle, there is some confusion for me: users have the identity they use to get an access token AND an identity for the prod data-api (M2M) AND an identity for the sandbo data-api. Shouldn’t they have a sandbox and prod identity for the access tokens as well?
With my architecture, your data-api just uses the access token. M2M not required.
John
1 Like
Hey @john.gateley ,
TLDR- Main reason is we need to support M2M tokens as our api is primarily being used by clients who will access the data api from their backends.
Thanks for the reply! The reason for the current architecture is our api is meant to be used by other developers on their backend services. Hence we generate client credentials(i.e. client_id and client_secret) for both sandbox and prod environments that they can use. When I say prod/sandbox environments these are customer facing environments not internal (dev/stg/prod) in case of confusion. Users logon to a dashboard where we provide them with the client credentials for each environment and they use this to access the data api from their backends. These client credentials belong to a team which consists of multiple members. Each member has access to the dashboard.
The router service is there to manage frontend requests and combine some of the data, e.g. we need to display the client credentials for each environment, we make one request to the router service which makes a request for sandbox & prod credentials from the data-api’s and returns the combined object. This way the data api’s have no notion of team members etc, they just ensure the correct client credentials are being used.
It was never our intention to support hitting the data-api directly from the frontend. As with all things like this, one of our customers required a custom dashboard to be built which queried the api directly hence was thinking of proxying requests through the router service and including the M2M token as part of that. Unless there is a better way, I’m hoping theres a simpler/neater solution?
Happy to clarify any more details, trying to explain as best I can.
Hi @maitham
A couple of things to start:
- You can use user access tokens with a backend service, it is not required to use M2M tokens. You get a refresh token (scope “offline_access”) and use that to get new access tokens as needed
- Your SPA should NEVER have a client secret, but you are using a client secret to get a M2M token for the routing service. This is not secure
I don’t have enough of the picture to be able to help more. This is a complex scenario, and requires a thorough understanding of the actors, services etc to be able to give good input.
It’s not often I do this, but I would recommend an Auth0 professional services engagement to help architect this. Send me a message directly and I will put you in touch if you are interested.
John
2 Likes
Thanks @john.gateley, I’ve sent you a message directly.
The SPA shows the user their team client_secret that is scoped to only accessing a specific API. Would love to discuss in more detail to clarify everything.
