Allowing an application to act on behalf of the user

[Beezlabs]

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.

[dan.woda]

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:

Server API authorization tokens for non-interactive applications

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 applicati…

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:

Auth0: Secure access for everyone. But not just anyone.

Thanks,
Dan

[Beezlabs]

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?

[Beezlabs]

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?

[dan.woda]

@Beezlabs,

@Beezlabs

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.

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.

@Beezlabs

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.

A refresh token acts like a long lived credential. This may be a solution. A refresh token allows the device to get access tokens.

@Beezlabs

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.

Auth0 refresh tokens don’t expire.

Does this clear up some of your questions?

[Beezlabs]

@dan.woda

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!

[dan.woda]

Let me know if you run into anything!