Sanity check for using a User's Access Token and a Machine-to-machine Access Token

Our application architecture looks like:
[browser (react)] -> [bff server] -> [common api] -> [database]

I was curious if anyone else has, or considered, passing both the user access token and a machine to machine access token from their bff servers to their common api service to enable authorization of the user, but also authentication of the whole request chain.

Does this make any sense? If so, are people just using two request headers to pass these tokens around.

To further the insanity, to get the users email address, wouldn’t I need to pass the user id token or call Auth0 API from our common api service?

Thanks in advance for trying to even read this.

Hi @markzb,

Welcome to the Community!

We all need a sanity check every once in a while :wink:. It sounds like you might be working around a common pattern. Can you tell us more about what you are trying to do? A quick example flow could be helpful.

Let me know,

Howdy @dan.woda,

I am trying to allow our backend system to handle user-level authorization, while also enforcing all requests to our backend system only come from our approved frontend systems. They idea would be that if an unauthorized person/application in our VPC was able to intercept the incoming valid requests, they wouldn’t be able to act as a man-in-the-middle.

For that reason, I was considering sending both a machine to machine access token to prove our frontend systems are authenticated to talk to the backend, but also the user access token to allow the backend to provide user data access/mutation authorization.

Hopefully that was additive and not just repeating my initial comment.

The user’s access token is already authenticating the request, a M2M token is not necessary. You may need a M2M for the backend to access API services, but that is seperate from the user.

You shouldn’t get M2M tokens as a SPA anyways. Anyone who has access to the React app can inspect the client and grab the client id and secret and act as the application.

@dan.woda Just confirming something you stated above.

The user’s Access Token can be trusted and used for authentication? I thought only the IdToken should be trusted for authentication based on the Auth0 docs I found.

If the access token can be trusted for authentication, why have the delineation between Id and Access tokens? Fundamentally I need the user identifier and their permissions, it would seem that I would just select the access token and forget about the IdToken.

Access Tokens must never be used for authentication. Access Tokens cannot tell if the user has authenticated. The only user information the Access Token possesses is the user ID, located in the sub claim.

Let me try documenting what I am internalizing from our conversation.

  1. SPA calls Auth0 for user login.
  2. Auth0 authenticates and calls back SPA with IdToken and AccessToken.
  3. SPA uses IdToken to verify user authentication and display user information completely on the browser.
  4. SPA calls API with Access Token in Authorization header.
  5. API uses Access Token to verify user authentication and authorization (permissions).
  6. API can respond with data.

If the above is the correct/expected flow, how does the API know who the end user is?

To resolve that question above, I added a custom claim that includes the user email into the access token, is that a potential issue?

Found what I was looking for here:

Great! Let us know if there is anything we can do to help.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.