> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-fix-docs-5546-update-db-search.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> How to use Auth0 to secure a CLI.

# Secure a CLI with Auth0

The three ways to secure a CLI with Auth0, in order of most secure to least secure, are:

* [Device Authorization Flow](#device-authorization-flow) for when the user can't open a browser
* [Client Credentials Grant Flow](#client-credentials-grant-flow) for applications acting on their own behalf and not attributable to a user
* [Resource Owner Password Grant Flow](#resource-owner-password-grant-flow) only for when you're trying to authenticate the CLI client itself, which is a very rare situation (otherwise not recommended)

## Device Authorization Flow

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 <Tooltip tip="Authorization Flow: Authorization grant (or workflow) specified in the OAuth 2.0 framework." cta="View Glossary" href="/docs/glossary?term=Authorization+Flow">Authorization Flow</Tooltip> (drafted in OAuth 2.0), in which they pass along their <Tooltip tip="Client ID: Identification value given to your registered resource from Auth0." cta="View Glossary" href="/docs/glossary?term=Client+ID">Client ID</Tooltip> to initiate the authorization process and get a token.

The easiest way to implement the Device Authorization Flow is to follow the steps in [Call API Using Device Authorization Flow](/docs/get-started/authentication-and-authorization-flow/device-authorization-flow/call-your-api-using-the-device-authorization-flow).

To learn more about the Device Authorization Flow in <Tooltip tip="OAuth 2.0: Authorization framework that defines authorization protocols and workflows." cta="View Glossary" href="/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip>, you can review the Internet Engineering Task Force (IEFT) draft [OAuth 2.0 Authorization Grant](https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15). You can also review our article, [Device Authorization Flow](/docs/get-started/authentication-and-authorization-flow/device-authorization-flow).

## Client Credentials Grant Flow

Use the Client Credentials Grant (CCG) flow when users and downstream <Tooltip tip="Identity Provider (IdP): Service that stores and manages digital identities." cta="View Glossary" href="/docs/glossary?term=identity+providers">identity providers</Tooltip> aren't involved, and you want to authenticate based on distinct machines or devices.

If your identity provider supports sending credentials, then you should review our article, [Client Credentials Flow](/docs/get-started/authentication-and-authorization-flow/client-credentials-flow). For details on how to implement this flow, refer to [Call API Using the Client Credentials Flow](/docs/get-started/authentication-and-authorization-flow/client-credentials-flow/call-your-api-using-the-client-credentials-flow).

## Resource Owner Password Grant Flow

We do not recommend using the <Tooltip tip="Resource Owner: Entity (such as a user or application) capable of granting access to a protected resource." cta="View Glossary" href="/docs/glossary?term=Resource+Owner">Resource Owner</Tooltip> Password Grant (ROPG) flow for native applications. In the IEFT article, [RFC 8252 OAuth 2.0 for Native Apps](https://tools.ietf.org/html/rfc8252), 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](https://tools.ietf.org/html/rfc8252#section-8.12).

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](https://auth0.com/docs/api/authentication#resource-owner-password).