Hello
We have an application stack which has a few api servers. Normally, users will communicate with this api using a client application but we want to enable the users to communicate with our api servers via scripts, daemons etc. As such, the machine 2 machine feature of auth0 comes close but won’t suffice since the client (for eg the automation script created by the user) has to act on behalf of the user. I found a similar topic here User context with m2m application. Also what I am looking for it’s very similar to the personal access tokens provided by Github. A similar topic was created here Server API authorization tokens for non-interactive applications but it is an old post so no idea if things have changed.
We are also open to storing the access token ourselves if such a solution is not provided by auth0, in which case can we integrate this token with Auth0 so that we don’t have to write our own handler for such tokens.
Hi @Beezlabs,
Welcome to the Community!
We haven’t released a feature dedicated to this use-case. The topic you like still represents the best guidance we have as far as I know. This post in particular:
There are probably a few ways to accomplish this, but they are going to be in this same vein as what jmangelo described.
If you have a moment, please submit a product feedback ticket so we can track the demand and better understand your use-case:
Thanks,
Dan
Thanks for the response Dan.
As I understand, making a client application go through the OAuth dance is the recommended approach but what about headless clients like a shell script or an IOT device. If my understanding is correct, in the OAuth flow, user interaction is necessary. This would be very difficult in headless scenarios.
Do you have any recommendations for this?
I was looking into Device Flow but this is something that I have never implemented. So, I don’t know if this could be a solution to my requirement. If I understand correctly, device flow allows a client to access resources on a server on behalf of the user and as such can be used on a shell script too. The only drawback that I see is that unlike a Personal Access Token which can have large expiries, the token generated by Device Flow is bound to the expiry restrictions of OAuth tokens. This means that if this headless client doesn’t access the Auth server for a long time, enough to expire the refresh token, the user will need to re-authorize.
Is my line of thought correct?
Device flow works great for IoT devices. That is the intended use-case. It is for a case where the device has limited or no input, and a second device (like a smartphone) can act as the browser.
A refresh token acts like a long lived credential. This may be a solution. A refresh token allows the device to get access tokens.
Auth0 refresh tokens don’t expire.
Does this clear up some of your questions?
Yes, that indeed clears up my issues. Thanks, we have a way forward now. Time to see if we can do it fruitfully!
Let me know if you run into anything!
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.