> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Cómo usar Auth0 para proteger una CLI.

# Proteger una CLI con Auth0

Las tres formas de proteger una CLI con Auth0, en orden de más segura a menos segura, son:

* [Flujo de autorización de dispositivo](#device-authorization-flow) para cuando el usuario no puede abrir un navegador
* [Flujo de concesión de credenciales de cliente](#client-credentials-grant-flow) para aplicaciones que actúan en su propio nombre y no pueden atribuirse a un usuario
* [Flujo de concesión de contraseña del propietario de recursos](#resource-owner-password-grant-flow) solo cuando se intenta autenticar la propia CLI como cliente, lo cual es una situación muy poco frecuente (en otros casos, no se recomienda)

<div id="device-authorization-flow">
  ## Flujo de autorización de dispositivo
</div>

Con dispositivos con capacidad de entrada limitada que se conectan a internet, en lugar de autenticar al usuario directamente, el dispositivo le pide que visite un enlace en su computadora o smartphone y autorice el dispositivo. Esto evita una mala experiencia de usuario en dispositivos que no tienen una forma sencilla de introducir texto. Para ello, las aplicaciones para dispositivos usan el <Tooltip tip="Flujo de autorización: concesión de autorización (o flujo de trabajo) especificado en el marco de OAuth 2.0." cta="Ver glosario" href="/es/docs/glossary?term=Authorization+Flow">Flujo de autorización</Tooltip> de dispositivos (definido en OAuth 2.0), en el que envían su <Tooltip tip="ID de cliente: valor de identificación asignado a su recurso registrado por Auth0." cta="Ver glosario" href="/es/docs/glossary?term=Client+ID">ID de cliente</Tooltip> para iniciar el proceso de autorización y obtener un token.

La forma más sencilla de implementar el Flujo de autorización de dispositivo es seguir los pasos de [Llamar a una API mediante el Flujo de autorización de dispositivo](/es/docs/get-started/authentication-and-authorization-flow/device-authorization-flow/call-your-api-using-the-device-authorization-flow).

Para obtener más información sobre el Flujo de autorización de dispositivo en <Tooltip tip="OAuth 2.0: marco de autorización que define protocolos y flujos de trabajo de autorización." cta="Ver glosario" href="/es/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip>, puede consultar el borrador de la Internet Engineering Task Force (IEFT) [OAuth 2.0 Authorization Grant](https://tools.ietf.org/html/draft-ietf-oauth-device-flow-15). También puede consultar nuestro artículo, [Flujo de autorización de dispositivo](/es/docs/get-started/authentication-and-authorization-flow/device-authorization-flow).

<div id="client-credentials-grant-flow">
  ## Flujo de concesión de credenciales de cliente
</div>

Utilice el flujo Client Credentials Grant (CCG) cuando no intervengan usuarios ni <Tooltip tip="Proveedor de identidad (IdP): servicio que almacena y gestiona identidades digitales." cta="Ver glosario" href="/es/docs/glossary?term=identity+providers">proveedores de identidad</Tooltip> posteriores, y desee autenticarse mediante máquinas o dispositivos concretos.

Si su proveedor de identidad admite el envío de credenciales, debe revisar nuestro artículo [Flujo de credenciales de cliente](/es/docs/get-started/authentication-and-authorization-flow/client-credentials-flow). Para obtener más información sobre cómo implementar este flujo, consulte [Llamar a una API mediante el flujo de credenciales de cliente](/es/docs/get-started/authentication-and-authorization-flow/client-credentials-flow/call-your-api-using-the-client-credentials-flow).

<div id="resource-owner-password-grant-flow">
  ## Flujo de concesión de contraseña del propietario de recursos
</div>

No recomendamos usar el flujo <Tooltip tip="Propietario del recurso: entidad (como un usuario o una aplicación) capaz de conceder acceso a un recurso protegido." cta="Ver glosario" href="/es/docs/glossary?term=Resource+Owner">Resource Owner</Tooltip> Password Grant (ROPG) para aplicaciones nativas. En el artículo del IETF, [RFC 8252 OAuth 2.0 para aplicaciones nativas](https://tools.ietf.org/html/rfc8252), se recomienda que “las solicitudes de autorización de OAuth 2.0 desde aplicaciones nativas SOLO se hagan a través de agentes de usuario externos, principalmente el navegador del usuario”. Para obtener más información, consulta [RFC 8252 Embedded User-Agents](https://tools.ietf.org/html/rfc8252#section-8.12).

El uso de Resource Owner Password Grant (ROPG) es menos seguro que las opciones basadas en redirección descritas anteriormente. ROPG es solo para sistemas heredados. En el contexto de las CLI, solo tiene sentido en casos como las cadenas de conexión, en los que necesitas admitir programas heredados.

Si debes usar ROPG en tu aplicación nativa en lugar de Device Flow, como recomendamos, puedes usar nuestro [endpoint de ROPG compatible con OIDC](https://auth0.com/docs/api/authentication#resource-owner-password).