Compartir a través de

Procedimientos recomendados y recomendaciones de la plataforma de identidad de Microsoft

  • Artículo

En este artículo se resaltan los procedimientos recomendados, las recomendaciones y los descuidos más comunes en la integración con la plataforma de identidad de Microsoft. Esta lista de comprobación le guía hacia una integración segura y de alta calidad. Revise esta lista periódicamente para asegurarse de que mantiene la calidad y la seguridad de la integración de la aplicación con la plataforma de identidad. La lista de comprobación no está pensada para revisar toda la aplicación. El contenido de la lista de comprobación está sujeto a cambios a medida que introducimos mejoras en la plataforma.

Si acaba de empezar, consulte la documentación de la plataforma de identidad de Microsoft para información sobre aspectos básicos de la autenticación, escenarios de aplicación en la plataforma de identidad de Microsoft y mucho más.

Utilice la siguiente lista de comprobación para asegurarse de que su aplicación está efectivamente integrada con la plataforma de identidad de Microsoft.

Sugerencia

El Asistente de integración puede ayudarle a aplicar muchos de estos procedimientos recomendados y recomendaciones. Seleccione cualquiera de los registros de aplicaciones y, a continuación, seleccione el elemento de menú Asistente de integración para empezar a usar el asistente.

Conceptos básicos

checkbox Lea y comprenda las directivas de la plataforma de Microsoft. Asegúrese de que la aplicación se adhiere a los términos descritos, ya que están pensados para proteger a los usuarios y a la plataforma.

Propiedad

checkbox Asegúrese de que la información asociada con la cuenta que ha usado para registrar y administrar las aplicaciones está actualizada.

Personalización de marca

checkbox Siga las directrices de personalización de marca para aplicaciones.

checkbox Proporcione un nombre significativo y un logotipo para la aplicación. Esta información aparece en la petición de consentimiento de la aplicación. Asegúrese de que el nombre y el logotipo son representativos de su producto y empresa para que los usuarios puedan tomar decisiones informadas. Asegúrese de que no infringen ninguna marca comercial.

Privacidad

checkbox Proporcione los vínculos a los términos del servicio y la declaración de privacidad de la aplicación.

Seguridad

checkbox Administrar los URI de redirección:

  • Mantenga la propiedad de todos los URI de redireccionamiento y mantenga actualizados los registros DNS de los mismos.
  • No utilice caracteres comodín (*) en los URI.
  • Para las aplicaciones web, asegúrese de que todos los URI son seguros y están cifrados (por ejemplo, mediante esquemas de https).
  • Para los clientes públicos, utilice los URI de redireccionamiento específicos de la plataforma si es aplicable (sobre todo para iOS y Android). En caso contrario, use el URI de redireccionamiento con una gran cantidad de aleatoriedad para evitar conflictos cuando llame de nuevo a la aplicación.
  • Si se utiliza la aplicación desde un agente web aislado, puede usar https://login.microsoftonline.com/common/oauth2/nativeclient.
  • Revise y recorte todos los identificadores URI de redirección que no se usen o que sean innecesarios de manera regular.

checkbox Si la aplicación se registra en un directorio, minimice y supervise manualmente la lista de propietarios del registro de aplicaciones.

checkbox No habilite la compatibilidad con el flujo de concesión implícita de OAuth2 a menos que se requiera de forma explícita. Más información sobre el escenario válido aquí.

checkbox Prescinda del nombre de usuario/contraseña. No use el flujo de credenciales de la contraseña de propietario del recurso (ROPC), que controla directamente las contraseñas de usuario. Este flujo requiere un alto grado de confianza y exposición del usuario, por lo que solo se debería usar cuando no se puedan usar otros flujos más seguros. Este flujo todavía es necesario en algunos escenarios (como DevOps), pero tenga en cuenta que su uso impondrá restricciones a la aplicación. Para conocer enfoques más modernos, lea Flujos de autenticación y escenarios de aplicaciones.

checkbox Proteja y administre sus credenciales de aplicación confidenciales para aplicaciones web, API web y aplicaciones de demonio. Utilice las credenciales del certificado, no las credenciales de la contraseña (secretos de cliente). Si debe utilizar una credencial de contraseña, no la configure manualmente. No almacene las credenciales en el código o en la configuración y nunca permita que las manipulen los seres humanos. Si es posible, utilice identidades administradas para los recursos de Azure o Azure Key Vault para almacenar y cambiar periódicamente las credenciales.

checkbox Asegúrese de que la aplicación solicite permisos con privilegios mínimos. Solo pida los permisos que la aplicación necesita absolutamente y únicamente cuando los necesite. Comprenda los diferentes tipos de permisos. Use únicamente los permisos de aplicación si es necesario; utilice permisos delegados siempre que sea posible. Para obtener una lista completa de los permisos de Microsoft Graph, consulte esta referencia sobre los permisos.

checkbox Si protege una API mediante la plataforma de identidad de Microsoft, piense detenidamente en los permisos que debería exponer. Considere cuál es la granularidad correcta para la solución y qué permisos requieren el consentimiento del administrador. Compruebe los permisos esperados en los tokens entrantes antes de tomar cualquier decisión de autorización.

Implementación

checkbox Utilice soluciones de autenticación modernas (OAuth 2.0, OpenID Connect) para iniciar sesión de forma segura.

checkbox No programe directamente con protocolos como OAuth 2.0 y Open ID. En su lugar, aproveche la biblioteca de autenticación de Microsoft (MSAL). Las bibliotecas MSAL encapsulan los protocolos de seguridad de forma segura en una biblioteca fácil de usar, y se obtiene compatibilidad integrada con escenarios de acceso condicional e inicio de sesión único (SSO) en todo el dispositivo, así como compatibilidad integrada con el almacenamiento en caché de tokens. Para obtener más información, consulte la lista de bibliotecas de cliente compatibles con Microsoft. Si debe codificar manualmente los protocolos de autenticación, debe seguir SDL de Microsoft o una metodología de desarrollo similar. Preste mucha atención a las consideraciones de seguridad en las especificaciones de estándares para cada protocolo.

checkbox NO mire el valor del token de acceso ni intente analizarlo como cliente. Pueden cambiar de valor o formato, o incluso cifrarse sin previo aviso: si el cliente necesita saber algo sobre el usuario, use siempre el token de id. Solo las API web deben analizar los tokens de acceso (ya que son las que definen el formato y la configuración de las claves de cifrado). El envío de un token de acceso directamente a una API por parte del cliente es un riesgo para la seguridad, ya que son credenciales confidenciales que conceden acceso a determinados recursos. Los desarrolladores no deben dar por sentado que se puede confiar en el cliente para validar el token de acceso.

checkbox Migre las aplicaciones existentes de la Biblioteca de autenticación de Azure Active Directory (ADAL) a la Biblioteca de autenticación de Microsoft. MSAL es la solución de plataforma de identidad más reciente de Microsoft y está disponible en .NET, JavaScript, Android, iOS, macOS, Python y Java. Conozca mejor cómo migrar ADAL.NET y ADAL.js, y las aplicaciones de ADAL.NET y de agente iOS.

checkbox En el caso de las aplicaciones móviles, configure cada plataforma con la experiencia de registro de aplicaciones. Para que la aplicación pueda aprovechar las ventajas de Microsoft Authenticator o del Portal de empresa de Microsoft para el inicio de sesión único, debe tener configurado un "URI de redirección del agente". De esta manera, Microsoft puede devolver el control a la aplicación después de la autenticación. Al configurar cada plataforma, la experiencia de registro de aplicaciones le guía por el proceso. Use el inicio rápido para descargar un ejemplo práctico. En iOS, use los agentes y la vista web siempre que sea posible.

checkbox En aplicaciones web o API web, mantenga una caché de tokens por cada cuenta. En el caso de las aplicaciones web, la caché de tokens debe estar protegida con clave mediante el identificador de cuenta. En el caso de las API web, la cuenta debe estar protegida con clave mediante el hash del token usado para llamar a la API. MSAL.NET proporciona serialización de caché de tokens personalizada en .NET y .NET Framework. Por motivos de seguridad y rendimiento, se recomienda serializar una caché por cada usuario. Para más información, lea sobre la serialización de la caché de tokens.

checkbox Si los datos que necesita la aplicación están disponibles con Microsoft Graph, solicite permisos para estos datos mediante el punto de conexión de Microsoft Graph en lugar de la API individual.

Experiencia del usuario final

checkbox Conozca la experiencia de consentimiento y configure las partes de la petición de consentimiento de su aplicación para que tanto los usuarios finales como los administradores tengan suficiente información para determinar si confían en su aplicación.

checkbox Minimice el número de veces que un usuario necesita especificar las credenciales de inicio de sesión mientras utiliza la aplicación al intentar la autenticación silenciosa (adquisición de tokens silenciosos) antes de los flujos interactivos.

casilla No use "prompt=consent" en cada inicio de sesión. Solo utilice prompt=consent si ha determinado que necesita pedir consentimiento para obtener permisos adicionales (por ejemplo, si ha cambiado los permisos necesarios de la aplicación).

checkbox Si procede, enriquezca su aplicación con datos de usuario. Usar Microsoft Graph API es una forma fácil de hacerlo. La herramienta Probador de Graph que le ayudará a empezar.

checkbox Registre el conjunto completo de permisos que la aplicación requiere para que los administradores puedan otorgar el consentimiento fácilmente al inquilino. Utilice el consentimiento incremental en tiempo de ejecución para ayudar a los usuarios a comprender por qué la aplicación está solicitando permisos que pueden afectar o confundir a los usuarios cuando se solicitan al iniciar la aplicación por primera vez.

checkbox Implemente una experiencia de cierre de sesión único limpia. Es un requisito de privacidad y seguridad, y contribuye a una buena experiencia de usuario.

Prueba

casilla Compruebe si hay directivas de acceso condicional que puedan afectar a la capacidad de los usuarios para utilizar la aplicación.

checkbox Pruebe la aplicación con todas las cuentas posibles que piensa admitir (por ejemplo, cuentas profesionales o educativas, cuentas personales de Microsoft, cuentas secundarias y cuentas soberanas).

Recursos adicionales

Explore la información detallada acerca de la versión 2.0: