How to implement a developer portal flow

Help
,
1

I am trying to implement a developer portal flow but have trouble mapping the idea in my head to the auth0 api. Here is what I am trying to do:

  • I have a Developer Portal application that users can log into (easy to implement with auth0)
  • I have an api that I want authenticated users to be able to call
  • each user in the developer portal can create some kind of “application” that is granted certain scopes to the api
  • a token is generated in the user interface for each of these applications that the developer can put into their serverside apps to call the api
  • these tokens can be expired or deleted in case they are compromised

The way I was thinking of implementing it was as follows:

  • a web application for developer portal
  • an api with developer portal allowed as machine-to-machine application
  • when the user creates a new “application” in the portal, I create a refresh token for the api on behalf of that user and display it as “token”
  • the token can be revoked since it is a refresh_token
  • when the user wants to call the api they first get an access_token using the refresh_token and can then make api calls until the access_token expires at which point they need to get another one

So far the only part I am having trouble with is to generate the refresh token for api access on behalf of the user. The oauth/token endpoint does not return a refresh_token as per spec.

Is there a better way to implement this flow?

2

Hi there! I realize this answer comes a little late, but hopefully it can provide some value.

The proper way to implement this would be to create, through the developer portal, a third-party application for each of your customers that request a registration. You would use the Management API v2 to create them.

The type of application that you will create (machine-to-machine, regular web app, and so on) will depend on the type of capabilities that you want to give to your customers. I.e. will they be able to let their users to authenticate interactively, or will they just be creating machine-to-machine interactions? If your users will be building interactive applications as well, you will probably need to ask for callback URLs.

As a result of the application creation, you will get a client ID and client secret (although it makes little sense to share it in SPA/Native application types). Your customers will need to use your Auth0 domain to request interactive authorizations (/authorize) or to request tokens directly (/oauth/token).

Hope that makes sense!

3

Thank you for the answer and suggested approach. This is more or less exactly what I have implemented now.
Each of my clients logs into the developer portal with their user account. Using the management api the developer portal creates new 3rd party applications. I opted for the slightly hacky approach of encoding the originating user in the 3rd party application name. (maybe there is a better way or you can support some sort of tagging of applications in the future?)

For example:
The user has an id of “auth0|12345”. When the user creates a new application in their developer account of name “User App”, then I create the 3rd party application (M2M) with name “auth0|12345|User App”.

This allows me to associate those applications with different user accounts without needing my own database which may go stale.

4

I suppose that approach should work at least for some time. A few random thoughts:

  • I would probably keep some kind of storage on your side with the relationship between user_id and client_id to facilitate management/search. You might even find in the future that this simple relationship might not be enough. I.e. you might probably end up having many users related to one single customer, and a third part application (or many) associated to a customer instead of directly to a user.
  • You might probably want to have separate auth0 tenants, one for handling access to your developer portal, and one to handle authorization for your API (where users of your customers will log in), since the set of users accessing each might be potentially very different.
  • If you find areas where the dashboard or other part of the products are not handling this use case very well, I encourage to leave detailed feedback at Auth0: Secure access for everyone. But not just anyone.. This is very valuable for the Product team to prioritize efforts.