Description
I am working on a platform composed of the following:
- A REST API server
- A python CLI application: it is an application that users install using pip.
The CLI application communicates with the REST API. We use Auth0 for authentication. Currently, the way we implemented authentication is as follows:
- We registered the python CLI application as a native “client” in Auth0.
- We registered the REST API server as an “API” in Auth0.
- A user will use the python CLI app to authenticate to Auth0 and obtain an ID token and access token using the Device authorization flow.
- Requests from the python CLI app to the REST API server should contain the access token with a specific API audience.
- The REST API validates the access token to make sure the request is legit.
The intended use of the platform/system
- We don’t intend to have “third party applications” requesting access to the REST API.
- We need the user’s identity in the REST API to perform correct authorization decisions. (We are inserting the email address to the access token using Auth0 actions)
- The ID token is currently received and validated by the python CLI app, but I don’t see the value of this. The python CLI app is intended to be used by a single user, not multiple users.
- We don’t intend to have multiple “resource servers”.
Question
Q1) Is it better to redesign the system so that the ID token is used instead of the access token to authenticate with the REST API?
I have read nearly all Auth0 documents and many other community resources about what is the right way of using oauth, and I see everywhere the following sentence: “Never use an ID token in a resource server”.
Q2) In my case, is the REST API still considered a resource server? Actually, does my system need Oauth?
Q3) Is there a resource of “standard authentication mechanisms” or something, that can guide me on how to make sure my authentication solution is valid and standard? Most of the Auth0 documentation have “third party apps” in mind.
Context about re-designing
I am thinking of redesigning the system so that:
- I register my REST API as a native client in Auth0. I don’t register the python CLI app.
- I use the python CLI app to request an ID token only, using the client ID of the REST API.
- The python CLI app will send the ID token to the REST API on each request.
- The REST API will validate id tokens to make sure requests are authentic.
The motive for the question
We are considering to use step-ca to issue user certificates for a use-case in our platform. We noticed that step-ca can be configured to issue certificates in exchange of ID tokens issued by okta or keycloak.
The catch is that step-ca’s client will perform device authorization flow, using the clientID that is configured in the step-ca server, obtain an ID token, and send the ID token to the step-ca server to exchange it for a certificate. Why didn’t they use access tokens? Why do they consider the step-ca server as a “client”?
Furthermore, here are some information that confused me:
-
Google’s Firebase docs mentions that if you want to identify the user in your server, send the ID token: אמת אסימוני זיהוי | Firebase Authentication. Meanwhile, Auth0 blog says that it is a common mistake to use ID tokens to call an API: ID Token and Access Token: What Is the Difference?
-
Keycloak docs mentions two usecases for openID connect: one where both ID tokens and access tokens are used by the client application/resource server, and one where ID tokens can be used on the clients application while access tokens are used in the resource server. Securing Applications and Services Guide