Novedades en la autenticación

Microsoft agrega y modifica periódicamente las características y la funcionalidad de la plataforma de identidad de Microsoft para mejorar su seguridad, facilidad de uso y cumplimiento de estándares.

A menos que se indique lo contrario, los cambios descritos aquí solo se aplican a las aplicaciones registradas después de la fecha efectiva del cambio indicada.

Consulte este artículo periódicamente para obtener información sobre:

• Problemas conocidos y correcciones
• Cambios en el protocolo
• Funciones obsoletas

Sugerencia

Para recibir notificaciones de las actualizaciones de esta página, agregue esta dirección URL al lector de fuentes RSS:
https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us

Octubre de 2023

Mensaje de la experiencia de usuario de RemoteConnect actualizado

Fecha de entrada en vigor: octubre de 2023

Puntos de conexión afectados: v2.0 y v1.0

Protocolo afectado: RemoteConnect

RemoteConnect es un flujo entre dispositivos que se utiliza para escenarios relacionados con el agente de autenticación de Microsoft y Microsoft Intune que implican tokens de actualización primarios. Para ayudar a prevenir los ataques de suplantación de identidad, el flujo de RemoteConnect recibirá actualizaciones del idioma de la experiencia de usuario para indicar que el dispositivo remoto (que inició el flujo) podrá acceder a cualquier aplicación que su organización utilice una vez completado correctamente el flujo.

El mensaje que aparecerá será similar al siguiente:

Junio de 2023

Omisión de notificaciones de correo electrónico con un propietario de dominio no comprobado

Fecha de entrada en vigor: junio de 2023

Puntos de conexión afectados: v2.0 y v1.0

Cambio

En el caso de las aplicaciones multiinquilino, los correos electrónicos que no sean comprobados por el propietario del dominio se omitirán de forma predeterminada cuando se solicite la notificación opcional email en una carga de token.

Se considera que un correo electrónico fue comprobado por el propietario del dominio si:

1. El dominio pertenece al inquilino donde reside la cuenta de usuario y el administrador del inquilino realizó la comprobación del dominio.
2. El correo electrónico procede de una cuenta de Microsoft (MSA).
3. El correo electrónico procede de una cuenta de Google.
4. El correo electrónico se usó para la autenticación mediante el flujo de código de acceso de un solo uso (OTP).

También debe tenerse en cuenta que las cuentas de Facebook y SAML/WS-Fed no tienen dominios comprobados.

Mayo de 2023

Se cambiará el nombre del rol Administrador de Power BI a Administrador de Fabric.

Fecha de entrada en vigor: junio de 2023

Puntos de conexión afectados:

• Enumerar roleDefinitions: Microsoft Graph v1.0
• Enumerar directoryRoles: Microsoft Graph v1.0

Cambio

Se cambiará el nombre del rol Administrador de Power BI a Administrador de Fabric.

El 23 de mayo de 2023, Microsoft presentó Microsoft Fabric, que proporciona una experiencia de integración de datos con tecnología de Data Factory, ingeniería de datos con tecnología Synapse, almacenamiento de datos, ciencia de datos y experiencias de análisis en tiempo real e inteligencia empresarial (BI) con Power BI, todo hospedada en una solución SaaS centrada en lago. La administración de inquilinos y capacidades para estas experiencias se centraliza en el portal de Administración de Fabric (anteriormente conocido como portal de administración de Power BI).

A partir de junio de 2023, se cambiará el nombre del rol Administrador de Power BI a Administrador de Fabric para ajustarse al ámbito y la responsabilidad cambiantes de este rol. Todas las aplicaciones, incluidos Microsoft Entra ID, las API de Microsoft Graph, Microsoft 365 y GDAP comenzarán a reflejar el nuevo nombre de rol durante varias semanas.

Como recordatorio, el código y los scripts de la aplicación no deben tomar decisiones basadas en el nombre del rol o el nombre para mostrar.

Diciembre de 2021

Los usuarios de AD FS verán más solicitudes de inicio de sesión para garantizar que inicia sesión el usuario correcto.

Fecha de entrada en vigor: diciembre de 2021

Puntos de conexión afectados: Autenticación integrada de Windows

Protocolo afectado: Autenticación integrada de Windows

Cambio

En la actualidad, cuando se envía a un usuario a AD FS para autenticarse, iniciará su sesión de forma silenciosa en cualquier cuenta que ya tenga una sesión con AD FS. Este inicio de sesión silencioso se produce incluso si el usuario pretende iniciar sesión en otra cuenta de usuario. Para reducir la frecuencia de este inicio de sesión incorrecto, a partir de diciembre, Microsoft Entra ID enviará elprompt=login parámetro a AD FS si el Administrador de cuentas web en Windows proporciona a Microsoft Entra ID un login_hint durante el inicio de sesión, lo que indica que se desea un usuario específico para el inicio de sesión.

Cuando se cumplen los requisitos anteriores (WAM se usa para enviar el usuario a Microsoft Entra ID para iniciar sesión, se incluye un login_hint y se incluye la instancia de AD FS para el dominio del usuario admite prompt=login), el usuario no iniciará sesión silenciosamente y, en su lugar, se le pedirá que proporcione un nombre de usuario para continuar iniciando sesión en AD FS. Si quiere iniciar sesión en su sesión de AD FS existente, puede seleccionar la opción "Continuar como usuario actual" que se muestra debajo de la solicitud de inicio de sesión. De lo contrario, puede continuar con el nombre de usuario con el que pretende iniciar sesión.

Este cambio se implantará en diciembre de 2021 a lo largo de varias semanas. No cambia el comportamiento de inicio de sesión para:

• Aplicaciones que usan IWA directamente
• Aplicaciones que usan OAuth
• Dominios que no están federados en una instancia de AD FS

Octubre de 2021

Se ha corregido el error 50105 para no devolver interaction_required durante la autenticación interactiva

Fecha de entrada en vigor: octubre de 2021

Puntos de conexión afectados: v2.0 y v1.0

Protocolo afectado: todos los flujos de usuario para aplicaciones que requieren la asignación del usuario

Cambio

Se genera el error 50105 (la designación actual) cuando un usuario no asignado intenta iniciar sesión en una aplicación que un administrador ha marcado como necesidad de asignación de usuario. Se trata de un patrón de control de acceso común y los usuarios a menudo deben encontrar un administrador para solicitar la asignación para desbloquear el acceso. El error tenía un error que provocaría bucles infinitos en aplicaciones bien codificadas que controlaban correctamente la respuesta de error interaction_required. interaction_required indica a una aplicación que realice la autenticación interactiva, pero incluso después de hacerlo, Microsoft Entra ID todavía devolvería una respuesta de error interaction_required.

El escenario de error se ha actualizado, por lo que durante la autenticación no interactiva (donde prompt=none se usa para ocultar la experiencia de usuario), se indicará a la aplicación que realice la autenticación interactiva mediante una respuesta de error interaction_required. En la autenticación interactiva posterior, Microsoft Entra ID ahora contendrá al usuario y mostrará un mensaje de error directamente, lo que impide que se produzca un bucle.

Como recordatorio, el código de la aplicación no debe tomar decisiones basadas en cadenas de código de error como AADSTS50105. En su lugar, siga nuestras instrucciones de control de errores y use las respuestas de autenticación estandarizadas como interaction_required y login_required que se encuentran en el campo estándar error de la respuesta. Los demás campos de respuesta están diseñados solo para que los consuman las personas que solucionan sus problemas.

Puede revisar el texto actual del error 50105 y mucho más en el servicio de búsqueda de errores: https://login.microsoftonline.com/error?code=50105.

El URI de AppId en aplicaciones de inquilino único requerirá el uso del esquema predeterminado o los dominios comprobados

Fecha de entrada en vigor: octubre de 2021

Puntos de conexión afectados: v2.0 y v1.0

Protocolo afectado: Todos los flujos

Cambio

En el caso de las aplicaciones de inquilino único, agregar o actualizar el URI de AppId valida que el dominio del URI del esquema HTTPS aparece en la lista de dominios comprobados del inquilino del cliente o que el valor usa el esquema predeterminado (api://{appId}) proporcionado por Microsoft Entra ID. Esto podría impedir que las aplicaciones agreguen un URI de id. de aplicación si el dominio no está en la lista de dominios comprobados o el valor no usa el esquema predeterminado. Para obtener más información sobre los dominios comprobados, consulte la documentación de dominios personalizados.

El cambio no afecta a las aplicaciones existentes que usan dominios no comprobados en su URI de AppID. Valida solo las nuevas aplicaciones o cuando una aplicación existente actualiza un URI de identificador o agrega uno nuevo a la colección identifierUri. Las nuevas restricciones solo se aplican a los URI agregados a la colección identifierUris de una aplicación después del 15 de octubre de 2021. Los URI de AppId que ya estén en la colección identifierUris de una aplicación cuando la restricción entre en vigor el 15 de octubre de 2021 seguirán funcionando aunque se agreguen nuevos URI a esa colección.

Si una solicitud produce un error en la comprobación de validación, la API de la aplicación para crear o actualizar devolverá 400 badrequest al cliente que indica HostNameNotOnVerifiedDomain.

Se admiten los siguientes formatos de URI de identificador de aplicación basados en esquemas HTTP y API. Reemplace los valores de marcador de posición como se describe en la lista que sigue a la tabla.

Identificadores de aplicación admitidos Formatos de URI	Ejemplos de URI de id. de aplicación
api://<appId>	api://fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
api://<tenantId>/<appId>	api://a8573488-ff46-450a-b09a-6eca0c6a02dc/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
api://<tenantId>/<string>	api://a8573488-ff46-450a-b09a-6eca0c6a02dc/api
api://<string>/<appId>	api://productapi/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
https://<tenantInitialDomain>.onmicrosoft.com/<string>	https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string>	https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain>	https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId>: propiedad de identificador de aplicación (appId) del objeto de aplicación.
• <string>: valor de cadena para el host o el segmento de trazado de API.
• <tenantId>: GUID generado por Azure para representar el inquilino dentro de Azure.
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, donde <tenantInitialDomain> es el nombre de dominio inicial que el creador del inquilino especificó durante la creación del inquilino.
• <verifiedCustomDomain>: un dominio personalizado comprobado configurado para el inquilino de Microsoft Entra.

Nota:

Si usa el esquema api://, se agrega un valor de cadena directamente después de "api://". Por ejemplo, api://<string>. Ese valor de cadena puede ser un GUID o una cadena arbitraria. Si agrega un valor GUID, debe coincidir con el identificador de la aplicación o con el identificador de inquilino. El valor de URI del identificador de aplicación debe ser único para el inquilino. Si agrega api://<tenantId> como URI de identificador de aplicación, nadie más podrá usar ese URI en ninguna otra aplicación. La recomendación es usar api://<appId>, en su lugar, o el esquema HTTP.

Importante

El valor de URI del id. de aplicación no debe terminar con un carácter de barra diagonal "/".

Nota

Aunque es seguro quitar los identifierUris para los registros de aplicaciones dentro del inquilino actual, quitarlos puede provocar que los clientes produzcan errores en otros registros de aplicaciones.

Agosto de 2021

El acceso condicional solo se desencadenará para ámbitos solicitados explícitamente

Fecha de entrada en vigor: agosto de 2021, con lanzamiento gradual a partir de abril.

Puntos de conexión afectados: v2.0

Protocolo afectado: todos los flujos que usan el consentimiento dinámico

En la actualidad, a las aplicaciones que usan el consentimiento dinámico se les otorgan todos los permisos para los que tienen consentimiento, incluso si no se solicitaron por nombre en el parámetro scope. Una aplicación que solicita solo user.read, pero con consentimiento para files.read, se puede forzar a pasar el requisito de acceso condicional asignado para files.read, por ejemplo.

Para reducir el número de avisos de acceso condicional innecesarios, Microsoft Entra ID está cambiando la forma en que se proporcionan ámbitos a las aplicaciones, por lo que solo los ámbitos solicitados explícitamente desencadenan el acceso condicional. Las aplicaciones que se basan en el comportamiento anterior de Microsoft Entra ID de incluir todos los ámbitos en el token, ya sea solicitado o no, pueden interrumpirse debido a ámbitos que faltan.

Ahora, las aplicaciones recibirán tokens de acceso con una combinación de permisos: los tokens solicitados y aquellos para los que se tiene consentimiento y que no requieran solicitudes de acceso condicional. Los ámbitos de acceso del token se reflejan en el parámetro scope de la respuesta del token.

Este cambio se realizará en todas las aplicaciones excepto en aquellas con una dependencia observada de este comportamiento. Se informará a los desarrolladores en caso de estar exentos de este cambio, ya que podrían tener una dependencia de las solicitudes adicionales de acceso condicional.

Ejemplos

Una aplicación tiene el consentimiento para user.read, files.readwrite y tasks.read. files.readwrite tiene aplicadas directivas de acceso condicional, mientras que los otros dos no. Si una aplicación realiza una solicitud de token para scope=user.read y el usuario que ha iniciado sesión actualmente no ha pasado ninguna directiva de acceso condicional, el token resultante será para los permisos user.read y tasks.read. Se incluye tasks.read porque la aplicación tiene el consentimiento y no requiere que se aplique una directiva de acceso condicional.

Si, después, la aplicación solicita scope=files.readwrite, el acceso condicional que requiere el inquilino se desencadenará, obligando a la aplicación a mostrar un mensaje de autenticación interactiva en el que se puede satisfacer la directiva de acceso condicional. El token devuelto tendrá los tres ámbitos.

Si la aplicación realiza una última solicitud para cualquiera de los tres ámbitos (por ejemplo, scope=tasks.read), Microsoft Entra ID verá que el usuario ya ha completado las directivas de acceso condicional necesarias para files.readwrite, y de nuevo, emite un token con los tres permisos.

Junio de 2021

La experiencia de usuario para el flujo de código de dispositivo ahora incluirá un mensaje de confirmación de la aplicación

Fecha de entrada en vigor: junio de 2021

Puntos de conexión afectados: v2.0 y v1.0

Protocolo afectado: el flujo de código de dispositivo

Para ayudar a evitar ataques de suplantación de identidad (phishing), el flujo de código del dispositivo ahora incluye una solicitud que valida que el usuario inicia sesión en la aplicación que espera.

El mensaje que aparece tiene el siguiente aspecto:

Mayo de 2020

Corrección de errores: Microsoft Entra ID ya no codificará la dirección URL del parámetro de estado dos veces

Fecha de entrada en vigor: marzo de 2021

Puntos de conexión afectados: v1.0 y v2.0

Protocolo afectado: todos los flujos que visitan el punto de conexión /authorize (flujo implícito y flujo de código de autorización)

Se encontró un error y se corrigió en la respuesta de autorización de Microsoft Entra. Durante el tramo /authorize de autenticación, el parámetro state de la solicitud se incluye en la respuesta, para conservar el estado de la aplicación y ayudar a evitar ataques CSRF. Microsoft Entra ID codificó incorrectamente la dirección URL del parámetro state antes de insertarlo en la respuesta, donde se codificó una vez más. Esto daría lugar a que las aplicaciones rechazaran incorrectamente la respuesta de Microsoft Entra ID.

Microsoft Entra ID ya no codificará este parámetro de forma doble, lo que permite que las aplicaciones analicen correctamente el resultado. Este cambio se realizará para todas las aplicaciones.

Los puntos de conexión de Azure Government están cambiando

Fecha efectiva: 5 de mayo de 2020 (finaliza en junio de 2020)

Puntos de conexión afectados: All

Protocolo afectado: Todos los flujos

El 1 de junio de 2018, la autoridad oficial de Microsoft Entra para Azure Government cambió de https://login-us.microsoftonline.com a https://login.microsoftonline.us. Este cambio también se aplica a Microsoft 365 GCC High y DoD, que Azure Government Microsoft Entra ID también ofrece servicios. Si es propietario de una aplicación en un inquilino de la Administración Pública de EE. UU., debe actualizar la aplicación para que la sesión de los usuarios se inicie en el punto de conexión .us.

El 5 de mayo de 2020, Microsoft Entra ID comenzará a aplicar el cambio de punto de conexión, lo que impide que los usuarios gubernamentales inicien sesión en aplicaciones hospedadas en inquilinos de la Administración Pública de Estados Unidos mediante el punto de conexión público (microsoftonline.com). Las aplicaciones afectadas comenzarán a experimentar un error AADSTS900439 - USGClientNotSupportedOnPublicEndpoint. Este error indica que la aplicación está intentando iniciar la sesión de un usuario de la Administración Pública de EE. UU. en el punto de conexión de nube pública. Si su aplicación se encuentra en un inquilino en la nube pública y tiene previsto prestar servicio a usuarios del Gobierno de EE. UU., deberá actualizar la aplicación para que los admita de forma explícita. Esto puede requerir la creación de un nuevo registro de aplicaciones en la nube de la Administración Pública de EE. UU.

La aplicación de este cambio se realizará mediante un lanzamiento gradual basado en la frecuencia con que los usuarios de la nube de la Administración Pública de EE. UU. inician sesión en la aplicación: se aplicará antes a las aplicaciones que inician sesión de usuarios de la Administración Pública de EE. UU. con poca frecuencia, mientras que las aplicaciones que los usuarios de la Administración Pública de EE. UU. usan con frecuencia serán las últimas a las que se aplicará. Esperamos que el cambio se haya completado en todas las aplicaciones en junio de 2020.

Para obtener más información, consulte la entrada de blog de Azure Government sobre esta migración.

Marzo de 2020

Las contraseñas de usuario tendrán un límite de 256 caracteres.

Fecha efectiva: 13 de marzo de 2020

Puntos de conexión afectados: All

Protocolo afectado: Todos los flujos de usuario.

Se pedirá a los usuarios con contraseñas de más de 256 caracteres que inicien sesión directamente en Microsoft Entra ID (no en un IDP federado, como AD FS) para poder iniciar sesión. Es posible que los administradores reciban solicitudes de ayuda para restablecer la contraseña del usuario.

El error en los registros de inicio de sesión será similar a AADSTS 50052: InvalidPasswordExceedsMaxLength.

Mensaje: The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.

Corrección:

El usuario no puede iniciar sesión porque su contraseña supera la longitud máxima permitida. Debe ponerse en contacto con su administrador para restablecer la contraseña. Si SSPR está habilitado en su inquilino, puede restablecer la contraseña siguiendo el vínculo "¿Ha olvidado la contraseña?".

Febrero de 2020

Los fragmentos vacíos se anexarán a cada redirección HTTP desde el punto de conexión de inicio de sesión.

Fecha efectiva: 8 de febrero de 2020

Puntos de conexión afectados: v1.0 y v2.0

Protocolo afectado: flujos de OAuth y OIDC que usan response_type=query, abarca el flujo de código de autorización en algunos casos y el flujo implícito.

Cuando se envía una respuesta de autenticación desde login.microsoftonline.com a una aplicación a través de la redirección HTTP, el servicio anexará un fragmento vacío a la dirección URL de respuesta. Esto evita una clase de ataques de redireccionamiento, ya que se asegura de que el explorador borre todo fragmento existente en la solicitud de autenticación. Ninguna aplicación debe tener una dependencia de este comportamiento.

Agosto de 2019

La semántica del formulario POST se aplicará más estrictamente y se omitirán los espacios y comillas.

Fecha efectiva: 2 de septiembre de 2019

Puntos de conexión afectados: v1.0 y v2.0

Protocolo afectado: Se usa POST en cualquier lugar(credenciales de cliente, canje de código de autorización, ROPC, OBO y canje de token de actualización).

A partir de la semana del 2 de septiembre de 2019, las solicitudes de autenticación que usan el método POST se validarán con estándares HTTP más estrictos. Concretamente, los espacios y las comillas dobles (") ya no se quitarán de los valores del formulario de solicitud. Estos cambios no se espera que interrumpan ningún cliente existente y se asegurará de que las solicitudes enviadas a Microsoft Entra ID se controlen de forma confiable cada vez. En el futuro (consulte más arriba), tenemos previsto rechazar además los parámetros duplicados y omitir la marca BOM dentro de las solicitudes.

Ejemplo:

En la actualidad, ?e= "f"&g=h se analiza exactamente igual que ?e=f&g=h, por tanto e == f. Con este cambio, ahora se analizaría para que e == "f"; esto es improbable que sea un argumento válido y la solicitud no se realizará correctamente.

Julio de 2019

Los tokens solo de aplicación para aplicaciones de inquilino único solo se emiten si la aplicación cliente existe en el inquilino de recursos.

Fecha efectiva: 26 de julio de 2019

Puntos de conexión afectados: v1.0 y v2.0

Protocolo afectado: credenciales de cliente (tokens de solo aplicación)

El 26 de julio de 2019 se aplicó un cambio de seguridad que modifica la manera en la que se emiten los tokens de solo aplicación (a través de la concesión de credenciales de cliente). Anteriormente, las aplicaciones podían obtener tokens para llamar a cualquier otra aplicación, sin tener en cuenta su presencia en el inquilino o los roles con consentimiento para esa aplicación. Este comportamiento se ha actualizado de modo que, en el caso de los recursos (a veces denominados API web) configurados para ser inquilino único (el valor predeterminado), la aplicación cliente debe existir en el inquilino de recursos. Aún no se requiere que exista consentimiento entre el cliente y la API, y las aplicaciones todavía deben realizar sus propias comprobaciones de autorización para asegurarse de que existe una notificación roles y de que contiene el valor esperado para la API.

El mensaje de error de este escenario indica actualmente:

The service principal named <appName> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.

Para solucionar este problema, use la experiencia de consentimiento del administrador con el fin de crear la entidad de servicio de la aplicación cliente en el inquilino o bien créela manualmente. Este requisito garantiza que el inquilino ha dado permiso a la aplicación para que opere dentro del inquilino.

Solicitud de ejemplo

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... En este ejemplo, el inquilino de recursos (autoridad) es contoso.com, la aplicación de recursos es una aplicación de un solo inquilino denominada gateway.contoso.com/api para el inquilino de Contoso y la aplicación cliente es 00001111-aaaa-2222-bbbb-3333cccc4444. Si la aplicación cliente tiene una entidad de servicio en Contoso.com, esta solicitud puede continuar. Si no la tiene, se producirá el error anterior en la solicitud.

Si la aplicación de puerta de enlace de Contoso fuera una aplicación multiinquilino, la solicitud continuaría, sin importar si la aplicación cliente tuviera o no una entidad de servicio en Contoso.com.

Los identificadores URI de redireccionamiento ahora pueden contener parámetros de cadena de consulta.

Fecha efectiva: 22 de julio de 2019

Puntos de conexión afectados: v1.0 y v2.0

Protocolo afectado: Todos los flujos

Por RFC 6749, las aplicaciones de Microsoft Entra ahora pueden registrar y usar URI de redirección (respuesta) con parámetros de consulta estáticos (como https://contoso.com/oauth2?idp=microsoft) para solicitudes de OAuth 2.0. Los identificadores URI de redireccionamiento dinámico siguen estando prohibidos, ya que representan un riesgo de seguridad, y no se pueden usar para conservar la información de estado a través de una solicitud de autenticación; para ello, use el parámetro state.

El parámetro de consulta estático está sujeto a la coincidencia de cadenas para los identificadores URI de redireccionamiento, al igual que cualquier otra parte del URI de redireccionamiento; si no hay ninguna cadena registrada que coincida con el parámetro redirect_uri descodificado con URI, se rechazará la solicitud. Si se encuentra el identificador URI en el registro de la aplicación, se usará toda la cadena para redirigir al usuario, incluido el parámetro de consulta estático.

En este momento (finales de julio de 2019), la experiencia de usuario del registro de aplicaciones en Azure Portal sigue bloqueando los parámetros de consulta. Sin embargo, puede editar el manifiesto de aplicación manualmente para agregar parámetros de consulta y probar este procedimiento en la aplicación.

Marzo de 2019

Se interrumpirán los clientes en bucle

Fecha efectiva: 25 de marzo de 2019

Puntos de conexión afectados: v1.0 y v2.0

Protocolo afectado: Todos los flujos

En ocasiones, las aplicaciones cliente pueden comportarse de manera incorrecta, emitiendo cientos de veces la misma solicitud de inicio de sesión durante un breve período de tiempo. Estas solicitudes pueden completarse satisfactoriamente o no, pero todas contribuyen a una deficiente experiencia para el usuario y a un incremento de las cargas de trabajo para el IDP, lo que aumenta la latencia para todos los usuarios y reduce la disponibilidad del IDP. Estas aplicaciones operan fuera de los límites de uso normal y deben actualizarse para que se comporten correctamente.

A los clientes que emitan solicitudes duplicadas varias veces se les enviará un error invalid_grant: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

La mayoría de los clientes no tendrán que cambiar su comportamiento para evitar este error. Solo los clientes incorrectamente configurados (aquellos sin almacenamiento en caché de tokens o los que ya presentan bucles de mensajes) se verán afectados por este error. Se realiza un seguimiento de los clientes por instancia a nivel local (mediante cookie) sobre los siguientes factores:

• Sugerencia de usuario, si existe

• Ámbitos o recursos solicitados

• Id. de cliente

• URI de redireccionamiento

• Tipo y modo de respuesta

Las aplicaciones que realizan varias solicitudes (más de 15) en un breve período de tiempo (5 minutos) recibirán un error invalid_grant que explica que están en bucle. Los tokens solicitados tienen una vigencia de una duración suficiente (10 minutos como mínimo, 60 minutos de forma predeterminada), por lo que las solicitudes repetidas durante este período de tiempo son innecesarias.

Todas las aplicaciones deben controlar invalid_grant mostrando un aviso interactivo, en lugar de solicitar un token de forma silenciosa. Para evitar este error, los clientes deberían asegurarse de que almacenan en caché correctamente los tokens que reciben.

Octubre de 2018

No se podrán reutilizar los códigos de autorización

Fecha efectiva: 15 de noviembre de 2018

Puntos de conexión afectados: v1.0 y v2.0

Protocolo afectado: flujo de código

A partir del 15 de noviembre de 2018, Microsoft Entra ID dejará de aceptar códigos de autenticación usados previamente para las aplicaciones. Este cambio de seguridad ayuda a poner Microsoft Entra ID en línea con la especificación de OAuth y se aplicará en los puntos de conexión v1 y v2.

Si la aplicación reutiliza códigos de autorización para obtener tokens para varios recursos, es recomendable que use el código para obtener un token de actualización y, a continuación, utilice este para adquirir tokens adicionales para otros recursos. Los códigos de autorización solo se pueden usar una vez, pero los tokens de actualización se pueden usar varias veces en varios recursos. Cualquier nueva aplicación que intente reutilizar un código de autenticación durante el flujo de código de OAuth obtendrá el error invalid_grant.

Para más información acerca de los tokens de actualización, consulte Actualización de los tokens de acceso. Si usa ADAL o MSAL, la biblioteca lo hace, sustituya la segunda instancia de AcquireTokenByAuthorizationCodeAsync por AcquireTokenSilentAsync.

Mayo de 2018

No se pueden usar los tokens de id. para el flujo OBO

Fecha: 1 de mayo de 2018

Puntos de conexión afectados: v1.0 y v2.0

Protocolos afectados: flujo implícito y flujo con derechos delegados

A partir del 1 de mayo de 2018, no se puede utilizar id_tokens como instrucción de aserción en un flujo OBO en las aplicaciones nuevas. En su lugar deben usarse tokens de acceso para proteger las API, incluso entre un cliente y el nivel intermedio de la misma aplicación. Las aplicaciones registradas antes del 1 de mayo de 2018 seguirán funcionando y podrán intercambiar id_tokens por un token de acceso, pero tenga en cuenta que este patrón no se considera un procedimiento recomendado.

Para ofrecer una solución alternativa al problema que pueda provocar este cambio, puede hacer lo siguiente:

1. Cree una API web para la aplicación con uno o más ámbitos. Este punto de entrada explícito le permitirá mayor control y seguridad.
2. En el manifiesto de la aplicación, Azure Portal o el portal de registro de aplicaciones, asegúrese de que la aplicación tiene permiso para emitir tokens de acceso mediante el flujo implícito, lo que se controla mediante la clave oauth2AllowImplicitFlow.
3. Cuando la aplicación cliente solicita un valor de id_token a través de response_type=id_token, también solicita un token de acceso (response_type=token) para la API web creada anteriormente. Por consiguiente, cuando se usa el punto de conexión v2.0 el parámetro scope debe ser similar a api://GUID/SCOPE. En el punto de conexión v1.0, el parámetro resource debe ser el identificador URI de la aplicación de la API web.
4. Pase este token de acceso al nivel intermedio en lugar de id_token.