Header Ads Widget

Ticker

6/recent/ticker-posts

8 poderes y flujos vitales de OAuth

 Daniel Lindau de Curity proporciona una descripción general de importantes flujos y habilidades de OAuth.


El espacio de API requiere autorización para proteger los datos; esto es un hecho en la era moderna. En consecuencia, implementar el sistema de autorización correcto es de vital importancia, quizás incluso más importante que la API para la que debe manejar la autorización.

OAuth es una solución poderosa para muchos proveedores. Sin embargo, al igual que con cualquier herramienta, es tan poderosa como la entiende el usuario que la elige. Comprender qué es OAuth y, al menos, tener una descripción general de cada flujo en particular es extremadamente importante. En este artículo, veremos OAuth y daremos un breve resumen de cada tipo de flujo . Veremos cuándo es apropiado cada flujo y cuál es su caso de uso específico.

¿Qué es OAuth? ¿Qué es un "flujo"?

Si bien no hace falta decirlo, es beneficioso indicar por adelantado exactamente qué es OAuth. OAuth es un estándar abierto para la delegación y autorización en Internet . El caso de uso de OAuth suele ser un cliente que necesita acceder a algún recurso en nombre del usuario. Para realizar esta delegación, se emite un token de acceso . El token de acceso representa el consentimiento que dio el usuario, permitiendo al cliente acceder a sus datos en nombre del usuario. La solicitud, concesión y gestión de la vida de este token a menudo se denomina “flujo”, un término que se utilizará sustancialmente a lo largo de este artículo.

Si bien la primera versión de OAuth se creó inicialmente en 2007 como un medio para manejar la autenticación en la API de Twitter, desde entonces se ha vuelto extremadamente popular en una variedad de aplicaciones con alcances que van desde bases de código de nivel empresarial hasta proyectos domésticos. La segunda versión, OAuth 2.0 , se ha convertido en el estándar de facto para proteger de forma segura sus API.

Los flujos difieren según el caso de uso

La especificación OAuth permite varias formas de obtener y validar tokens, y no todos los flujos están destinados a todos los tipos de clientes. La especificación de OAuth habla de clientes públicos y privados, lo que se traduce aproximadamente en la capacidad de los clientes para mantener sus credenciales almacenadas de forma segura. Los clientes privados suelen ser aplicaciones con un backend que puede mantener un secreto para usar en la autenticación. Los clientes públicos no tienen forma de mantener un secreto de forma segura, por ejemplo, una aplicación de una sola página que generalmente no tiene un backend.

Por ejemplo, las aplicaciones web con backend se consideran clientes privados y las aplicaciones de una sola página se consideran públicas. El backend puede guardar el secreto de forma segura, mientras que el SPA tiene todo a la vista.

Los clientes móviles son un poco más difíciles de clasificar, ya que en general son bastante buenos para guardar un secreto, pero es difícil darles uno. La forma en que se distribuyen las aplicaciones a través de las tiendas de aplicaciones dificulta que los clientes se autentiquen de manera que el servidor OAuth confíe en que es la aplicación correcta. Por este motivo, deben considerarse públicos . Al utilizar otros medios para obtener credenciales, como el registro de cliente dinámico , se puede convertir en un cliente privado. Pero más sobre eso más adelante.

Obtención de tokens

Hay cuatro flujos básicos para obtener tokens en OAuth y varios flujos que se definen en las especificaciones de los hermanos. Aquí describiré los flujos base y otros que considero importantes.

1. Concesión del código de autorización

La concesión de código de autorización , o flujo de código , es el flujo de OAuth más extendido. Para obtener un token usando el flujo de código, los clientes envían una solicitud de autorización al servidor OAuth simplemente redireccionando el navegador al servidor. El servidor OAuth se asegura de que el usuario esté autenticado y le solicita que apruebe la delegación. Cuando el usuario aprueba, se emite un código de corta duración al cliente. Este código puede considerarse una contraseña de un solo uso o un nonce . El cliente recibe este código y ahora puede usarlo en una llamada de backend autenticada, fuera del navegador, y cambiarlo por el token.

Una cosa para mencionar aquí es que el usuario solo ingresará sus credenciales en el servidor OAuth. El usuario no tendrá que dar las credenciales a la aplicación, simplemente las ingresa al servidor que ya conoce y en el que confía. Esto es algo que OAuth se propuso resolver.

El otro beneficio es que el propietario del token pasa el navegador, lo que dificulta el robo, y dado que la llamada para intercambiar el token está autenticada, el servidor puede estar seguro de que entrega el token al cliente correcto.

Por lo general, el flujo de código también le permitirá recibir un Token de actualización , que le permite al cliente obtener nuevos tokens de acceso sin involucrar al usuario. Incluso después de que expire el token de acceso. El flujo de código solo debe ser utilizado por clientes privados, ya que el cliente necesita autenticarse cuando intercambia el código.

Flujo de código : el cliente consta de dos partes, el navegador y el backend

2. Flujo implícito

El flujo implícito es un flujo menos complicado que el flujo de código . Comienza de la misma manera que el flujo de código, con el cliente realizando una solicitud de autorización al servidor OAuth. El usuario se autentica y aprueba la delegación, pero en lugar de emitir un código, el servidor OAuth responde con un token de acceso.

La desventaja aquí es, por supuesto, que el token es visible en su totalidad y, dado que está en el navegador, el cliente debe manejar el token de una manera que podría hacerlo vulnerable.

El flujo implícito se realiza para los clientes públicos  que no pueden autenticarse. Entonces, la confianza aquí radica en un parámetro llamado redirect_uri . El servidor OAuth debe haber registrado una URL para el cliente, donde se enviará la respuesta. La respuesta solo se enviará allí, por lo que si una aplicación maliciosa engaña a un usuario para que inicie un proceso de delegación, la respuesta siempre volverá a la aplicación real.

Dado que esto es para clientes públicos, no se emitirá un Token de actualización. Eso significa que los nuevos tokens de acceso solo se pueden recibir involucrando al usuario.

Flujo implícito : el flujo completo ocurre en el navegador

3. Flujo de credenciales del cliente

En el flujo de credenciales de cliente , no hay ningún usuario. Es un flujo que es estrictamente para la comunicación de servidor a servidor. Un servidor necesita acceder a una API como él mismo. Por lo tanto, no hay un navegador involucrado y se necesita un cliente privado. Para obtener un token de acceso , el cliente simplemente pasa sus credenciales al servidor OAuth y recibe el token.

No se emite ningún token de actualización en este flujo, ya que el cliente puede recuperar un token de acceso nuevo utilizando sus credenciales de todos modos.

Flujo de credenciales del cliente : el cliente se autentica contra el punto final del token. Ningún usuario involucrado.

4. Flujo de credenciales de contraseña del propietario del recurso

El flujo de credenciales de contraseña del propietario del recurso es bastante simple. El cliente recopila las credenciales del usuario y las pasa junto con sus propias credenciales de cliente. El servidor responde con un token de acceso y, opcionalmente, un token de actualización . Simple verdad? Pero hay un 'pero', y es grande.

ROPC es un flujo que frustra uno de los propósitos de OAuth; que el usuario tiene que ceder sus credenciales a la aplicación y, por lo tanto, no tiene control sobre cómo el cliente la usará. No se recomienda el uso del flujo si puede usar otra cosa. Solo se especifica en la especificación para permitir casos heredados o de migración . Debe usarse con cuidado . Un ejemplo podría ser una aplicación de escritorio empresarial, que no se actualiza fácilmente pero necesita tener acceso a la plataforma API.

No recomendamos su uso, pero si realmente lo necesita: El flujo es solo para clientes privados y el cliente podría obtener un Token de actualización.

ROPC : el cliente envía las credenciales de los usuarios junto con sus propias credenciales.

5. Registro dinámico de clientes

Si bien no es uno de los flujos de la especificación OAuth principal, el registro dinámico de clientes resuelve un caso de uso importante para los clientes móviles . Dado que las aplicaciones móviles se distribuyen a través de las tiendas de aplicaciones, es difícil darles una credencial para identificarse de forma única y, por lo tanto, los clientes móviles suelen etiquetarse como públicos.

El registro de cliente dinámico intenta redimir eso especificando los medios para que un cliente se registre y solicite una credencial única en el momento de la instalación. Funciona al permitir que el cliente envíe un token de registro al servidor OAuth, que genera un conjunto de credenciales y las devuelve al cliente. Estas credenciales se pueden usar en un flujo de código y el cliente ahora puede autenticarse.

El token de registro se puede obtener de varias formas. Ya sea permitiendo que el usuario se autentique en un flujo implícito o utilizando el flujo de credenciales de cliente con un secreto predistribuido.

Fuera del caso móvil, el registro dinámico de clientes puede ser muy útil para las plataformas de administración de API , que necesitan poder crear clientes para el servidor OAuth.

6. Flujo de tokens asistido

El flujo Assisted Token es un borrador que no forma parte de los flujos base, pero vale la pena mencionarlo. Es una especificación hermana de OAuth que intenta facilitar la obtención de tokens para las aplicaciones de una sola página . Para ese tipo de aplicaciones, puede resultar difícil manejar el flujo implícito, ya que depende en gran medida de las redirecciones. En cambio, Assisted Token Flow define un flujo similar a Implícito , que en su lugar usa iframes y postMessage como medio de comunicación.

Lea más aquí: Flujo de token asistido: la respuesta a la integración de OAuth en aplicaciones de una sola página

Gestión de tokens

7. Introspección

La introspección es la forma de preguntar al servidor OAuth si un token es válido. Los tokens de acceso generalmente se transmiten por referencia , lo que significa que no significan nada para nadie más que el servidor OAuth. Los clientes de introspección suelen ser una API o una especie de puerta de enlace de API . La introspección es una simple llamada autenticada , en la que envías un token y la respuesta son los datos que pertenecen al token, como el tiempo de vencimiento, el asunto, etc.

8. Revocación

La revocación es uno de los poderes de OAuth. Sin OAuth, un usuario que entregó sus credenciales a una aplicación no tiene forma de retirar ese consentimiento. La única forma es cambiar la contraseña, lo que podría tener mayores efectos secundarios que no permitir que la aplicación acceda a la cuenta del usuario.

Con OAuth, el usuario puede decidir recuperar el consentimiento en cualquier momento revocando el token. En OAuth, tiene dos opciones para la revocación, puede revocar el token de acceso, lo que podría verse como el final de la sesión actual. Si hay un Token de actualización, seguirá siendo válido. Revocar el token de actualización invalidaría el token de actualización y cualquier token de acceso activo que venga con él.

Es el cliente el que realiza la revocación real con una llamada autenticada. Aunque esté autenticado, los clientes públicos pueden realizar la revocación.

Por qué es importante distinguir los flujos de OAuth

Puede parecer que hay muchos flujos similares en OAuth, pero cada flujo tiene su caso de uso específico. Con estos flujos esenciales, debería poder elegir los flujos que se ajusten a su aplicación y escenario.

Si bien todo esto es generalmente de alto nivel, cada flujo podría justificar su propia pieza completa. Para obtener más información, revise las diversas piezas que hemos realizado anteriormente con respecto a los flujos de OAuth y OAuth . Si está interesado en saber más sobre los conceptos básicos de OAuth y puede estar en Estocolmo el 22 de octubre, únase a nuestro taller en la Cumbre de la Plataforma de APIs nórdicas .

Publicar un comentario

0 Comentarios