Post Top Ad

Your Ad Spot

jueves, 20 de agosto de 2020

3 potentes extensiones para aprovechar al máximo OAuth 2.0

OAuth 2.0 es el estándar de oro para proteger el acceso a las API. Con cuatro flujos de autorización bien definidos o tipos de concesión incluidos en el RFC de OAuth 2.0 original , la funcionalidad de OAuth es más que adecuada para una amplia gama de casos de uso y dispositivos .
Sin embargo, como explica Michał Trojanowski en su charla de la Cumbre de la Plataforma 2019, un panorama tecnológico cambiante ha creado la necesidad de nuevas funcionalidades de autorización. En esta publicación, veremos tres poderosas adiciones a la especificación original de OAuth 2.0, incluido el tipo de concesión de código de dispositivo , el tipo de concesión de intercambio de token y la extensión de clave de prueba para intercambio de código , como lo explicó el propio Michał.
Vea a Michał Trojanowski describir cómo extender OAuth:

1. Tipo de concesión de código de dispositivo

En el tipo de concesión del Código de autorización de OAuth 2.0 original , el cliente inicializa el flujo de autorización a través de un agente de usuario, como un navegador. Luego, se envía un código de autorización al cliente mediante un URI de redireccionamiento en el navegador, que el cliente puede intercambiar por un token de acceso.
Sin embargo, Michał explica que si el dispositivo no tiene acceso a un navegador (como es el caso de muchos dispositivos de IoT) o tiene capacidades de entrada limitadas (como un televisor), este flujo es menos que ideal.
Ingrese el tipo de concesión del Código de dispositivo . Este flujo de autorización propuesto está diseñado especialmente para dispositivos sin navegador o con restricciones de entrada . Implica el uso de dos dispositivos separados: uno que solicita autorización y otro en el que se otorga la autorización.
Como ejemplo de esto, Michał describe a un usuario que inicia sesión en una aplicación de YouTube en un televisor a través de su teléfono móvil. El flujo es relativamente sencillo: el cliente (en este caso, el televisor) inicia el flujo de autorización enviando una solicitud POST al servidor de autorización:
POST /device_authorization
Content-Type: application/w-xxx-form-urlencoded
client_id=459691054427
En la respuesta, el servidor devuelve una autorización device_codeuser_codeverification_uriEl cliente presenta el código de usuario y la URI de verificación al usuario, quien debe buscar la URI e ingresar el código en su teléfono móvil.
Mientras tanto, el cliente comienza a sondear el servidor de autorización con el código del dispositivo, preguntando si el usuario ya ha autorizado la aplicación. Al principio, el servidor responderá con un error 400, indicando que la autorización aún está pendiente. Sin embargo, eventualmente, una vez que el usuario autorice en su teléfono móvil, ¡el servidor responderá con un token de acceso!

2. Tipo de concesión de intercambio de tokens

El tipo de concesión de Token Exchange es un protocolo preliminar que permite a un usuario actuar en nombre de otro. En algunos casos, puede ser una cuenta de administrador que actúa en nombre de un usuario habitual; en otros casos, pueden ser subcuentas que actúan en nombre de una cuenta principal.
Este tipo de concesión agrega al menos dos nuevos parámetros: subject_token- el token del usuario en cuestión - y subject_token_typeSi bien estos parámetros son suficientes para hacerse pasar por un usuario (lo que significa que el servidor de recursos no sabrá que un usuario actúa en nombre de otro), el tipo de concesión también admite la delegación explícita de tokens, que además requiere los parámetros actor_tokenactor_token_type.
Michał agrega que la especificación Token Exchange agrega cuatro nuevos reclamos a JSON Web Tokens (JWT), que ayudan a identificar a los usuarios que están intercambiando tokens:
  • act: Este reclamo contiene una lista de reclamos, como subiss, que identifican qué usuario inició el intercambio de tokens.
  • scope: Esta reclamación contiene una lista de ámbitos que limita lo que el usuario puede hacer en nombre del otro usuario.
  • client_id: Esta reclamación contiene el ID del cliente que inició la solicitud de intercambio de tokens.
  • may_act: Este reclamo contiene una lista de reclamos que identifica qué usuarios pueden iniciar una solicitud de intercambio de tokens.

3. Clave de prueba para la extensión de intercambio de código (PKCE)

Proof Key for Code Exchange (PKCE) es una extensión de seguridad para el tipo de concesión de código de autorización OAuth 2.0 original PKCE, que se pronuncia "pixy", es para clientes con toda su base de código accesible para los usuarios, como aplicaciones de página única (SPA) y muchas aplicaciones móviles o de escritorio, donde los tokens de acceso podrían ser interceptados. Michał observa que, originalmente, el tipo de subvención implícita se utilizó para estas situaciones; sin embargo, se desaconseja su uso aquí por motivos de seguridad.
La extensión Proof Key for Code Exchange es relativamente sencilla. Agrega dos piezas de información a la solicitud que inicia el flujo de autorización: un verificador de código transformado y el método utilizado para transformarlo. Más tarde, cuando el cliente va a intercambiar el código de autorización por un token de acceso, la extensión agrega el verificador del código original a la solicitud. Antes de emitir un token de acceso, el servidor de autorización utiliza el método de transformación para verificar si el verificador de código original corresponde al verificador de código transformado, en otras palabras, para asegurarse de que el mismo cliente está solicitando un token de acceso.

Pensamientos finales

El OAuth 2.0 original es un estándar poderoso, pero nuevos flujos y extensiones como estos continúan evolucionando la seguridad y conveniencia de la autorización. Las tres extensiones discutidas en este artículo permiten la autorización en dispositivos restringidos, una delegación de token transparente de un usuario a otro y una autorización segura en clientes públicos.
Como siempre, si desea obtener más información sobre estas extensiones, Michał sugiere sumergirse en las RFC oficiales:

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

outbrain

Páginas