I have a backend application with an API (ASP.Net Core) plus a SPA. I have managed to set-up the SPA such that the user is able to log-in via Auth0, and is able to generate an access token that can be used to authenticate with the backend application. This all works perfectly fine. The application is a multi-tenant application, so I store a user ID in the user profile that is used in the backend to make sure that the user is only able to access its own data.
Now, I want the user to access the backend API with a non-interactive 3rd party application that is not under my control. So, the user should be able to generate a token that doesn’t expire, and use this in the app. The token should be linked to a user.
It is unclear how I can manage this with Auth0. I understand that it is not safe to manage this in the SPA, and my backend application should be able to manage the token for the user, and display it only once in the SPA. This flow should be similar to Personal Access Tokens with GitHub.
How do I implement this with Auth0? Is it even possible?
At this time there’s no built-in support for end-user accessible tokens that could be used to provide access to a third-party application in a similar process to the GitHub personal access tokens you mentioned. This possibility is something on our radar and listed in the backlog, however, it’s not yet available.
At this point if a third-party application wants access to your API on behalf of an end-user then it should perform the typical OAuth2 dance where the user would authorize the application and then the application could obtain access tokens suitable for the API. This implies that the client application needs to be able to talk OAuth2 instead of just including a single-piece of data provided by the user in each request (the so called personal access token). In addition, the client application would need to be registered in Auth0 which could either be done manually or leveraging dynamic client registration.
In conclusion, if I understood your scenario correctly the so called personal tokens that could be generated by a user and just provided to any application as a quick method to allow the application to call the API on behalf of the end-user is something that is not yet available, however, access from third-party application is already supported as long as they follow the OAuth2 protocol; you mentioned non-interactive, but I’m assuming something like a command line application instead of something without any sort of interaction with the user as otherwise it would also be complex for the user to provide the personal access token so in this case the CLI could perform a one-time authorization setup much in the same way as a native application would do and in the process obtain a refresh token that would mean continued access without requiring further interaction from the user.