OAuth 2 es un marco de autorización que permite que las aplicaciones (como Facebook, GitHub y DigitalOcean) obtengan acceso limitado a las cuentas de usuario en un servicio HTTP. Funciona delegando la autenticación de usuario al servicio que aloja una cuenta de usuario y autorizando a aplicaciones de terceros a acceder a esa cuenta de usuario. OAuth 2 proporciona flujos de autorización para aplicaciones web y de escritorio, así como para dispositivos móviles.

Esta guía informativa está dirigida a los desarrolladores de aplicaciones y proporciona una descripción general de los roles de OAuth 2, los tipos de concesión de autorización, los casos de uso y los flujos.

Implemente sus aplicaciones frontend desde GitHub con la plataforma de aplicaciones DigitalOcean. Deje que DigitalOcean se concentre en escalar su aplicación.

Funciones de OAuth

OAuth define cuatro roles:

Propietario del recurso : el propietario del recurso es el usuario que autoriza a una aplicación a acceder a su cuenta. El acceso de la aplicación a la cuenta del usuario está limitado al alcance de la autorización otorgada (por ejemplo, acceso de lectura o escritura).
Cliente : El cliente es la aplicación que desea acceder a la cuenta del usuario. Para ello, debe contar con la autorización del usuario y la autorización debe ser validada por la API.
Servidor de recursos : el servidor de recursos aloja las cuentas de usuario protegidas.
Servidor de autorización : el servidor de autorización verifica la identidad del usuario y luego emite tokens de acceso a la aplicación.

Desde el punto de vista de un desarrollador de aplicaciones, la API de un servicio cumple las funciones de servidor de recursos y de servidor de autorización. Nos referiremos a ambas funciones combinadas como función de servicio o API.

Flujo de protocolo abstracto

Ahora que tienes una idea de qué son los roles de OAuth, veamos un diagrama de cómo interactúan generalmente entre sí:

A continuación se muestra una explicación más detallada de los pasos del diagrama:

La aplicación solicita autorización al usuario para acceder a los recursos del servicio.
Si el usuario autorizó la solicitud, la aplicación recibe una concesión de autorización.
La aplicación solicita un token de acceso al servidor de autorización (API) presentando la autenticación de su propia identidad y la concesión de autorización.
Si la identidad de la aplicación está autenticada y la concesión de autorización es válida, el servidor de autorización (API) emite un token de acceso a la aplicación. La autorización está completa.
La aplicación solicita el recurso al servidor de recursos (API) y presenta el token de acceso para la autenticación.
Si el token de acceso es válido, el servidor de recursos (API) sirve el recurso a la aplicación.

El flujo real de este proceso variará según el tipo de autorización que se utilice, pero esta es la idea general. Analizaremos los diferentes tipos de autorización en una sección posterior.

Registro de la aplicación

Antes de utilizar OAuth con su aplicación, debe registrarse en el servicio. Esto se hace a través de un formulario de registro en la sección de desarrolladores o API del sitio web del servicio, donde deberá proporcionar la siguiente información (y probablemente detalles sobre su aplicación):

Nombre de la aplicación
Sitio web de la aplicación
URI de redireccionamiento o URL de devolución de llamada

La URI de redireccionamiento es donde el servicio redirigirá al usuario después de que autorice (o rechace) su aplicación y, por lo tanto, es la parte de su aplicación que manejará los códigos de autorización o tokens de acceso.

ID de cliente y secreto de cliente

Una vez que se registre su aplicación, el servicio emitirá credenciales de cliente en forma de un identificador de cliente y un secreto de cliente. El ID de cliente es una cadena expuesta públicamente que la API del servicio utiliza para identificar la aplicación y también se utiliza para crear URL de autorización que se presentan a los usuarios. El secreto de cliente se utiliza para autenticar la identidad de la aplicación ante la API del servicio cuando la aplicación solicita acceder a la cuenta de un usuario y debe mantenerse privado entre la aplicación y la API.

Concesión de autorización

En el flujo de protocolo abstracto descrito anteriormente, los primeros cuatro pasos cubren la obtención de una concesión de autorización y un token de acceso. El tipo de concesión de autorización depende del método utilizado por la aplicación para solicitar la autorización y de los tipos de concesión admitidos por la API. OAuth 2 define tres tipos de concesión principal, cada uno de los cuales es útil en diferentes casos:

Código de autorización : se utiliza con aplicaciones del lado del servidor
Credenciales del cliente : se utilizan con aplicaciones que tienen acceso a API
Código de dispositivo : se utiliza para dispositivos que no tienen navegadores o tienen limitaciones de entrada

Advertencia : El marco OAuth especifica dos tipos de concesión adicionales: el tipo de flujo implícito y el tipo de concesión de contraseña . Sin embargo, estos tipos de concesión se consideran inseguros y ya no se recomienda su uso.

Ahora describiremos los tipos de subvenciones con más detalle, sus casos de uso y flujos, en las siguientes secciones.

Tipo de subvención: Código de autorización

El tipo de concesión de código de autorización es el más utilizado porque está optimizado para aplicaciones del lado del servidor, donde el código fuente no se expone públicamente y se puede mantener la confidencialidad del secreto del cliente. Se trata de un flujo basado en redirección, lo que significa que la aplicación debe ser capaz de interactuar con el agente de usuario (es decir, el navegador web del usuario) y recibir códigos de autorización de API que se enrutan a través del agente de usuario.

Ahora describiremos el flujo del código de autorización:

Paso 1: Enlace del código de autorización

En primer lugar, se le proporciona al usuario un enlace con un código de autorización que se parece al siguiente:

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=codeclient_id=CLIENT_IDredirect_uri=CALLBACK_URLscope=read

A continuación se muestra una explicación de los componentes de este enlace de ejemplo:

** https://cloud.digitalocean.com/v1/oauth/authorize**: el punto final de autorización de API
id_cliente=id_cliente: el ID del cliente de la aplicación (cómo la API identifica la aplicación)
redirección_uri=URL DE DEVOLUCIÓN DE LLAMADA:donde el servicio redirige al agente de usuario después de que se otorga un código de autorización
tipo_de_respuesta=código: especifica que su aplicación está solicitando una concesión de código de autorización
alcance=mirada lasciva: especifica el nivel de acceso que solicita la aplicación

Paso 2: El usuario autoriza la aplicación

Cuando el usuario hace clic en el enlace, primero debe iniciar sesión en el servicio para autenticar su identidad (a menos que ya haya iniciado sesión). Luego, el servicio le solicitará que autorice o deniegue el acceso de la aplicación a su cuenta. A continuación, se muestra un ejemplo de solicitud de autorización de la aplicación:

Esta captura de pantalla en particular es de la pantalla de autorización de DigitalOcean e indica que la aplicación Thedropletbook está solicitando autorización para el acceso de lectura a la cuenta de manicas@digitalocean.com.

Paso 3: La aplicación recibe el código de autorización

Si el usuario hace clic en Autorizar aplicación, el servicio redirige al agente de usuario a la URL de redirección de la aplicación, que se especificó durante el registro del cliente, junto con un código de autorización. La redirección se vería así (suponiendo que la aplicación es dropletbook.com):

https://dropletbook.com/callback?code=AUTHORIZATION_CODE

Paso 4: La aplicación solicita el token de acceso

La aplicación solicita un token de acceso de la API al pasar el código de autorización junto con los detalles de autenticación, incluido el secreto del cliente, al punto final del token de la API. A continuación, se muestra un ejemplo de POSTsolicitud al punto final del token de DigitalOcean:

https://cloud.digitalocean.com/v1/oauth/token?client_id=CLIENT_IDclient_secret=CLIENT_SECRETgrant_type=authorization_codecode=AUTHORIZATION_CODEredirect_uri=CALLBACK_URL

Paso 5: La aplicación recibe el token de acceso

Si la autorización es válida, la API enviará una respuesta que contiene el token de acceso (y, opcionalmente, un token de actualización) a la aplicación. La respuesta completa será similar a la siguiente:

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"mark@thefunkybunch.com"}}

Ahora la aplicación está autorizada. Puede usar el token para acceder a la cuenta del usuario a través de la API del servicio, limitado al alcance del acceso, hasta que el token caduque o sea revocado. Si se emite un token de actualización, se puede usar para solicitar nuevos tokens de acceso si el token original está caducado.

Nota sobre la clave de prueba para el intercambio de códigos

Si un cliente público utiliza el tipo de concesión de código de autorización, existe la posibilidad de que el código de autorización pueda ser interceptado. La clave de prueba para el intercambio de códigos (o PKCE, que se pronuncia como “pixie”) es una extensión del flujo de código de autorización que ayuda a mitigar este tipo de ataque.

La extensión PKCE implica que el cliente crea y registra una clave secreta (conocida como verificador de código) para cada solicitud de autorización. Luego, el cliente transforma el verificador de código en un desafío de código y luego envía este desafío de código y el método de transformación al punto final de autorización en la misma solicitud de autorización.

El punto final de autorización registra el desafío del código y el método de transformación, y responde con el código de autorización como se describió anteriormente. Luego, el cliente envía la solicitud de token de acceso que incluye el verificador de código que generó originalmente.

Después de recibir el verificador de código, el servidor de autorización lo transforma en el código de desafío utilizando el método de transformación que compartió primero el cliente. Si el código de desafío derivado del verificador de código enviado por el cliente no coincide con el registrado originalmente por el servidor de autorización, entonces el servidor de autorización denegará el acceso al cliente.

Se recomienda que cada cliente utilice la extensión PKCE para mejorar la seguridad.

Tipo de subvención: Credenciales del cliente

El tipo de concesión de credenciales de cliente proporciona a una aplicación una forma de acceder a su propia cuenta de servicio. Algunos ejemplos de casos en los que esto puede resultar útil incluyen si una aplicación desea actualizar su descripción registrada o redirigir la URI, o acceder a otros datos almacenados en su cuenta de servicio a través de la API.

Flujo de credenciales del cliente

La aplicación solicita un token de acceso enviando sus credenciales, su ID de cliente y su secreto de cliente al servidor de autorización. Un ejemplo de POSTsolicitud podría ser similar al siguiente:

https://oauth.example.com/token?grant_type=client_credentialsclient_id=CLIENT_IDclient_secret=CLIENT_SECRET

Si las credenciales de la aplicación son correctas, el servidor de autorización devuelve un token de acceso a la aplicación. Ahora la aplicación está autorizada a usar su propia cuenta.

Nota : DigitalOcean actualmente no admite el tipo de concesión de credenciales de cliente, por lo que el enlace apunta a un servidor de autorización imaginario en oauth.example.com.

Tipo de subvención: Código de dispositivo

El tipo de concesión de código de dispositivo proporciona un medio para que los dispositivos que carecen de un navegador o tienen entradas limitadas obtengan un token de acceso y accedan a la cuenta de un usuario. El propósito de este tipo de concesión es facilitar a los usuarios la autorización más sencilla de las aplicaciones en dichos dispositivos para acceder a sus cuentas. Algunos ejemplos de casos en los que esto podría ser útil incluyen si un usuario desea iniciar sesión en una aplicación de transmisión de video en un dispositivo que no tiene una entrada de teclado típica, como un televisor inteligente o una consola de videojuegos.

Flujo de código del dispositivo

El usuario inicia una aplicación en su dispositivo sin navegador o con limitaciones de entrada, como un televisor o un decodificador. La aplicación envía una POSTsolicitud a un punto final de autorización del dispositivo.

Un ejemplo POSTde solicitud de código de dispositivo podría ser así:

POST https://oauth.example.com/deviceclient_id=CLIENT_id

El punto final de autorización del dispositivo es diferente del servidor de autenticación, ya que el punto final de autorización del dispositivo en realidad no es auténtico el dispositivo. En cambio, devuelve un código de dispositivo único, que se utiliza para identificar el dispositivo; un código de usuario, que el usuario puede ingresar en una máquina en la que es más fácil autenticarse, como una computadora portátil o un dispositivo móvil; y la URL que el usuario debe visitar para ingresar el código de usuario y autenticar su dispositivo.

Así es como podría ver un ejemplo de respuesta del punto final de autorización del dispositivo:

{  "device_code": "IO2RUI3SAH0IQuESHAEBAeYOO8UPAI",  "user_code": "RSIK-KRAM",  "verification_uri": "https://example.okta.com/device",  "interval": 10,  "expires_in": 1600}

Tenga en cuenta que el código del dispositivo también podría ser un código QR que el lector puede escanear en un dispositivo móvil.

A continuación, el usuario introduce el código de usuario en la URL especificada e inicia sesión en su cuenta. A continuación, se le presenta una pantalla de consentimiento en la que puede autorizar al dispositivo a acceder a su cuenta.

Mientras el usuario visita la URL de verificación e ingresa su código, el dispositivo sondeará el punto final de acceso hasta que devuelva un error o un token de autenticación. El punto final de acceso devolverá errores si el dispositivo sondea con demasiada frecuencia (el slow_downerror), si el usuario aún no autorizado o rechaza la solicitud (el authorization_pendingerror), si el usuario rechaza la solicitud (el access_deniederror) o si el token venció ( el expired_tokenerror).

Sin embargo, si el usuario aprueba la solicitud, el punto final de acceso devolverá un token de autenticación.

Nota : Nuevamente, DigitalOcean actualmente no admite el tipo de concesión de código de dispositivo, por lo que el enlace en este ejemplo apunta a un servidor de autorización imaginario en oauth.example.com.

Ejemplo de uso de token de acceso

Una vez que la aplicación tenga un token de acceso, puede usarla para acceder a la cuenta del usuario a través de la API, limitado al alcance del acceso, hasta que el token caduque o sea revocado.

A continuación se muestra un ejemplo de una solicitud de API que utiliza curl. Tenga en cuenta que incluye el token de acceso:

curl -X POST -H "Authorization: Bearer ACCESS_TOKEN""https://api.digitalocean.com/v2/$OBJECT"

Suponiendo que el token de acceso sea válido, la API procesará la solicitud de acuerdo con sus especificaciones. Si el token de acceso ha caducado o no es válido, la API devolverá un invalid_requesterror.

Flujo de actualizacion de tokens

Una vez que un token de acceso caduca, su uso para realizar una solicitud desde la API generará un Invalid Token Error. En este punto, si se incluye un token de actualización cuando se emitió el token de acceso original, se puede utilizar para solicitar un token de acceso nuevo al servidor de autorización.

A continuación se muestra un ejemplo de POSTsolicitud que utiliza un token de actualización para obtener un nuevo token de acceso:

https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_tokenclient_id=CLIENT_IDclient_secret=CLIENT_SECRETrefresh_token=REFRESH_TOKEN

Conclusión

Al seguir esta guía, comprenderá cómo funciona OAuth 2 y cuándo se debe utilizar un flujo de autorización en particular.

Si desea obtener más información sobre OAuth 2, consulte estos valiosos recursos:

Cómo utilizar la autenticación OAuth con DigitalOcean como usuario o desarrollador
Cómo utilizar la API v2 de DigitalOcean
Documentación de referencia de la API OAuth de DigitalOcean
El marco de autorización OAuth 2.0

Deja una respuesta Cancelar la respuesta

Introducción a OAuth 2

Introducción