Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Importante
A partir del 1 de mayo de 2025, Azure AD B2C ya no estará disponible para la compra por parte de nuevos clientes. Obtenga más información en nuestras preguntas más frecuentes.
Muchas aplicaciones modernas tienen un front-end de aplicación de página única (SPA) que se escribe principalmente en JavaScript. A menudo, la aplicación se escribe mediante un marco como React, Angular o Vue.js. Los SPA y otras aplicaciones de JavaScript que se ejecutan principalmente en un explorador tienen algunos desafíos adicionales para la autenticación:
Las características de seguridad de estas aplicaciones son diferentes de las aplicaciones web tradicionales basadas en servidor.
Muchos servidores de autorización y proveedores de identidades no admiten solicitudes de uso compartido de recursos entre orígenes (CORS).
Las redirecciones del explorador de página completa fuera de la aplicación pueden ser invasivas para la experiencia del usuario.
Advertencia
Microsoft recomienda que no use el flujo de concesión implícita. La forma recomendada de admitir SPAs es el flujo de código de autorización de OAuth 2.0 (con PKCE). Determinadas configuraciones de este flujo requieren un alto grado de confianza en la aplicación y conllevan riesgos que no están presentes en otros flujos. Solo debe usar este flujo cuando no se puedan usar otros más seguros. Para obtener más información, consulte los problemas de seguridad del flujo de concesión implícita.
Algunos marcos, como MSAL.js 1.x, solo admiten el flujo de concesión implícito. En estos casos, Azure Active Directory B2C (Azure AD B2C) admite el flujo de concesión implícita de autorización de OAuth 2.0. El flujo se describe en la sección 4.2 de la especificación de OAuth 2.0. En el flujo implícito, la aplicación recibe tokens directamente desde el punto de conexión de autorización de Azure AD B2C, sin ningún intercambio de servidor a servidor. Toda la lógica de autenticación y el control de sesiones se realizan completamente en el cliente de JavaScript con un redireccionamiento de página o un cuadro emergente.
Azure AD B2C amplía el flujo implícito de OAuth 2.0 estándar a más que la autenticación y autorización simples. Azure AD B2C presenta el parámetro de directiva. Con el parámetro de directiva, puede usar OAuth 2.0 para agregar directivas a la aplicación, como los flujos de usuario de registro, inicio de sesión y administración de perfiles. En el ejemplo de solicitudes HTTP de este artículo, usamos {tenant}.onmicrosoft.com para la ilustración. Reemplace {tenant} por el nombre del inquilino si tiene uno. Además, debe haber creado un flujo de usuario.
Usamos la ilustración siguiente para ilustrar el flujo de inicio de sesión implícito. Cada paso se describe en detalle más adelante en el artículo.
Envío de solicitudes de autenticación
Cuando la aplicación web necesita autenticar al usuario y ejecutar un flujo de usuario, dirige al usuario al punto de conexión de /authorize Azure AD B2C. El usuario realiza una acción en función del flujo de usuario.
En esta solicitud, el cliente indica los permisos que necesita adquirir del usuario en el scope parámetro y el flujo de usuario que se va a ejecutar. Para obtener una sensación de cómo funciona la solicitud, intente pegar la solicitud en un explorador y ejecutarla. Reemplazar:
{tenant}por el nombre de su inquilino de Azure AD B2C.00001111-aaaa-2222-bbbb-3333cccc4444por el id. de la aplicación que registró en su inquilino.{policy}por el nombre de una directiva que haya creado en el inquilino, por ejemplob2c_1_sign_in.
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&response_mode=fragment
&scope=openid%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
Los parámetros de la solicitud HTTP GET se explican en la tabla siguiente.
| Parámetro | Obligatorio | Descripción |
|---|---|---|
| {inquilino} | Sí | Nombre del inquilino de Azure AD B2C |
| {política} | Sí | Nombre del flujo de usuario que desea ejecutar. Especifique el nombre de un flujo de usuario que ha creado en el inquilino de Azure AD B2C. Por ejemplo: b2c_1_sign_in, b2c_1_sign_up, o b2c_1_edit_profile. |
| ID de cliente | Sí | Identificador de aplicación asignado a la aplicación en Azure Portal . |
| tipo_de_respuesta | Sí | Debe incluirse id_token para el inicio de sesión de OpenID Connect. También puede incluir el tipo tokende respuesta . Si usa token, la aplicación puede recibir inmediatamente un token de acceso del punto de conexión de autorización, sin realizar una segunda solicitud al punto de conexión de autorización. Si usa el token tipo de respuesta, el scope parámetro debe contener un ámbito que indique a qué recurso se va a emitir el token. |
| URI de redirección | No | El URI de redireccionamiento de la aplicación, adonde la aplicación puede enviar y recibir las respuestas de autenticación. Debe coincidir exactamente con uno de los URI de redireccionamiento que agregó a una aplicación registrada en el portal, excepto que debe estar codificado como URL. |
| modo_de_respuesta | No | Especifica el método que se va a usar para devolver el token resultante a la aplicación. Para los flujos implícitos, use fragment. |
| alcance | Sí | Lista de ámbitos separados por espacios. Un único valor de ámbito indica al identificador de Entra de Microsoft ambos de los permisos que se solicitan. El ámbito openid indica un permiso para iniciar sesión con el usuario y obtener los datos del usuario en forma de tokens de identificador. El offline_access ámbito es opcional para las aplicaciones web. Indica que la aplicación necesita un token de actualización para el acceso de larga duración a los recursos. |
| estado | No | Valor incluido en la solicitud que también se devuelve en la respuesta del token. Puede ser cualquier cadena de contenido que desee utilizar. Normalmente, se usa un valor único generado aleatoriamente para evitar ataques de falsificación de solicitudes entre sitios. El estado también se usa para codificar información sobre el estado del usuario en la aplicación antes de que se produjera la solicitud de autenticación, por ejemplo, la página en la que estaba el usuario o el flujo de usuario que se estaba ejecutando. |
| valor de seguridad | Sí | Un valor incluido en la solicitud (generada por la aplicación), que se incluye en el token de identificador resultante como una notificación. La aplicación puede comprobar este valor para mitigar los ataques de reutilización de token. Normalmente, el valor es una cadena aleatoria y única que se puede usar para identificar el origen de la solicitud. |
| inmediato | No | Tipo de interacción del usuario necesaria. Actualmente, el único valor válido es login. Este parámetro obliga al usuario a escribir sus credenciales en esa solicitud. El inicio de sesión único no surte efecto. |
Esta es la parte interactiva del flujo. Se pide al usuario que complete el flujo de trabajo de la política. Es posible que el usuario tenga que escribir su nombre de usuario y contraseña, iniciar sesión con una identidad social, registrarse para obtener una cuenta local o cualquier otro número de pasos. Las acciones de usuario dependen de cómo se define el flujo de usuario.
Una vez que el usuario complete el flujo de usuario, Azure AD B2C devuelve una respuesta a la aplicación a través de redirect_uri. Usa el método especificado en el response_mode parámetro . La respuesta es exactamente la misma para cada uno de los escenarios de acción del usuario, independientemente del flujo de usuario que se ejecutó.
Respuesta exitosa
Una respuesta correcta que usa response_mode=fragment y response_type=id_token+token tiene el aspecto siguiente, con saltos de línea para legibilidad:
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
| Parámetro | Descripción |
|---|---|
| token de acceso | Token de acceso que la aplicación solicitó desde Azure AD B2C. |
| tipo_de_token | Valor del tipo de token. El único tipo que admite Azure AD B2C es Bearer. |
| expira_en | El período de tiempo que el token de acceso es válido (en segundos). |
| alcance | Ámbitos para los que el token es válido. También puede usar ámbitos para almacenar en caché los tokens para su posterior uso. |
| token de identificación | El token de identificador que la aplicación solicitó. Puede usar el token de identificador para comprobar la identidad del usuario y comenzar una sesión con el usuario. Para más información sobre los tokens de identificador y su contenido, consulte la referencia de tokens de Azure AD B2C. |
| estado | Si un parámetro state está incluido en la solicitud, debería aparecer el mismo valor en la respuesta. La aplicación debe comprobar que los state valores de la solicitud y la respuesta son idénticos. |
Respuesta de error
Las respuestas de error también se pueden enviar al URI de redirección para que la aplicación pueda controlarlas correctamente:
GET https://aadb2cplayground.azurewebsites.net/#
error=access_denied
&error_description=the+user+canceled+the+authentication
&state=arbitrary_data_you_can_receive_in_the_response
| Parámetro | Descripción |
|---|---|
| error | Código usado para clasificar los tipos de errores que se producen. |
| descripción_del_error | Un mensaje de error específico que puede ayudarlo a identificar la causa raíz de un error de autenticación. |
| estado | Si un parámetro state está incluido en la solicitud, debería aparecer el mismo valor en la respuesta. La aplicación debe comprobar que los state valores de la solicitud y la respuesta son idénticos. |
Validar el token de identificador
La recepción de un token de identificador no es suficiente para autenticar al usuario. Valide la firma del token de identificación y verifique las declaraciones del token según los requisitos de la aplicación. Azure AD B2C usa tokens web JSON (JWT) y criptografía de clave pública para firmar tokens y comprobar que son válidos.
Muchas bibliotecas de código abierto están disponibles para validar los JWT, en función del lenguaje que prefiera usar. Considere la posibilidad de explorar las bibliotecas de código abierto disponibles en lugar de implementar su propia lógica de validación. Puede usar la información de este artículo para ayudarle a aprender a usar correctamente esas bibliotecas.
Azure AD B2C tiene un punto de conexión de metadatos de OpenID Connect. Una aplicación puede usar el punto de conexión para capturar información sobre Azure AD B2C en tiempo de ejecución. Esta información incluye puntos de conexión, contenido de tokens y claves de firma de tokens. Hay un documento de metadatos JSON para cada flujo de usuario en el inquilino de Azure AD B2C. Por ejemplo, el documento de metadatos de un flujo de usuario denominado b2c_1_sign_in en un fabrikamb2c.onmicrosoft.com inquilino se encuentra en:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration
Una de las propiedades de este documento de configuración es .jwks_uri El valor del mismo flujo de usuario sería:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys
Para determinar qué flujo de usuario se usó para firmar un token de identificador (y dónde capturar los metadatos), puede usar cualquiera de las siguientes opciones:
El nombre del flujo de usuario se incluye en la notificación
acrenid_token. Para obtener información sobre cómo analizar las declaraciones de un token de identificador, consulte la referencia del token de Azure AD B2C.Codifique el flujo de usuario en el valor del
stateparámetro al emitir la solicitud. A continuación, descodifique elstateparámetro para determinar qué flujo de usuario se usó.
Después de adquirir el documento de metadatos del punto de conexión de metadatos de OpenID Connect, puede usar las claves públicas RSA-256 (ubicadas en este punto de conexión) para validar la firma del token de identificador. Puede haber varias claves enumeradas en este punto de conexión en un momento dado, cada una identificada por .kid El encabezado de id_token también contiene una kid alegación. Indica cuál de estas claves se usó para firmar el token de identificador. Para más información, incluido el aprendizaje sobre la validación de tokens, consulte la referencia de tokens de Azure AD B2C.
Después de validar la firma del token de ID, varias reclamaciones requieren comprobación. Por ejemplo:
Valide la notificación
noncepara evitar ataques de reproducción del token. El valor debe ser el que usted especificó en la solicitud de inicio de sesión.Valide la
audreivindicación para confirmar que el token de identificación se emitió para tu app. Su valor debe ser el identificador de aplicación de la aplicación.Valide las
iatyexpreclamaciones para verificar que el token de identificación no ha expirado.
Varias validaciones adicionales que debe realizar se describen en detalle en la especificación de OpenID Connect Core. También podría desear validar atributos adicionales, dependiendo de su escenario. Algunas validaciones comunes incluyen:
Asegurarse de que el usuario o la organización se ha registrado en la aplicación.
Asegurarse de que el usuario tiene la autorización y los privilegios adecuados.
Asegurarse de que se ha producido una cierta seguridad de la autenticación, como mediante la autenticación multifactor de Microsoft Entra.
Para obtener más información sobre las reclamaciones en un token de ID, consulte la referencia de tokens de Azure AD B2C.
Después de validar el token de identificador, puede iniciar una sesión con el usuario. Use las notificaciones del token de identificador para obtener información sobre el usuario en la aplicación. Esta información se puede usar para mostrar, registros, autorización, etc.
Obtención de tokens de acceso
Si lo único que las aplicaciones web deben hacer es ejecutar flujos de usuario, puede omitir las secciones siguientes. La información de las secciones siguientes solo se aplica a las aplicaciones web que necesitan realizar llamadas autenticadas a una API web protegida por el propio Azure AD B2C.
Ahora que el usuario ha iniciado sesión en su SPA, puede obtener tokens de acceso para llamar a las API web protegidas por Microsoft Entra ID. Incluso si ya ha recibido un token mediante el token tipo de respuesta, puede usar este método para adquirir tokens para recursos adicionales sin redirigir al usuario para iniciar sesión de nuevo.
En un flujo de aplicación web típico, realizaría una solicitud al /token punto de conexión. Sin embargo, el punto de conexión no admite solicitudes CORS, por lo que realizar llamadas AJAX para obtener un token de actualización no es una opción. En su lugar, puede usar el flujo implícito en un elemento iframe HTML oculto para obtener nuevos tokens para otras API web. Aquí tienes un ejemplo, con saltos de línea para mejorar la legibilidad.
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
&response_mode=fragment
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
&prompt=none
| Parámetro | ¿Obligatorio? | Descripción |
|---|---|---|
| {inquilino} | Obligatorio | Nombre del inquilino de Azure AD B2C |
| {política} | Obligatorio | Flujo de usuario que se va a ejecutar. Especifique el nombre de un flujo de usuario que ha creado en el inquilino de Azure AD B2C. Por ejemplo: b2c_1_sign_in, b2c_1_sign_up, o b2c_1_edit_profile. |
| ID de cliente | Obligatorio | Identificador de aplicación asignado a la aplicación en Azure Portal. |
| tipo_de_respuesta | Obligatorio | Debe incluir id_token para el inicio de sesión en OpenID Connect. También puede incluir el tipo tokende respuesta . Si usa token aquí, la aplicación puede recibir inmediatamente un token de acceso del punto de conexión de autorización, sin realizar una segunda solicitud al punto de conexión de autorización. Si usa el token tipo de respuesta, el scope parámetro debe contener un ámbito que indique a qué recurso se va a emitir el token. |
| URI de redirección | Recomendado | El URI de redireccionamiento de la aplicación, adonde la aplicación puede enviar y recibir las respuestas de autenticación. Debe coincidir exactamente con uno de los URI de redireccionamiento que ha registrado en el portal, con la excepción de que debe estar codificado como URL. |
| alcance | Obligatorio | Lista de ámbitos separados por espacios. Para obtener tokens, incluya todos los alcances que necesita para el recurso que desea utilizar. |
| modo_de_respuesta | Recomendado | Especifica el método que se usa para devolver el token resultante a la aplicación. Para los flujos implícitos, use fragment. Se pueden especificar otros dos modos, query y form_post, pero no funcionan en el flujo implícito. |
| estado | Recomendado | Un valor incluido en la solicitud que se devuelve en la respuesta del token. Puede ser cualquier cadena de contenido que desee utilizar. Normalmente, se usa un valor único generado aleatoriamente para evitar ataques de falsificación de solicitudes entre sitios. El estado también se usa para codificar información sobre el estado del usuario en la aplicación antes de que se haya producido la solicitud de autenticación. Por ejemplo, la página o vista en la que se encontraba el usuario. |
| valor de seguridad | Obligatorio | Un valor incluido en la solicitud, generada por la aplicación, que se incluirá en el token de identificador resultante como una notificación. La aplicación puede comprobar este valor para mitigar los ataques de reutilización de token. Normalmente, el valor es una cadena única aleatoria que identifica el origen de la solicitud. |
| inmediato | Obligatorio | Para actualizar y obtener tokens en un iframe oculto, use prompt=none para asegurarse de que el iframe no se bloquea en la página de inicio de sesión y se devuelve inmediatamente. |
| sugerencia_de_inicio_de_sesión | Obligatorio | Para actualizar y obtener tokens en un iframe oculto, incluya el nombre de usuario del usuario en esta sugerencia para distinguir entre varias sesiones que el usuario podría tener en un momento dado. Puede extraer el nombre de usuario de un inicio de sesión anterior mediante la notificación preferred_username (el ámbito profile es obligatorio para recibir la notificación preferred_username). |
| indicador_de_dominio | Obligatorio | Puede ser consumers o organizations. Para actualizar y obtener tokens en un iframe oculto, incluya el valor domain_hint en la solicitud. Extraiga la notificación tid del token de identificador de un inicio de sesión anterior para determinar qué valor usar (el ámbito profile es obligatorio para recibir la notificación tid). Si el valor de la tid reclamación es 9188040d-6c67-4c5b-b112-36a304b66dad, utilice domain_hint=consumers. De lo contrario, use domain_hint=organizations. |
Al establecer el parámetro prompt=none, esta solicitud se realiza correctamente o produce un error inmediatamente, y vuelve a la aplicación. Una respuesta correcta se envía a la aplicación a través del URI de redirección mediante el método especificado en el response_mode parámetro .
Respuesta exitosa
Una respuesta correcta mediante response_mode=fragment tiene un aspecto similar al de este ejemplo:
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
| Parámetro | Descripción |
|---|---|
| token de acceso | El token que solicitó la aplicación. |
| tipo_de_token | El tipo de token siempre será un token de portador. |
| estado | Si un parámetro state está incluido en la solicitud, debería aparecer el mismo valor en la respuesta. La aplicación debe comprobar que los state valores de la solicitud y la respuesta son idénticos. |
| expira_en | Período de validez del token de acceso (en segundos). |
| alcance | Ámbitos para los que el token de acceso es válido. |
Respuesta de error
Las respuestas de error también se pueden enviar al URI de redirección para que la aplicación pueda controlarlas correctamente. Para prompt=none, un error esperado es similar al de este ejemplo:
GET https://aadb2cplayground.azurewebsites.net/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently
| Parámetro | Descripción |
|---|---|
| error | Cadena de código de error que se puede usar para clasificar tipos de errores que se producen. También puede usar la cadena para reaccionar a los errores. |
| descripción_del_error | Un mensaje de error específico que puede ayudarlo a identificar la causa raíz de un error de autenticación. |
Si recibe este error en la solicitud de iframe, el usuario debe iniciar sesión de nuevo de manera interactiva para recuperar un nuevo token.
Tokens de actualización
Los tokens de identificador y los tokens de acceso expiran después de un breve período de tiempo. La aplicación debe estar preparada para actualizar estos tokens periódicamente. Los flujos implícitos no permiten obtener un token de actualización debido a motivos de seguridad. Para actualizar cualquier tipo de token, use el flujo implícito en un elemento iframe HTML oculto. En la solicitud de autorización se incluye el prompt=none parámetro . Para recibir un nuevo valor de id_token, asegúrese de usar response_type=id_token y scope=openid, así como un parámetro nonce.
Envío de una solicitud de cierre de sesión
Cuando quiera cerrar la sesión del usuario de la aplicación, redirija al usuario al punto de conexión de cierre de sesión de Azure AD B2C. A continuación, puede borrar la sesión del usuario en la aplicación. Si no lo redirige, el usuario podría volver a autenticar la aplicación sin escribir sus credenciales de nuevo, ya que tiene un inicio de sesión único válido con el punto de conexión de Azure AD B2C.
Simplemente puede redirigir al usuario al end_session_endpoint que aparece en el mismo documento de metadatos de OpenID Connect descrito en Validar el token de identificador. Por ejemplo:
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
| Parámetro | Obligatorio | Descripción |
|---|---|---|
| {inquilino} | Sí | Nombre del inquilino de Azure AD B2C. |
| {política} | Sí | Flujo de usuario que desea usar para cerrar la sesión del usuario de la aplicación. Debe ser el mismo flujo de usuario que la aplicación usó para iniciar sesión. |
| URI de redirección después de cierre de sesión | No | Dirección URL a la que se debe redirigir el usuario después de cerrar la sesión correctamente. Si no se incluye, Azure AD B2C muestra al usuario un mensaje genérico. |
| estado | No | Si un parámetro state está incluido en la solicitud, debería aparecer el mismo valor en la respuesta. La aplicación debe comprobar que los state valores de la solicitud y la respuesta son idénticos. |
Nota:
Al dirigir al usuario a end_session_endpoint se borra parte del estado del inicio de sesión único del usuario con Azure AD B2C. En cambio, no cierra la sesión del proveedor de identidades sociales del usuario. Si el usuario selecciona el mismo proveedor de identidades durante un inicio de sesión posterior, el usuario se vuelve a autenticar, sin escribir sus credenciales. Si un usuario quiere cerrar la sesión de la aplicación de Azure AD B2C, no significa necesariamente que quiera cerrar sesión completamente en su cuenta de Facebook, por ejemplo. Sin embargo, para las cuentas locales, la sesión del usuario se finalizará correctamente.
Pasos siguientes
Consulte el ejemplo de código: Inicio de sesión con Azure AD B2C en una SPA de JavaScript.