I’ve seen some confusing info between the Auth0 docs and some comments online, so I’d like to make sure I’m doing this correctly since I can’t tell which is more up to date. BTW I’m using the OIDC conformant switch in my tenant and not using any of the legacy endpoints.
For my setup, I have a server that uses the Management API to do a few user operations (create/update/delete, etc). This server also does some things not related to Auth0 where it accesses resources that require a valid user (like access my Azure databases). The server gets its own management API access token that it uses for all operations (via oauth/token endpoint, using my custom API as the audience). I then have a client, which specifies the audience as the same custom API. After logging in, the client now has an id_token and an access_token. The client uses the id_token info to get various profile info (user id, metadata). If the client needs to make a request to the server, it passes its access token. The server then needs to validate the client’s access token before allowing it to do any operations. Currently, since the client access token is a JWT due to having my custom api specified as the audience, I’m using one of the jwt.io suggested libraries to validate this token using my public certificate. If it’s valid, my server continues to process the request, otherwise it bails out with an unauthorized error.
I have a few questions about my setup.
- Should my client even be specifying my custom API as an audience? Or should I configure it so it’s just getting an opaque string for an access token? I realized I’m not actually using this access token for any requests, since the server uses its management API access token. I’m just using the client one to verify that the user has signed in and is legit.
- If in #1 my token is just opaque and thus not a JWT, how do you actually verify it? I’ve seen forum posts that calling the /userinfo endpoint will result in issues with too many requests sometimes. I’d hate to have a large user base making a lot of calls only to run afoul of whatever the rate limit is, so I’m guessing there’s another way to validate it.
- For some things, my server would like to have the user’s info. What would be the best method to do this? I could call /userinfo with their opaque access token, but see #2 for rate concerns. I could specify my custom API as the audience so the client’s access token is a JWT which I can then decode (as it contains their user info due to my rule setup). Or lastly, the client could send their id token, which I could then verify (via the process I mentioned I do earlier) and then use to fill in the user’s info. Note that the id token wouldn’t be used to make any requests in this case, just to verify that they are legit and thus let them access my resources.