Saltar al contenido

Autenticación moderna para la aplicación

01/10/2020

Autenticación moderna para la aplicación😁😁😁👍😊👌Hay muchas opciones para proteger las identidades en la aplicación. Al seleccionar la tecnología adecuada COMPARTELO Y DA ME GUSTA👌👌👌👌👌👌👍👍👍👍👍👍 DEJA TU EMAIL😜😜😜😜

Pilares del Marco de arquitectura de Azure
16 / 100

Autenticación moderna para la aplicación

Hay muchas opciones para proteger las identidades en la aplicación.

Al seleccionar la tecnología adecuada para la aplicación, podrá garantizar su seguridad

y, a la vez, ofrecer una gran experiencia a los usuarios.

En la empresa de transporte, los conductores tienen identidades en Microsoft 365.

Quiere saber cómo puede usar esas identidades para autenticarlas en la aplicación de

programación. Quiere proporcionar un acceso seguro a la aplicación sin necesidad de

que los conductores administren cuentas de usuario y credenciales adicionales.

Echemos un vistazo a los estándares y servicios que puede usar para la autenticación.

  • ¿Qué es Azure Active Directory?

Azure Active Directory (Azure AD) es un servicio de administración de acceso y de

identidades basado en la nube de Microsoft. Simplifica la autenticación para los desarrolladores,

ya que proporciona identidad como servicio. Admite los protocolos estándar del sector como

Oath 2.0 y Open Id Connect.

Azure AD permite a los usuarios iniciar

para proteger las identidades, como Identity Protection y autenticación multi factor.

Determinados servicios de Microsoft, como Azure y Microsoft 365, usan Azure AD para almacenar

y administrar usuarios. Por ejemplo, cada vez que Microsoft 365 necesita verificar un usuario,

Azure AD realiza toda la tarea de administración de identidades y acceso.

Autenticación en Azure Active Directory

Los usuarios se autentican en dos fases:

  1. El proveedor de identidades comprueba la identidad de los usuarios que existen en el
  2. directorio. Tras una autenticación correcta, se emiten tokens que contienen información
  3. relacionada con la autenticación correcta.
  4. El usuario pasa esos tokens

    a la aplicación. La aplicación debe validar el token de seguridad del

  5. usuario para garantizar que la autenticación se haya realizado correctamente.

Veamos un escenario básico en el que es necesario identificarse: un usuario de un explorador

web debe autenticarse en una aplicación web. Tenga en cuenta el diagrama siguiente para este escenario:

Captura de pantalla que muestra un escenario básico en el que es necesario identificarse

  1. El usuario solicita un recurso protegido, en este caso, una aplicación web.
  2. La aplicación web redirige la solicitud al proveedor de identidades, y este solicita y verifica las
  3. credenciales de autenticación del usuario.
  4. Si el usuario envía las credenciales correctas, el proveedor devuelve un token de seguridad al
  5. usuario y lo redirige al recurso que ha solicitado al inicio.
  6. El usuario envía el token de seguridad a la aplicación web.
  7. La aplicación web utiliza el token para comprobar que el proveedor de identidades haya realizado
  8. la autenticación.

Después de este proceso de autenticación, en el que se identifica al usuario, la aplicación web debe autorizar

el acceso del usuario a los recursos. La autorización es el proceso por el que la aplicación web comprueba si

el usuario tiene permiso para acceder al recurso solicitado.

Este flujo de comunicación se basa en los protocolos estándar del sector de Oath 2.0 y Open Id Connect.

Oath 2.0

Oath 2.0 es el protocolo estándar del sector para la autorización. Proporciona flujos

de autorización específicos para aplicaciones web, móviles y de escritorio. Esta especificación

se diseñó principalmente para permitir que los usuarios autorizaran a una aplicación a tener

acceso a los datos de otra aplicación.

Imagine que tiene una aplicación que almacena información de contacto. Quiere que los usuarios

con cuentas de LinkedIn puedan importar su información de contacto de LinkedIn en la aplicación

. Con Oath, puede habilitar esta comunicación de servidor a servidor. Los usuarios pueden permitir

que la aplicación tenga acceso a la información de contacto, sin necesidad de compartir

contraseñas entre aplicaciones.

Oath funciona bien para la autorización de comunicaciones de servidor a servidor, pero no

incluye estándares ni especificaciones para la autenticación. A medida que las aplicaciones

aumentaron los niveles de uso compartido de los datos y la información de las cuentas entre

ellas, la habilitación de un marco estándar para el inicio de sesión único se hizo evidente.

Esto condujo al desarrollo de Open Id Connect.

  1. Open Id Connect

Open Id Connect es una capa de autenticación que se basa en Oath 2.0. Incluye los

métodos de verificación de identidad que no se encuentran en Oath 2.0. Open Id Connect

proporciona un token de acceso y un token de identificador, que se pueden enviar a una

aplicación para demostrar su identidad.

El token de identificador es un objeto

el usuario autenticado. El proveedor de identidades firma el token para que las aplicaciones

puedan comprobar la autenticación mediante la clave pública del proveedor.

JSON Web Token es un estándar internacional abierto que define el modo en el que las aplicaciones

pueden intercambiar datos de manera segura en forma de mensajes firmados digitalmente.

El contenido de cada token no está cifrado, pero el mensaje está firmado con la clave privada

del proveedor de identidades. Al comprobar la firma con la clave pública correspondiente,

las aplicaciones pueden demostrar que el token lo emite el proveedor de identidades y no se ha alterado.

Autenticación de OpenID

En este diagrama se muestra cómo la aplicación cliente, el servidor de aplicaciones y el

proveedor de identidades se comunican en una solicitud de autenticación de Open Id Connect.

El cliente puede ser una aplicación móvil o una aplicación de escritorio. En este caso, es un

explorador web. El servidor de aplicaciones suele ser un servidor web que hospeda páginas web o una

API web. El proveedor de identidades, en el centro, es Azure AD.

Cuando el explorador web navega a la aplicación web, el servidor web necesita autenticar al usuario.

En este caso, el servidor redirige el explorador a Azure AD y proporciona su propio

id. de cliente, que se ha registrado en Azure AD. Cuando el usuario se ha autenticado

correctamente en Azure AD, el proveedor redirige el explorador al URI en el servidor web.

Al implementar Open Id Connect, debe obtener un id. de cliente para la aplicación mediante

la creación de un registro de aplicación en Azure AD. Luego, copie el id. de cliente en los archivos

de configuración de la aplicación. En el registro de aplicación también se incluirá el URI de la

aplicación web para que Azure AD pueda redirigir al cliente correctamente.