Secure a CLI with Auth0
The three ways to secure a CLI with Auth0, in order of most secure to least secure, are:
Resource Owner Password Grant Flow (not recommended)
The first option can be used when a browser cannot be opened, while the second option is for applications acting on their own behalf and not attributable to a user. The third option is only when you're attempting to authenticate the CLI client itself, which is a very rare situation.
With input-constrained devices that connect to the internet, rather than authenticate the user directly, the device asks the user to go to a link on their computer or smartphone and authorize the device. This avoids a poor user experience for devices that do not have an easy way to enter text. To do this, device apps use the Device Authorization Flow (drafted in OAuth 2.0), in which they pass along their Client ID to initiate the authorization process and get a token.
Client Credentials Grant Flow
Use the Client Credentials Grant (CCG) flow when users and downstream identity providers aren't involved, and you want to authenticate based on distinct machines or devices.
Resource Owner Password Grant Flow
We do not recommend using the Resource Owner Password Grant (ROPG) flow for native applications. In the RFC 8252 OAuth 2.0 for Native Apps from the Internet Engineering Task Force (IETF), it is recommended that “OAuth 2.0 authorization request from native apps should ONLY be made through external user-agents, primarily the user’s browser”. For details, see RFC 8252 Embedded User-Agents.
Using Resource Owner Password Grant (ROPG) are less secure than the redirect-based options described above. ROPG is only for legacy. In the context of CLIs, it only makes sense for things like connection strings where you need to support legacy programs.
If you must use ROPG in your native app instead of Device Flow as we recommend, then you can use our OIDC Compliant ROPG endpoint.