Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué es OpenID Connect?

 En un mundo cada vez más conectado por API, el papel de la identidad nunca ha sido más importante. Hay diferentes formas en que los proveedores de API pueden otorgar acceso a datos para aplicaciones en nombre de los usuarios, y una forma que se ha vuelto casi omnipresente es OAuth 2.0. Por ejemplo, cuando se le pide que comparta sus datos con una aplicación móvil que le permite tuitear en el juego su mejor puntuación en Wordscapes, OAuth 2.0 está impulsando la integración que permite que esto suceda.

Sin embargo, OAuth 2.0 tiene sus limitaciones, la más importante es probar el hecho de que el ser humano realmente se autenticó cuando permitió el acceso a sus datos. Esta falla es algo que los desarrolladores de aplicaciones y los proveedores de API pueden tolerar al enviar un tweet. Sin embargo, no es tan bueno si la API envía un pago en nombre del usuario o comparte datos confidenciales como registros de salud o seguros.

Aquí es donde entra OpenID Connect. En esta publicación, volvemos a lo básico y echamos un vistazo a lo que OpenID Connect está diseñado para resolver y cómo lo logra.

¿Qué resuelve OpenID Connect?

Es importante poner OpenID Connect en el contexto correcto al observar lo que vino antes. La especificación principal de OpenID Connect se describe como " una capa de identidad simple sobre el protocolo OAuth 2.0" . Como dijimos en la introducción, permitir que una aplicación acceda a sus datos de forma segura a través de API sin renunciar a sus credenciales es parte de lo que se trata OAuth 2.0. ¿Por qué también se necesita OpenID Connect?

El motivo es que OAuth 2.0 solo proporciona autorización; Se requiere OpenID Connect para demostrar la identidad de la parte solicitante. Considere el ejemplo de Wordscapes. Wordscapes accede a la API de Twitter en su nombre utilizando un token de acceso dedicado a usted; Wordscapes solo sabe que estaba autorizado para acceder a sus datos. No sabe nada sobre el evento de autenticación que tuvo lugar y la versión de Twitter de lo que considera que eres tú. No puede:

  • Dile que definitivamente fuiste tú quien se autenticó.
  • Sepa cómo se autenticó.
  • Obtenga cualquier información útil que pueda ayudarlo a brindarle una mejor experiencia como cliente.

Proporcionar información como esta, incluido el evento de autenticación en sí y quién era el usuario final, es precisamente lo que logra OpenID Connect. Permite que la aplicación, la parte que confía, acceda a pruebas de identidad firmadas criptográficamente. Los beneficios incluyen:

  • Asegura a la aplicación del Cliente que la autenticación realmente se llevó a cabo mediante el uso de un token de identificación , que es un medio de llevar atributos de identidad utilizando un token web JSON firmado (JWS) que se puede verificar mediante criptografía de clave pública. Esto garantiza que la delegación de acceso por parte de un usuario final esté respaldada por una afirmación verificable criptográficamente.
  • También permite que la aplicación Cliente sepa “algo” sobre la identidad del Usuario final, lo cual es esencial para la federación de la identidad del usuario. La federación es útil para las aplicaciones del Cliente, ya que les permite subcontratar muchos aspectos de la identidad del usuario a un proveedor en el que confía sin sacrificar la seguridad y el acceso.
  • Tener alguna prueba de autenticación puede ayudar a los desarrolladores de aplicaciones a crear experiencias de autenticación mucho más fluidas. Pueden (donde sea respaldado por un proveedor de identidad) usar un Token de ID válido existente para probar la identidad del Usuario Final al Servidor de Autorización. En tales escenarios, es posible que el servidor de autorización no solicite al usuario que se autentique, lo que resulta en una experiencia mucho más fluida al usar una aplicación que aprovecha esta función.

El ID Token es la característica definitoria del protocolo central de OpenID Connect. Su función principal es transmitir información sobre la identidad del usuario que fue autenticado. Esto se manifiesta en una serie de reclamaciones codificadas en el token, cuyos ejemplos incluyen:

  • El sujeto: un identificador único que representa al usuario final como lo conoce el proveedor de identidad.
  • El emisor y la audiencia: el proveedor de identidad que emitió el token y la aplicación de cliente para la que estaba destinado.
  • Fecha de emisión y vencimiento.

Esta lista no es exhaustiva y se pueden incluir otras Reclamaciones estándar con un alcance adicional para incluir Reclamaciones personalizadas cuando sea necesario.

Por lo tanto, el token de identificación puede contener metadatos importantes sobre el usuario final. Esto puede proporcionar mayores niveles de garantía de que el usuario final es quien dice ser. También ofrece puntos de referencia para la aplicación Cliente cuando incorporan uno de los flujos proporcionados por el proveedor de identidad.

Flujos

Los flujos que se ofrecen en OpenID Connect son la forma en que una aplicación Cliente interactúa con el proveedor de identidad para garantizar que el Usuario final esté autenticado y la aplicación Cliente esté autorizada para actuar en nombre del Usuario final. Los flujos, en términos generales, reflejan lo que se denominan concesiones de autorización en el RFC de OAuth 2.0 subyacente y son:

  • Código de Autorización.
  • Implícito.
  • Híbrido.

Un desarrollador de aplicaciones incorporará un flujo determinado cuando cree su software, utilizando el response_typeparámetro para indicar qué flujo se requiere. Las posibles combinaciones se muestran en el estándar y en la siguiente tabla:

VALOR DEL TIPO DE RESPUESTAFLUIR
codeCódigo de Autorización
id_tokenImplícito
id_token tokenImplícito
code id_tokenHíbrido
code tokenHíbrido
code id_token tokenHíbrido

Cada flujo tiene sus pros y sus contras, que es importante comprender (especialmente cuando un proveedor ofrece más de uno).

Tenga en cuenta que hay otras características de OpenID Connect Core, como el parámetro de solicitud como JWT y la implementación muy poderosa de sugerencias de inicio de sesión que no cubriremos en esta publicación, pero que abordaremos en artículos futuros.

Código de Autorización

No hay premios por adivinar que el flujo del código de autorización se asigna en gran medida a la concesión del código de autorización de OAuth 2.0, donde se redirige al usuario final para que se autentique. Dadas sus similitudes con OAuth 2.0, el código de autorización representa la ruta más sencilla para actualizar a OpenID Connect. El flujo sigue siendo en gran medida consistente con el protocolo subyacente:

  • La aplicación Cliente envía al Usuario final (su cliente) al Servidor de autorización del proveedor de identidad, estableciendo el response_typeparámetro en code.
  • El usuario final se autentica y autoriza el acceso a la aplicación del cliente.
  • El servidor de autorización proporciona un código de autorización como prueba de autorización .
  • La aplicación Cliente cobra el Código de autorización de un token de acceso que les permite llamar a una o más API en nombre del Usuario final.

Por supuesto, existen varias diferencias entre OAuth y OpenID Connect en este contexto. Sin embargo, la diferencia más importante es que la aplicación del cliente obtiene un token de identificación cuando visita el punto final del token. Esto puede parecer contrario a la intuición dado que response_typeno contiene el id_tokenvalor, pero la razón de esto será más obvia a medida que analicemos los otros flujos.

Implícito

Al igual que el flujo de código de autorización, implícita superpone la concesión de autorización implícita de OAuth 2.0, con los mismos casos de uso y consideraciones de seguridad, a saber:

  • El flujo está diseñado para su uso en el navegador.
  • La aplicación del cliente no está autenticada y depende de que el usuario final se autentique correctamente.
  • Todos los tokens se devuelven desde el punto final de autorización, y el punto final del token no se utiliza.
  • El token de identificación y el token de acceso están expuestos al navegador, lo que los hace más susceptibles al robo a través de ataques de tipo man-in-the-browser.

El flujo implícito tiene su lugar y aún ofrece los beneficios de la prueba de autenticación. El flujo implícito puede tener aplicaciones prácticas dentro de las implementaciones de "jardín amurallado", como dentro de la infraestructura corporativa con un conjunto limitado de credenciales internas. Sin embargo, incluso aquí, se debe considerar seriamente antes de implementarlo.

Híbrido

El flujo final de OpenID Connect es el flujo híbrido. El flujo híbrido es una combinación de código de autorización y flujo implícito. Algunos tokens son devueltos por el punto final de autorización, mientras que otros son devueltos por el punto final del token.

Sin embargo, la devolución de tokens en el punto final de autorización no es solo por diversión. Está pensado como una forma de agregar protección adicional a la aplicación del Cliente donde sea necesario, especialmente para proteger el tramo del viaje desde el punto final de autorización hasta el punto final del token contra ataques.

A modo de ejemplo, si una aplicación cliente solicitudes response_typede code id_token(la definición subyacente se pueden encontrar aquí ) que está a la espera de dos atributos específicos para ser devuelto a la Autorización Punto final:

  • Un código de autorización: al igual que con el flujo del código de autorización, la aplicación del cliente puede cobrarlo en el punto final del token por un token de acceso.
  • Un token de identificación: el token de identificación, en este caso, contiene el c_hashreclamo, que es un hash construido específicamente del código de autorización.

Debido a que es un JWS, el Token de ID proporciona los medios para proteger el Código de autorización contra alteraciones , brindando una oportunidad a la aplicación del Cliente para garantizar que su valor sea válido. La aplicación del cliente también recibirá un token de identificación del token endpoint y puede verificar que los reclamos devueltos en ambos extremos coincidan. El flujo híbrido, ya sea que se superponga al Código de autorización o al flujo implícito, puede agregar beneficios significativos para la aplicación del Cliente y su confianza en el evento de autenticación.

Pensamientos finales

El beneficio principal del estándar OpenID Connect es que proporciona una prueba de autenticación a las aplicaciones del Cliente. Sin embargo, es solo una parte del rompecabezas general de OpenID. La Fundación OpenID orquesta la creación de muchas normas, algunas una mejora en el núcleo, otros diseñados para industrias específicas y casos de uso. Ejemplos incluyen:

  • Discovery , un mecanismo para que los Clientes ingieran los metadatos de un determinado proveedor de identidad para acceder a sus servicios de forma dinámica.
  • Registro de cliente dinámico , que proporciona un medio para que una aplicación de software se registre automáticamente en un proveedor de identidad determinado.
  • Estándares API de grado financiero , un conjunto de estándares sobre los que construir API de servicios financieros.
  • Health Relationship Trust (HEART) , un perfil que permite a los pacientes delegar el acceso a sus datos clínicos.

Todos estos estándares adicionales se basan en OpenID Connect en su esencia. Esto, y el número creciente de proveedores de identidad importantes que admiten OpenID Connect (más recientemente Apple ), indican que el protocolo se está convirtiendo en un bloque de construcción fundamental y cada vez más importante de la economía API.

Publicar un comentario

0 Comentarios