Hello,
We are caught in a stormpath migration dilemma. Our application currently depends on stormpath’s getApiKeys functionality, which allows authenticated users to create key/secret pairs that allow them to make calls to our API, where stormpath decodes this API token and authenticates the user.
My question is, does Auth0 provide a mechanism to dynamically generate a token/secret like this, which we can use in lieu of a username/password login?
Ideally, we’d like to:
Allow on-demand generation/expiration of a token/secret
Not be responsible for storing this token/secret
I’ve seen this thread detailing how to implement API keys, however from what I can tell it looks like we’d be providing a static app_id and app_secret to a customer, is there any way for the customer to generate/expire these tokens on-demand?
The thread you mentioned was more about dealing with one of the most common scenarios for which API keys are used, the one where your API is pretty much sold as a service. In particular, the API is a generic one and has pretty much no notion of individual end-users, that is, you would provide the API keys to an organization/individual that is your customer and you would not really care if they shared it or not because the API itself does not work against individual end-user data and the key is pretty much just to know to which customer to address the bill associated with the number of calls: I’ll update the original answer to make this more clear.
On the other hand your scenario seems to be more focused on letting individual end-users access the same service you provide in your own client application through a different mechanism (I’m assuming direct HTTP calls) and without having to disclose their username and password as part of that process, in particular, the API would need to be called with the identity of each individual end-user. For this scenario, client credentials does not seem a good fit; we have some additional functionality in the release pipeline that could be a better fit for it, but at this time it is not yet available and I don’t have a definitive timeline for its availability.
As additional information, if what you’re looking for is more around allowing the growth of an ecosystem of third-party applications that can consume your API on behalf of your end-users and not so much allowing end-users to directly call the API then you should consider taking a look at dynamic client registration. This would allow third-party applications to also perform the OAuth2 dance necessary to get tokens for your API and doing it in a way that would not force the end-users to directly provide their credentials to these third-party applications. Basically the end-user would still be authenticating (providing credentials) directly with your Auth0 account, but then it would grant the third-party application the ability to receive access tokens to call the API on their behalf.
The grant could also be revoked which would effectively remove the ability for the third-party application to continue to obtain access tokens. However, have in mind that the ability to remove grants is currently available through the Management API v2, so if you then wanted end-users to be able to revoke these themselves you would need to provide the suitable user interface.