Tipos de aplicaciones que se pueden usar en Active Directory B2C

Azure Active Directory B2C (Azure AD B2C) admite la autenticación para varias arquitecturas de aplicaciones modernas. Todos ellos se basan en los protocolos estándar de la industria OAuth 2.0 u OpenID Connect. En este artículo se describen los tipos de aplicaciones que puede crear, independientemente del lenguaje o la plataforma que prefiera. También le ayuda a comprender los escenarios de alto nivel antes de empezar a crear aplicaciones.

Todas las aplicaciones que usan Azure AD B2C deben estar registradas en el inquilino de Azure AD B2C mediante Azure Portal. El proceso de registro de la aplicación recopila y asigna valores, tales como:

• Un ID de aplicación que identifica de forma única la aplicación.
• Una URL de respuesta que se puede utilizar para redirigir las respuestas a su aplicación.

Cada solicitud que se envía a Azure AD B2C especifica un flujo de usuario (una directiva integrada) o una directiva personalizada que controla el comportamiento de Azure AD B2C. Ambos tipos de políticas le permiten crear un conjunto altamente personalizable de experiencias de usuario.

La interacción de cada aplicación sigue un patrón similar de alto nivel:

1. La aplicación dirige al usuario al punto de conexión v2.0 para ejecutar una directiva.
2. El usuario completa la política de acuerdo con la definición de la política.
3. La aplicación recibe un token de seguridad del punto de conexión v2.0.
4. La aplicación utiliza el token de seguridad para acceder a información protegida o a un recurso protegido.
5. El servidor de recursos valida el token de seguridad para comprobar que se puede conceder el acceso.
6. La aplicación actualiza periódicamente el token de seguridad.

Estos pasos pueden diferir ligeramente en función del tipo de aplicación que esté creando.

Aplicaciones web

En el caso de las aplicaciones web (incluidas .NET, PHP, Java, Ruby, Python y Node.js) hospedadas en un servidor web y a las que se accede a través de un explorador, Azure AD B2C admite OpenID Connect para todas las experiencias de usuario. En la implementación de Azure AD B2C de OpenID Connect, la aplicación web inicia las experiencias de usuario mediante la emisión de solicitudes de autenticación a Microsoft Entra ID. El resultado de la solicitud es un elemento id_token. Este token de seguridad representa la identidad del usuario. También proporciona información sobre el usuario en forma de reclamaciones:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Obtenga más información sobre los tipos de tokens y reclamaciones que están disponibles para una aplicación en la referencia de tokens de Azure AD B2C.

En una aplicación web, cada ejecución de una política realiza estos pasos de alto nivel:

1. El usuario navega a la aplicación web.
2. La aplicación web redirige al usuario a Azure AD B2C indicando la directiva que se va a ejecutar.
3. El usuario complete la directiva.
4. Azure AD B2C devuelve un id_token al explorador.
5. El id_token se publica en el URI de redirección.
6. El id_token se valida y se establece una cookie de sesión.
7. Se devuelve una página segura al usuario.

La validación de la id_token mediante una clave de firma pública que se recibe de Microsoft Entra ID es suficiente para comprobar la identidad del usuario. Este proceso también establece una cookie de sesión que se puede utilizar para identificar al usuario en solicitudes de página posteriores.

Para ver este escenario en acción, pruebe uno de los ejemplos de código de inicio de sesión de aplicaciones web en nuestra sección Introducción.

Además de facilitar un inicio de sesión sencillo, es posible que una aplicación web también necesite acceder a un servicio web back-end. En este caso, la aplicación web puede realizar un flujo de OpenID Connect ligeramente diferente y adquirir tokens mediante códigos de autorización y tokens de actualización. Este escenario se muestra en la siguiente sección API web.

Aplicación de página única

Muchas aplicaciones web modernas se crean como aplicaciones de página única del lado cliente ("SPAs"). Los desarrolladores los escriben mediante JavaScript o un marco SPA como Angular, Vue o React. Estas aplicaciones se ejecutan en un explorador web y tienen características de autenticación diferentes a las de las aplicaciones web del lado servidor tradicionales.

Azure AD B2C proporciona dos opciones para permitir que las aplicaciones de página única inicien sesión de usuarios y obtengan tokens para acceder a servicios back-end o API web:

Flujo de código de autorización (con PKCE)

El flujo de código de autorización de OAuth 2.0 (con PKCE) permite a la aplicación intercambiar un código de autorización para los tokens de identificador para representar el usuario autenticado y los tokens de acceso necesarios para llamar a las API protegidas. Además, devuelve tokens de actualización que proporcionan acceso a largo plazo a los recursos en nombre de los usuarios sin necesidad de interacción con esos usuarios.

Recomendamos este enfoque. Tener tokens de actualización de duración limitada ayuda a la aplicación a adaptarse a las limitaciones modernas de privacidad de cookies del explorador, como SAFARI ITP.

Para aprovechar este flujo, la aplicación puede usar una biblioteca de autenticación que lo admita, como MSAL.js 2.x.

Flujo de concesión implícita

Algunas bibliotecas, como MSAL.js 1.x, solo admiten el flujo de concesión implícito o la aplicación se implementa para usar el flujo implícito. En estos casos, Azure AD B2C admite el flujo implícito de OAuth 2.0. El flujo de concesión implícita permite a la aplicación obtener tokens de identificador y de acceso. A diferencia del flujo de código de autorización, el flujo de concesión implícito no devuelve un token de actualización.

Este flujo de autenticación no incluye escenarios de aplicación que usan marcos javaScript multiplataforma, como Electron y React-Native. Estos escenarios requieren más funcionalidades para la interacción con las plataformas nativas.

APIs web

Puede usar Azure AD B2C para proteger servicios web, como la API web RESTful de la aplicación. Las API web pueden usar OAuth 2.0 para proteger sus datos, mediante la autenticación de las solicitudes HTTP entrantes mediante tokens. El llamador de una API web anexa un token en el encabezado de autorización de una solicitud HTTP:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

A continuación, la API web puede usar el token para comprobar la identidad del autor de la llamada y extraer información sobre el autor de las afirmaciones codificadas en el token. Aprenda más sobre todos los tipos de tokens y notificaciones disponibles para una aplicación en la referencia de token de Azure AD B2C.

Una API web puede recibir tokens de muchos tipos de clientes, incluidas aplicaciones web, aplicaciones de escritorio y móviles, aplicaciones de una sola página, daemons del lado del servidor y otras API web. A continuación, se muestra un ejemplo del flujo completo de una aplicación web que llama a una API web:

1. La aplicación web ejecuta una directiva y el usuario completa la experiencia de usuario.
2. Azure AD B2C devuelve un (OpenID Connect) id_token y un código de autorización al explorador.
3. El navegador envía el id_token y el código de autorización al URI de redireccionamiento.
4. El servidor web valida id_token y establece una cookie de sesión.
5. El servidor web solicita a Azure AD B2C un access_token proporcionando el código de autorización, el ID de cliente de la aplicación y las credenciales del cliente.
6. El access_token y refresh_token se devuelven al servidor web.
7. Se invoca a la API web con el access_token en una cabecera de autorización.
8. La API web valida el token.
9. Los datos seguros se devuelven a la aplicación web.

Para obtener más información sobre los códigos de autorización, los tokens de actualización y los pasos para obtener tokens, lea sobre el protocolo OAuth 2.0.

Para obtener información sobre cómo proteger una API web mediante Azure AD B2C, consulte los tutoriales de API web en nuestra sección Introducción.

Aplicaciones móviles y aplicaciones nativas

Las aplicaciones que se instalan en dispositivos, como las aplicaciones móviles y de escritorio, a menudo necesitan acceder a servicios de back-end o API web en nombre de los usuarios. Puede agregar experiencias de administración de identidades personalizadas a las aplicaciones nativas y llamar de forma segura a los servicios back-end mediante Azure AD B2C y el flujo de código de autorización de OAuth 2.0.

En este flujo, la aplicación ejecuta directivas y recibe un authorization_code de Microsoft Entra ID después de que el usuario complete la directiva. El authorization_code representa el permiso de la aplicación para llamar a los servicios de back-end en nombre del usuario que ha iniciado sesión actualmente. A continuación, la aplicación puede intercambiar el authorization_code en segundo plano por un access_token y un refresh_token. La aplicación puede usar el access_token para autenticarse en una API web de back-end en solicitudes HTTP. También puede usar el refresh_token para obtener uno nuevo access_token cuando caduca uno anterior.

Demonios/aplicaciones del lado del servidor

Las aplicaciones que contienen procesos de larga duración o que funcionan sin la presencia de un usuario también necesitan una forma de acceder a recursos seguros, como las API web. Estas aplicaciones pueden autenticarse y obtener tokens mediante sus identidades (en lugar de la identidad delegada de un usuario) y mediante el flujo de credenciales de cliente de OAuth 2.0. El flujo de credenciales de cliente no es igual al flujo en nombre de y este no se debe usar para la autenticación de servidor a servidor.

En el caso de Azure AD B2C, el flujo de credenciales de cliente de OAuth 2.0 se encuentra actualmente en versión preliminar pública. Sin embargo, puede configurar el flujo de credenciales de cliente mediante el identificador de Microsoft Entra y el punto de conexión de la plataforma /token de identidad de Microsoft (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) para una aplicación de Microsoft Graph o su propia aplicación. Para obtener más información, consulte el artículo de referencia sobre el token de Microsoft Entra.

Tipos de aplicaciones no admitidos

Cadenas de la API web (flujo en nombre de)

Muchas arquitecturas incluyen una API web que necesita llamar a otra API web de nivel inferior, donde ambas están protegidas por Azure AD B2C. Este escenario es común en clientes nativos que tienen un back-end de API web y llaman a un servicio en línea de Microsoft, como Microsoft Graph API.

Este escenario de API web encadenadas puede admitirse mediante la concesión de credenciales de portador JWT de OAuth 2.0, también conocido como flujo "en nombre de". Sin embargo, el flujo "en nombre de" no está implementado actualmente en Azure AD B2C.

Pasos siguientes

Obtenga más información sobre las directivas integradas proporcionadas por flujos de usuario en Azure Active Directory B2C.