I’m trying to grant a user access to my API through a CLI application. Logging in via a web browser the way some other tools do would be fine, but I can’t find an example of this. Ideally it would work cross platform and written in Node. Has anyone built something like this?
Welcome to the Community!
You have a few options for securing a CLI application:
- Device Authorization Flow
- Client Credentials Grant Flow
- Resource Owner Password Grant Flow (not recommended)
Since you’d like to authenticate the user and not the application itself, it sounds like you’re looking for the Device Authorization Flow.
I don’t have an example node CLI, but this guide walks you through the steps for setting this up (You can log in to follow along with your own application settings):
Thanks, this article I found is more what I’m talking about: Browser SSO for CLI Applications. Command Line Applications are programs… | by Hasintha Indrajee | Medium.
I also investigated the client credentials flow, but it looks like you can’t have a token that lives longer than 30 days? Is there a way to generate a much longer lived client credentials token? Or is there a way to manually generate tokens?
It looks like the article covers the Authorization Code Flow. This flow is recommended for regular web apps (or SPAs when used with PKCE). For CLI, it’s recommended to use either the client credentials or device flow instead of the authorization code flow.
The device flow is somewhat similar to authorization code flow, but it is designed specifically for input-restrained devices or scenarios where the client does not run in the browser.
(It looks like RFC 8628 - OAuth 2.0 Device Authorization Grant became a proposed standard in Aug 2019, so my guess is there are some resources for using Authorization Code flow for CLIs written before this became a standard .)
For client credentials, you are correct about the Access Token lifetime restriction of 30 days. When the expiration date is met, your app would need to request a new Access Token. Client credentials flow does not involve a browser at all, and so an end user would not need to actually log in for authentication. In other words, the CLI would handle the authentication request without any end-user interaction.
If you want to authenticate end users in the browser, then you’d use the device flow. In order to prevent the need for the end user to log in every time their Access Token expires, you can set up your app to use refresh tokens. (Refresh tokens are not supported in the client credentials flow, but they are supported in the device flow.) When the Access Token expires, your app would be able to request a new Access Token without requiring the end-user to log in again by using a Refresh Token.
I think the article is using the standard flow, but setting up a webserver locally to retrieve the returned token when Auth0 callsback after authenticating on the web. Anyway, I’ll continue to investigate.
Regarding the client credentials flow, my scenario is that I’m giving out tokens to third parties who will use the token to send data to my API from their servers. Like how a service like datadog will give you an API token to send them analytics. So a 30 day lifetime is too short and refresh tokens won’t work.
I’ve fixed this by generating and authenticating my own tokens, though it would be good if there was an auth0 way of doing this.
That makes sense! Thanks for providing additional context.
I don’t believe there is a built-in solution for a setup like you’ve described. The closest OAuth flow would be client credentials. Each third party would have its own machine-to-machine application so that when they need to use your API, they can use their own client ID and secret to get an Access Token.
It would be great to get more information about your use case for our product team to review! You can create a feature request in our feedback category: