Flujo de código de autorización de OAuth 2.0 en Azure Active Directory B2C

2025-05-05

Importante

A partir del 1 de mayo de 2025, Azure AD B2C ya no estará disponible para ser adquirido por nuevos clientes. Obtenga más información en nuestras preguntas más frecuentes.

Puede usar la concesión de código de autorización de OAuth 2.0 en las aplicaciones instaladas en un dispositivo para obtener acceso a los recursos protegidos, como las API web. Mediante la implementación de Azure Active Directory B2C (Azure AD B2C) de OAuth 2.0, puede agregar tareas de registro, inicio de sesión y otras tareas de administración de identidades a las aplicaciones de una sola página, móviles y de escritorio. En este artículo se describe cómo enviar y recibir mensajes HTTP sin usar bibliotecas de código abierto. Este artículo es independiente del lenguaje. Cuando sea posible, se recomienda usar las bibliotecas de autenticación de Microsoft (MSAL) admitidas. Eche un vistazo a las aplicaciones de ejemplo que usan MSAL.

El flujo de código de autorización de OAuth 2.0 se describe en la sección 4.1 de la especificación de OAuth 2.0. Puede usarlo para la autenticación y autorización en la mayoría de los tipos de aplicación, incluidas las aplicaciones web, las aplicaciones de página única y las aplicaciones instaladas de forma nativa. Puede usar el flujo de código de autorización de OAuth 2.0 para adquirir de forma segura tokens de acceso y tokens de actualización para las aplicaciones, que se pueden usar para acceder a los recursos protegidos por un servidor de autorización. El token de actualización permite al cliente adquirir nuevos tokens de acceso (y actualización) una vez que expire el token de acceso, normalmente después de una hora.

Este artículo se centra en el flujo de código de autorización de OAuth 2.0 de los clientes públicos . Un cliente público es cualquier aplicación cliente que no pueda ser de confianza para mantener de forma segura la integridad de una contraseña secreta. Esto incluye aplicaciones de página única, aplicaciones móviles, aplicaciones de escritorio y básicamente cualquier aplicación que no se ejecute en un servidor.

Nota:

Para agregar la administración de identidades a una aplicación web mediante Azure AD B2C, use OpenID Connect en lugar de OAuth 2.0.

Azure AD B2C amplía los flujos estándar de OAuth 2.0 para realizar más que la autenticación y autorización simples. Presenta el flujo de usuario. Con los flujos de usuario, puede usar OAuth 2.0 para agregar experiencias de usuario a la aplicación, como el registro, el inicio de sesión y la administración de perfiles. Los proveedores de identidades que usan el protocolo OAuth 2.0 incluyen Amazon, Microsoft Entra ID, Facebook, GitHub, Google y LinkedIn.

Para probar las solicitudes HTTP de este artículo:

Reemplace {tenant} por el nombre del inquilino de Azure AD B2C.
Reemplace 00001111-aaaa-2222-bbbb-3333cccc4444 por el id. de la aplicación que registró previamente en el inquilino de Azure AD B2C.
Reemplace {policy} por el nombre de una directiva que ha creado en el inquilino, por ejemplo, b2c_1_sign_in.

Configuración de URI de redirección necesaria para aplicaciones de página única

El flujo de código de autorización para aplicaciones de página única requiere una configuración adicional. Siga las instrucciones para crear tu aplicación de página única y habilitar correctamente el URI de redirección para CORS. Para actualizar un URI de redireccionamiento existente para habilitar CORS, puede hacer clic en el indicador de migración en la sección "Web" de la pestaña Autenticación del registro de aplicaciones. Como alternativa, puede abrir el editor de manifiestos del registro de aplicaciones y establecer el campo type para su URI de redireccionamiento en spa en la sección replyUrlsWithType.

El spa tipo de redireccionamiento es retrocompatible con el flujo implícito. Las aplicaciones que usan actualmente el flujo implícito para obtener tokens pueden moverse al tipo de URI de redireccionamiento spa sin problemas y seguir usando el flujo implícito.

1. Obtener un código de autorización

El flujo del código de autorización comienza con el cliente dirigiendo al usuario al punto de conexión /authorize . Esta es la parte interactiva del flujo, donde el usuario realiza la acción. En esta solicitud, el cliente indica en el scope parámetro los permisos que necesita adquirir del usuario. Los ejemplos siguientes (con saltos de línea para mejorar la legibilidad) muestran cómo adquirir un código de autorización. Si va a probar esta solicitud HTTP GET, use el explorador.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=00001111-aaaa-2222-bbbb-3333cccc4444%20offline_access%20https://{tenant-name}/{app-id-uri}/{scope}
&state=arbitrary_data_you_can_receive_in_the_response
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256

Parámetro	¿Obligatorio?	Descripción
{inquilino}	Obligatorio	Nombre del inquilino de Azure AD B2C
{política}	Obligatorio	El 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	El tipo de respuesta, que debe incluir `code` para el flujo de código de autorización. Puede recibir un token de identificador si lo incluye en el tipo de respuesta, como `code+id_token`, y en este caso, el ámbito debe incluir `openid`.
URI de redirección	Obligatorio	El URI de redirección de la aplicación, donde su aplicación envía y recibe 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. 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 ámbito `offline_access` es opcional para las aplicaciones web. Indica que la aplicación necesita un token de actualización para el acceso extendido a los recursos. El id. de cliente indica que el token emitido está diseñado para que lo use el cliente registrado de Azure AD B2C. El `https://{tenant-name}/{app-id-uri}/{scope}` indica un permiso para los recursos protegidos, como una API web. Para obtener más información, consulte Solicitud de un token de acceso.
modo_de_respuesta	Recomendado	El método que se usa para devolver el código de autorización resultante a la aplicación. Puede ser `query`, `form_post` o `fragment`.
estado	Recomendado	Un valor incluido en la solicitud que puede ser una cadena de cualquier contenido que desee usar. Se suele usar un valor único generado de manera aleatoria para evitar los 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 en la que se encontraba el usuario o el flujo de usuario que se estaba ejecutando.
inmediato	Opcional	Tipo de interacción del usuario necesaria. Actualmente, el único valor válido es `login`, que obliga al usuario a escribir sus credenciales en esa solicitud. El inicio de sesión único no surtirá efecto.
desafío_de_código	recomendado/requerido	Se usa para proteger las concesiones de código de autorización a través de la clave de prueba para intercambio de código (PKCE). Se requiere si se incluye `code_challenge_method`. Debe agregar lógica a la aplicación para generar `code_verifier` y `code_challenge`. `code_challenge` es un hash SHA256 con codificación URL base64 de `code_verifier`. El `code_verifier` se almacena en la aplicación para su uso posterior y se envía el `code_challenge` junto con la solicitud de autorización. Para obtener más información, consulte PKCE RFC. Ahora se recomienda para todos los tipos de aplicación: aplicaciones nativas, SPA y clientes confidenciales, como aplicaciones web.
`code_challenge_method`	recomendado/requerido	Método utilizado para codificar `code_verifier` para el parámetro `code_challenge`. Debe ser `S256`, pero la especificación permite el uso de `plain` si por algún motivo el cliente no puede admitir SHA256. Si excluye el `code_challenge_method`, pero todavía incluye el `code_challenge`, entonces se supone que el `code_challenge` es texto plano. La plataforma de identidad de Microsoft admite tanto `plain` como `S256`. Para obtener más información, consulte PKCE RFC. Esto es necesario para las aplicaciones de página única mediante el flujo de código de autorización.
sugerencia_de_inicio_de_sesión	No	Se puede usar para rellenar previamente el campo nombre de inicio de sesión de la página de inicio de sesión. Para obtener más información, consulte Rellenar previamente el nombre de inicio de sesión.
indicador_de_dominio	No	Proporciona una sugerencia a Azure AD B2C sobre el proveedor de identidades sociales que se debe usar para el inicio de sesión. Si se incluye un valor válido, el usuario va directamente a la página de inicio de sesión del proveedor de identidades. Para obtener más información, consulte Redireccionamiento del inicio de sesión a un proveedor de redes sociales.
Parámetros personalizados	No	Parámetros personalizados que se pueden usar con directivas personalizadas. Por ejemplo, el URI de contenido de página personalizada dinámica o los solucionadores de notificaciones de clave-valor.

En este momento, se le pide al usuario que complete el flujo de trabajo del flujo de usuario. Esto puede implicar que el usuario escriba su nombre de usuario y contraseña, inicie sesión con una identidad social, regístrese en el directorio o cualquier otro número de pasos. Las acciones de usuario dependen de cómo se define el flujo de usuario.

Después de que el usuario complete el flujo de usuario, Microsoft Entra ID devuelve una respuesta a su aplicación con el valor que usó para 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ó.

Una respuesta correcta que usa response_mode=query tiene este aspecto:

GET urn:ietf:wg:oauth:2.0:oob?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...        // the authorization_code, truncated
&state=arbitrary_data_you_can_receive_in_the_response                // the value provided in the request

Parámetro	Descripción
código	El código de autorización que solicitó la aplicación. La aplicación puede usar el código de autorización para solicitar un token de acceso para un recurso de destino. Los códigos de autorización son de corta duración. Normalmente, caducan al cabo de unos 10 minutos.
estado	Consulte la descripción completa de la tabla en la sección anterior. 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.

Las respuestas de error también se pueden enviar al URI de redirección para que la aplicación pueda controlarlas correctamente:

GET urn:ietf:wg:oauth:2.0:oob?
error=access_denied
&error_description=The+user+has+cancelled+entering+self-asserted+information
&state=arbitrary_data_you_can_receive_in_the_response

Parámetro	Descripción
error	Cadena de código de error que puede usar para clasificar los 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.
estado	Consulte la descripción completa de la tabla anterior. 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.

2. Obtención de un token de acceso

Ahora que ha adquirido un código de autorización, puede canjear el code de un token al recurso previsto mediante el envío de una solicitud POST al punto de conexión de /token. En Azure AD B2C, puede solicitar tokens de acceso para otras API como de costumbre especificando sus ámbitos en la solicitud.

También puede solicitar un token de acceso para la API web de back-end de la propia aplicación mediante la convención de usar el identificador de cliente de la aplicación como ámbito solicitado, lo que dará lugar a un token de acceso con ese identificador de cliente como audiencia.

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong

Parámetro	¿Obligatorio?	Descripción
{inquilino}	Obligatorio	Nombre del inquilino de Azure AD B2C
{política}	Obligatorio	Flujo de usuario que se usó para adquirir el código de autorización. No puede usar un flujo de usuario diferente en esta solicitud.
ID de cliente	Obligatorio	Identificador de aplicación asignado a la aplicación en Azure Portal.
secreto_del_cliente	Sí, en Web Apps	Secreto de aplicación que se generó en Azure Portal. Los secretos de cliente se usan en este flujo para escenarios de aplicación web, donde el cliente puede almacenar de forma segura un secreto de cliente. En escenarios de aplicación nativa (cliente público), los secretos de cliente no se pueden almacenar de forma segura y, por tanto, no se usan en esta llamada. Si usa un secreto de cliente, cámbielo periódicamente.
tipo_de_subvención	Obligatorio	Tipo de concesión. Para el flujo de código de autorización, el tipo de concesión debe ser `authorization_code`.
alcance	Recomendado	Lista de ámbitos separados por espacios. Un único valor de ámbito indica a Azure AD B2C ambos permisos que se solicitan. Usar el identificador de cliente como ámbito significa que tu aplicación necesita un token de acceso que se pueda utilizar con tu propio servicio o API web, representado por el mismo identificador de cliente. El ámbito de `offline_access` indica que la aplicación necesita un token de actualización para el acceso de larga duración a los recursos. También puede usar el `openid` ámbito para solicitar un token de identificador de Azure AD B2C.
código	Obligatorio	El código de autorización que adquirió del punto de conexión `/authorize`.
URI de redirección	Obligatorio	URI de redirección de la aplicación donde hayas recibido el código de autorización.
verificador_de_código	recomendado	Lo mismo `code_verifier` que se usa para obtener el código de autorización. Se requiere si PKCE se utilizó en la solicitud de concesión de código de autorización. Para obtener más información, consulte PKCE RFC.

Si va a probar esta solicitud HTTP POST, puede usar cualquier cliente HTTP como Microsoft PowerShell.

Una respuesta de token correcta tiene este aspecto:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

Parámetro	Descripción
no antes de	Hora a la que el token se considera válido, en tiempo de época.
tipo_de_token	Valor del tipo de token. El único tipo que admite Microsoft Entra ID es Bearer.
token de acceso	Token web JSON (JWT) firmado que solicitó.
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.
expira_en	El período de tiempo que el token es válido (en segundos).
token de actualización	Un token de actualización de OAuth 2.0. La aplicación puede usar este token para adquirir tokens adicionales después de que expire el token actual. Los tokens de actualización son de larga duración. Puede usarlos para conservar el acceso a los recursos durante largos períodos de tiempo. Para más información, consulte la referencia de tokens de Azure AD B2C.

Las respuestas de error tienen este aspecto:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}

Parámetro	Descripción
error	Cadena de código de error que puede usar para clasificar los 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.

3. Uso del token

Ahora que ha adquirido correctamente un token de acceso, puede usar el token en las solicitudes a las API web de back-end mediante su inclusión en el encabezado Authorization:

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

4. Actualizar el token

Los tokens de acceso y los tokens de identificador son de corta duración. Una vez que expiren, debe actualizarlos para seguir accediendo a los recursos. Al actualizar el token de acceso, Azure AD B2C devuelve un nuevo token. El token de acceso actualizado tendrá actualizados nbf (no antes), iat (emitidos en) y valores de notificación exp (expiración). Todos los demás valores de notificación son los mismos que el token de acceso emitido originalmente.

Para actualizar el token, envíe otra solicitud POST al /token punto de conexión. Esta vez, proporcione el refresh_token en lugar del code.

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Parámetro	¿Obligatorio?	Descripción
{inquilino}	Obligatorio	Nombre del inquilino de Azure AD B2C
{política}	Obligatorio	Flujo de usuario que se usó para adquirir el token de actualización original. No puede usar un flujo de usuario diferente en esta solicitud.
ID de cliente	Obligatorio	Identificador de aplicación asignado a la aplicación en Azure Portal.
secreto_del_cliente	Sí, en Web Apps	Secreto de aplicación que se generó en Azure Portal. Los secretos de cliente se usan en este flujo para escenarios de aplicación web, donde el cliente puede almacenar de forma segura un secreto de cliente. En escenarios de aplicación nativa (cliente público), los secretos de cliente no se pueden almacenar de forma segura y, por tanto, no se usan en esta llamada. Si usa un secreto de cliente, cámbielo periódicamente.
tipo_de_subvención	Obligatorio	Tipo de concesión. Para este segmento del flujo de código de autorización, el tipo de concesión debe ser `refresh_token`.
alcance	Recomendado	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. Usar el identificador de cliente como ámbito significa que tu aplicación necesita un token de acceso que se pueda utilizar con tu propio servicio o API web, representado por el mismo identificador de cliente. El ámbito de `offline_access` indica que la aplicación necesita un token de actualización para el acceso de larga duración a los recursos. También puede usar el `openid` ámbito para solicitar un token de identificador de Azure AD B2C.
URI de redirección	Opcional	URI de redirección de la aplicación donde hayas recibido el código de autorización.
token de actualización	Obligatorio	Token de actualización original que adquirió en la segunda etapa del flujo.

Una respuesta de token correcta tiene este aspecto:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

Parámetro	Descripción
no antes de	Hora a la que el token se considera válido, en tiempo de época.
tipo_de_token	Valor del tipo de token. El único tipo que admite Microsoft Entra ID es Bearer.
token de acceso	JWT firmado que solicitó.
alcance	Ámbitos para los que el token es válido. También puede usar los scopes para almacenar en caché los tokens para su uso posterior.
expira_en	El período de tiempo que el token es válido (en segundos).
token de actualización	Un token de actualización de OAuth 2.0. La aplicación puede usar este token para adquirir tokens adicionales después de que expire el token actual. Los tokens de actualización son de larga duración y se pueden usar para conservar el acceso a los recursos durante largos períodos de tiempo. Para más información, consulte la referencia de tokens de Azure AD B2C.

Las respuestas de error tienen este aspecto:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}

Parámetro	Descripción
error	Cadena de código de error que puede usar para clasificar los 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.

Uso de su propio directorio de Azure AD B2C

Para probar estas solicitudes usted mismo, complete los pasos siguientes. Reemplace los valores de ejemplo que hemos usado en este artículo por sus propios valores.

Cree un directorio de Azure AD B2C. Use el nombre del directorio en las solicitudes.
Cree una aplicación para obtener un identificador de aplicación y un URI de redirección. Incluya un cliente nativo en la aplicación.
Cree los flujos de usuario para obtener sus nombres de flujo de usuario.

Compartir a través de