Zach, let me address first the concepts the usage of Access Tokens vs ID Tokens. The following is based on one of the videos created by Vittorio in our “Learn Identity” series: Calling an API
On the “Calling an API” video, on 33:27, you can hear Vittorio recap on “Access tokens vs ID tokens”.
Here are the highlights of his recap:
Access Token:
-
An access token is meant to grant a client access to a resource (delegated authorization).
-
Per the OAuth 2.0 spec, there is no mandated format for the Access Token but most people, Auth0 included, use JWTs.
-
Clients can request and use access tokens but not inspect them.
ID Token:
-
ID Tokens are meant to signal that a successful authentication occurred. These tokens are designed to support sign-in and authentication information.
-
Per the OIDC spec, the ID token is formatted as a JWT.
-
An ID Token should never be sent to any entity other than the client itself.
Vittorio points out that there is a lot of controversy about this. The ID token is really designed for sign in, and so, usually, once you receive it, that means that you are the client because the receiver and recipient of the token are the same entity. So, normally the ID token shouldn’t travel farther.
Vittorio also mentioned that there are situations in which, from a security perspective, it’s potentially okay to use the ID token for making a call to an API. Those situations are largely limited to a case in which the client, as in the component that calls APIs, and the API itself happen to be the same logical application.
In this case, you don’t necessarily need delegation information because you are just a first-party app. From a security perspective, there are a number of flows in which having acquired the ID token or the access token makes no difference, or makes no discernible difference. This may be your case.
An ID token could be seen as an access token with specialized semantics. So, as long as the audience that you have in the ID token corresponds to the identifier of your app you could do that; that is, it’s all within the logical boundaries of an application. Just never send the ID token to a third-party API. This should always be targeted to your own application, the same application that requested it.
However, Vittorio warns that it’s very controversial because a lot of people will simply argue that the specification says you should use an access token, but the specification doesn’t really cover the first-party scenario. It’s really designed to describe the third-party scenario, but you end up arguing semantics.
So, unless there is a huge advantage in terms of convenience under the first-party app model, it’s recommended to use the access token.
The scope of this blog post is to provide guidance for a web application that uses a client-server architecture where the client is in charge of authenticating the user and obtaining the ID token and the access token. The client then sends the access token to the server to make requests on behalf of the user and the server uses the access token to determine the access level the user has. Here, we recommend using the access token for delegated authorization and using the ID token as the result of authentication in an OIDC context and to encapsulate user information that is consumed by the client application.
Since you are following a different architecture that warrants a different level of discussion beyond the scope of this tutorial, I recommend for you to start a separate thread under the General category, please:
This will help us provide you with better visibility and advice on this particular topic and we could also understand better your architecture and scenario with the things that are unique to your application.
In that thread, I’ll recommend that you share with us a more detailed description of what you currently have: for example, what is the client, what is the server, perhaps with a flow diagram.
This detailed document on Authorization may also help further distinguish the boundaries of authorization in an application stack: