Hi @matt.hintzke,
Thank you for reaching out to us!
I think the easiest way to understand these relationships is by understanding the Access Tokens. Access Tokens are used in token-based authentication to allow an application to access an API. The application receives an Access Token after a user successfully authenticates and authorizes access, then passes the Access Token as a credential when it calls the target API. The passed token informs the API that the bearer of the token has been authorized to access the API and perform specific actions specified by the scope that was granted during authorization. See: Access Tokens
Auth0 supports only one resource identifier (“audience”) per access token, but an access token can carry multiple scopes (and custom claims). If an app requires access to multiple resource servers, the app will need to ask for different access tokens (or create one global resource server with multiple scopes).
Applications can request an ID Token (where the audience is the web app itself, and carries information about the user), but can also request an access token where the audience is the resource server, by including the “audience” parameter in the request.
Let’s say that you didn’t want to have all your APIs/Apps share the same “Auth0 Application”, as proposed in the api-auth0 documentation. Also, if you wanted each to be its own Auth0 Application.
You can use Auth0 to request both:
ID token, with information about the user, where the audience is the client app itself.
Access token, with maybe permissions, scopes, where the audience is the backend API (“resource server”). This is done by adding the “audience=xxxx” parameter in the authorize request.
The app should use the ID token to get information about the user, like name, email, roles and so on.
The app should use the Access token to make requests to the resource server.
In summary, Auth0 provides the 2 tokens the id token and access token which both are in JWT format. The id token will stay in the application and the access token will be used to make requests to its unique resource server. We usually recommend to model a single conceptual resource server (taking Google as an example, that would be the “Google API”) with different scopes to model different access permissions (e.g. “read:email”, “read:contacts”, “write:files”, and so on.)
But you can still model different APIs (resource servers) in Auth0, just keep in mind that applications will have to request multiple tokens if they need to access multiple APIs.
Please let me know if this makes sense and help you understand the relationships.