Tipos de identidad y cuenta para aplicaciones únicas y multiinquilino

2025-05-06

En este artículo se explica cómo, como desarrollador, puede elegir si la aplicación solo permite a los usuarios de su inquilino de Microsoft Entra, cualquier inquilino de Microsoft Entra o usuarios con cuentas personales de Microsoft. Puede configurar la aplicación para que sea de inquilino único o multiinquilino durante el registro de aplicaciones en Microsoft Entra. Asegúrese de seguir el principio de confianza cero de acceso con privilegios mínimos para que la aplicación solo solicite permisos que realmente necesita.

La Plataforma de identidad de Microsoft proporciona compatibilidad con tipos de identidad específicos:

Cuentas profesionales o educativas cuando la entidad tiene una cuenta en un identificador de Microsoft Entra.
Cuentas personales de Microsoft (MSA) para cualquier persona que tenga cuenta en Outlook.com, Hotmail, Live, Skype, Xbox, etc.
Identidades externas en microsoft Entra ID para asociados (usuarios fuera de su organización).

Una parte necesaria del registro de aplicaciones en Microsoft Entra ID es la selección de los tipos de cuenta admitidos. Mientras que los profesionales de TI en roles de administrador deciden quién puede dar su consentimiento a las aplicaciones de su inquilino, usted, como desarrollador, especifique quién puede usar la aplicación en función del tipo de cuenta. Cuando un inquilino no permite registrar la aplicación en Microsoft Entra ID, los administradores le proporcionan una manera de comunicar esos detalles a través de otro mecanismo.

Puede elegir entre las siguientes opciones de tipo de cuenta compatibles al registrar la aplicación.

Accounts in this organizational directory only (O365 only - Single tenant)
Accounts in any organizational directory (Any Azure AD directory - Multitenant)
Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
Personal Microsoft accounts only

Solo las cuentas de este directorio organizativo (inquilino único)

Al seleccionar Solo cuentas en este directorio organizativo (solo O365 - Inquilino único), solo se permiten usuarios e invitados desde el inquilino donde el desarrollador registró su aplicación. Esta opción es la más común para las aplicaciones de línea de negocio (LOB).

Solo cuentas en cualquier directorio organizativo (multiinquilino)

Al seleccionar Cuentas en cualquier directorio organizativo (Cualquier directorio de Microsoft Entra - Multiinquilino), se permite que cualquier usuario de cualquier directorio de Microsoft Entra inicie sesión en la aplicación multiinquilino. Si solo quiere permitir a los usuarios de inquilinos específicos, filtre estos usuarios en el código comprobando que la notificación ordenada en id_token se encuentra en la lista de inquilinos permitidos. La aplicación puede usar el punto de conexión de la organización o el punto de conexión común para iniciar sesión de los usuarios en el inquilino principal del usuario. Para admitir que los usuarios invitados inicien sesión en la aplicación multiinquilino, use el punto de conexión de inquilino específico para el inquilino donde el usuario es un invitado para iniciar sesión en el usuario.

Cuentas en cualquier cuenta profesional y y cuentas personales de Microsoft

Al seleccionar Cuentas en cualquier cuenta profesional y cuentas personales de Microsoft (cualquier directorio de Microsoft Entra : multiinquilino) y cuentas personales de Microsoft (por ejemplo, Skype, Xbox), permite que un usuario inicie sesión en la aplicación con su identidad nativa desde cualquier inquilino o cuenta de consumidor de Microsoft Entra. El mismo filtrado de inquilinos y el uso del punto de conexión se aplican a estas aplicaciones, como lo hacen con las aplicaciones multiinquilino que se describen anteriormente.

Solo cuentas personales de Microsoft

Al seleccionar Solo cuentas personales de Microsoft, permite que solo los usuarios con cuentas de consumidor usen la aplicación.

No depende solo del desarrollador

Mientras define en el registro de aplicación quién puede iniciar sesión en la aplicación, la última indicación procede del usuario individual o de los administradores del inquilino principal del usuario. Los administradores de inquilinos suelen querer tener más control sobre una aplicación, no solo configurar quién puede iniciar sesión. Por ejemplo, es posible que quieran aplicar una directiva de acceso condicional a la aplicación o al control del grupo que permiten usar la aplicación. Para permitir que los administradores de inquilinos tengan este control, hay un segundo objeto en la Plataforma de identidad de Microsoft: la aplicación Enterprise. Las aplicaciones de Enterprise también se conocen como entidades de servicio.

Aplicaciones con usuarios de otros inquilinos u otras cuentas de consumidor

Los tipos de cuenta admitidos incluyen la opción de Cuentas en cualquier directorio organizativo para una aplicación multitenant, de modo que pueda permitir a los usuarios del directorio organizativo. En otras palabras, permite que un usuario inicie sesión en la aplicación con su identidad nativa desde cualquier Microsoft Entra ID. Una entidad de servicio se crea automáticamente en el inquilino cuando el primer usuario de un inquilino se autentica en la aplicación.

Solo hay un registro de aplicación o un objeto de la aplicación. Sin embargo, hay una aplicación empresarial o una entidad de servicio (SP) en cada inquilino que permite a los usuarios iniciar sesión en la aplicación. El administrador de inquilinos puede controlar cómo funciona la aplicación en su inquilino.

Consideraciones sobre la aplicación multiinquilino

Las aplicaciones multiinquilino inician la sesión de los usuarios desde el inquilino principal del usuario cuando la aplicación usa el punto de conexión común o de la organización. La aplicación tiene un registro de aplicación como se muestra en el diagrama siguiente. En este ejemplo, la aplicación se registra en el inquilino de Adatum. El usuario A de Adatum y el usuario B de Contoso pueden iniciar sesión en la aplicación con la expectativa Usuario A de Adatum accede a los datos de Adatum y que el usuario B de Contoso accede a los datos de Contoso.

Como desarrollador, es su responsabilidad mantener la información del inquilino independiente. Por ejemplo, si los datos de Contoso proceden de Microsoft Graph, el usuario B de Contoso solo ve los datos de Microsoft Graph de Contoso. No hay posibilidad de que el usuario B de Contoso acceda a los datos de Microsoft Graph en el inquilino de Adatum, ya que Microsoft 365 tiene una separación de datos real.

En el diagrama, el usuario B de Contoso puede iniciar sesión en la aplicación y puede acceder a los datos de Contoso en la aplicación. La aplicación puede usar los puntos de conexión comunes (u organización) para que el usuario inicie sesión de forma nativa en su inquilino, lo que no requiere ningún proceso de invitación. Un usuario puede ejecutar e iniciar sesión en la aplicación y funciona después de que el usuario o el administrador de inquilinos conceda consentimiento.

Pasos siguientes

Cómo y por qué se agregan aplicaciones a Microsoft Entra ID explica cómo los objetos de aplicación describen una aplicación a Microsoft Entra ID.
Procedimientos recomendados de seguridad para las propiedades de la aplicación en Microsoft Entra ID trata de propiedades, como el URI de redireccionamiento, los tokens de acceso, los certificados y secretos, el identificador URI de la aplicación y la propiedad de la aplicación.
Creación de aplicaciones con un enfoque de confianza cero para la identidad proporciona información general sobre los permisos y los procedimientos recomendados de acceso.
Adquirir autorización para acceder a los recursos le ayuda a comprender cómo garantizar mejor Confianza cero al adquirir permisos de acceso a recursos para la aplicación.
Desarrollar estrategia de permisos delegados le ayuda a implementar el mejor enfoque para administrar permisos en la aplicación y desarrollar mediante principios de confianza cero.
Desarrollar la estrategia de permisos de aplicación le ayuda a decidir sobre el enfoque de permisos de aplicación para la administración de credenciales.