Procedimientos: Inicio de sesión de cualquier usuario de Azure Active Directory mediante el patrón de aplicación multiinquilinoHow to: Sign in any Azure Active Directory user using the multi-tenant application pattern

Si ofrece una aplicación de software como servicio (SaaS) a muchas organizaciones, puede configurar la aplicación para que acepte inicios de sesión de cualquier inquilino de Azure Active Directory (Azure AD).If you offer a Software as a Service (SaaS) application to many organizations, you can configure your application to accept sign-ins from any Azure Active Directory (Azure AD) tenant. Esta operación se conoce como convertir una aplicación en multiinquilino.This configuration is called making your application multi-tenant. Los usuarios de cualquier inquilino de Azure AD podrán iniciar sesión en su aplicación después de dar su consentimiento al uso de su cuenta con ella.Users in any Azure AD tenant will be able to sign in to your application after consenting to use their account with your application.

Si tiene una aplicación existente con su propio sistema de cuenta o es compatible con otros tipos de inicio de sesión de otros proveedores de nube, es sencillo agregar el inicio de sesión de Azure AD desde cualquier inquilino.If you have an existing application that has its own account system, or supports other kinds of sign-ins from other cloud providers, adding Azure AD sign-in from any tenant is simple. Solo tiene que registrar la aplicación, agregar el código de inicio de sesión mediante OAuth2, OpenID Connect o SAML e incluir el botón "Iniciar sesión con Microsoft" en la aplicación.Just register your app, add sign-in code via OAuth2, OpenID Connect, or SAML, and put a "Sign in with Microsoft" button in your application.

Nota

En este artículo se da por supuesto que ya está familiarizado con la creación de una aplicación de un solo inquilino para Azure AD.This article assumes you’re already familiar with building a single-tenant application for Azure AD. Si no lo está, comience leyendo una de las guías de inicio rápido en la página principal de la guía para desarrolladores.If you’re not, start with one of the quickstarts on the developer guide homepage.

Para convertir la aplicación en una aplicación multiempresa de Azure AD, siga estos cuatro pasos:There are four steps to convert your application into an Azure AD multi-tenant app:

  1. Actualice el registro de aplicación para que sea multiempresa.Update your application registration to be multi-tenant
  2. Actualice el código para enviar solicitudes al punto de conexión /common.Update your code to send requests to the /common endpoint
  3. Actualice el código para administrar varios valores issuer.Update your code to handle multiple issuer values
  4. Comprenda el consentimiento de administrador y usuario y realice los cambios apropiados en el código.Understand user and admin consent and make appropriate code changes

Vamos a examinar cada paso con detalle.Let’s look at each step in detail. También puede ir directamente al ejemplo de Construcción de una aplicación web SaaS multiinquilino que llama a Microsoft Graph mediante Azure AD y OpenID Connect.You can also jump straight to the sample Build a multi-tenant SaaS web application that calls Microsoft Graph using Azure AD and OpenID Connect.

Actualización del registro para que sea multiempresaUpdate registration to be multi-tenant

De forma predeterminada, los registros de API y de aplicación web en Azure AD son de un solo inquilino.By default, web app/API registrations in Azure AD are single-tenant. Puede convertir el registro en multiinquilino si busca el modificador Tipos de cuenta admitidos en el panel Autenticación del registro de aplicación en Azure Portal y lo establece en Cuentas en cualquier directorio organizativo.You can make your registration multi-tenant by finding the Supported account types switch on the Authentication pane of your application registration in the Azure portal and setting it to Accounts in any organizational directory.

Para que la aplicación pueda convertirse en multiempresa, Azure AD requiere que el URI de id. de aplicación sea único a nivel global.Before an application can be made multi-tenant, Azure AD requires the App ID URI of the application to be globally unique. El URI de id. de aplicación es una de las maneras en que una aplicación se identifica en los mensajes de protocolo.The App ID URI is one of the ways an application is identified in protocol messages. Cuando la aplicación es de un solo inquilino, es suficiente con que el URI de identificador de aplicación sea único en dicho inquilino.For a single-tenant application, it is sufficient for the App ID URI to be unique within that tenant. En el caso de una aplicación multiempresa, debe ser único a nivel global de forma que Azure AD pueda encontrar la aplicación entre todos los inquilinos.For a multi-tenant application, it must be globally unique so Azure AD can find the application across all tenants. El carácter globalmente único viene impuesto por la necesidad de que el URI de id. de aplicación tenga un nombre de host que coincida con un dominio comprobado del inquilino de Azure AD.Global uniqueness is enforced by requiring the App ID URI to have a host name that matches a verified domain of the Azure AD tenant.

De manera predeterminada, las aplicaciones creadas a través de Azure Portal tienen un URI de id. de aplicación único a nivel global establecido durante la creación de la aplicación, pero puede cambiar este valor.By default, apps created via the Azure portal have a globally unique App ID URI set on app creation, but you can change this value. Por ejemplo, si el nombre del inquilino era contoso.onmicrosoft.com, un identificador URI de id. de aplicación válido sería https://contoso.onmicrosoft.com/myapp.For example, if the name of your tenant was contoso.onmicrosoft.com then a valid App ID URI would be https://contoso.onmicrosoft.com/myapp. Si el inquilino tenía el dominio comprobado contoso.com, también sería un URI de id. de aplicación válido https://contoso.com/myapp.If your tenant had a verified domain of contoso.com, then a valid App ID URI would also be https://contoso.com/myapp. Si el URI de id. de aplicación no sigue este patrón, la configuración de una aplicación como multiinquilino dará error.If the App ID URI doesn’t follow this pattern, setting an application as multi-tenant fails.

Actualización del código para enviar solicitudes a /commonUpdate your code to send requests to /common

En una aplicación de un solo inquilino, las solicitudes de inicio de sesión se envían al punto de conexión de inicio de sesión del inquilino.In a single-tenant application, sign-in requests are sent to the tenant’s sign-in endpoint. Por ejemplo, en el caso de contoso.onmicrosoft.com, el punto de conexión sería: https://login.microsoftonline.com/contoso.onmicrosoft.com.For example, for contoso.onmicrosoft.com the endpoint would be: https://login.microsoftonline.com/contoso.onmicrosoft.com. Las solicitudes enviadas al punto de conexión de un inquilino pueden iniciar la sesión de los usuarios (o invitados) de ese inquilino en las aplicaciones de dicho inquilino.Requests sent to a tenant’s endpoint can sign in users (or guests) in that tenant to applications in that tenant.

Con una aplicación multiempresa, la aplicación no sabe de antemano de qué inquilino procede el usuario, así que no puede enviar solicitudes al punto de conexión de uno de los inquilinos.With a multi-tenant application, the application doesn’t know up front what tenant the user is from, so you can’t send requests to a tenant’s endpoint. En su lugar, las solicitudes se envían a un punto de conexión que las multiplexa en todos los inquilinos de Azure AD: https://login.microsoftonline.com/commonInstead, requests are sent to an endpoint that multiplexes across all Azure AD tenants: https://login.microsoftonline.com/common

Cuando la Plataforma de identidad de Microsoft recibe una solicitud en el punto de conexión /common, inicia la sesión del usuario y, como consecuencia, detecta cuál es el inquilino del que procede.When the Microsoft identity platform receives a request on the /common endpoint, it signs the user in and, as a consequence, discovers which tenant the user is from. El punto de conexión /common funciona con todos los protocolos de autenticación compatibles con Azure AD: OpenID Connect, OAuth 2.0, SAML 2.0 y WS-Federation.The /common endpoint works with all of the authentication protocols supported by the Azure AD: OpenID Connect, OAuth 2.0, SAML 2.0, and WS-Federation.

La respuesta de inicio de sesión a la aplicación contiene un token que representa al usuario.The sign-in response to the application then contains a token representing the user. El valor issuer del token indica a una aplicación el inquilino del que procede el usuario.The issuer value in the token tells an application what tenant the user is from. Cuando el punto de conexión /common devuelva una respuesta, el valor issuer del token corresponderá al inquilino del usuario.When a response returns from the /common endpoint, the issuer value in the token corresponds to the user’s tenant.

Importante

El punto de conexión /common no es un inquilino ni un emisor, sino un multiplexador.The /common endpoint is not a tenant and is not an issuer, it’s just a multiplexer. Para tener esto en cuenta, la lógica de la aplicación para validar los tokens debe estar actualizada al utilizar /common.When using /common, the logic in your application to validate tokens needs to be updated to take this into account.

Actualice el código para administrar varios valores issuerUpdate your code to handle multiple issuer values

Las aplicaciones web y las API web reciben y validan los tokens que provienen de la Plataforma de identidad de Microsoft.Web applications and web APIs receive and validate tokens from the Microsoft identity platform.

Nota

Si bien las aplicaciones cliente nativas solicitan y reciben tokens de la Plataforma de identidad de Microsoft, lo hacen para enviarlos a las API, donde se validan.While native client applications request and receive tokens from the Microsoft identity platform, they do so to send them to APIs, where they are validated. Las aplicaciones nativas no validan los tokens de acceso y deben tratarlos como opacos.Native applications do not validate access tokens and must treat them as opaque.

Veamos cómo una aplicación valida los tokens que recibe de la Plataforma de identidad de Microsoft.Let’s look at how an application validates tokens it receives from the Microsoft identity platform. Una aplicación de un solo inquilino normalmente toma un valor de punto de conexión como:A single-tenant application normally takes an endpoint value like:

https://login.microsoftonline.com/contoso.onmicrosoft.com

...y lo usa para crear una dirección URL de metadatos (en este caso, OpenID Connect), como:...and uses it to construct a metadata URL (in this case, OpenID Connect) like:

https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-configuration

para descargar dos trozos esenciales de información que se usan para validar los tokens: las claves de firma del inquilino y el valor issuer.to download two critical pieces of information that are used to validate tokens: the tenant’s signing keys and issuer value.

Cada inquilino de Azure AD tiene un valor issuer único con la forma:Each Azure AD tenant has a unique issuer value of the form:

https://sts.windows.net/31537af4-6d77-4bb9-a681-d2394888ea26/

...donde el valor de GUID es la versión segura de cambio de nombre del id. del inquilino....where the GUID value is the rename-safe version of the tenant ID of the tenant. Si selecciona el vínculo de metadatos anterior para contoso.onmicrosoft.com, puede ver este valor issuer en el documento.If you select the preceding metadata link for contoso.onmicrosoft.com, you can see this issuer value in the document.

Cuando una aplicación de un solo inquilino valida un token, comprueba la firma del token con las claves de firma del documento de metadatos.When a single-tenant application validates a token, it checks the signature of the token against the signing keys from the metadata document. Esta prueba permite asegurarse de que el valor issuer del token coincide con el que se encuentran en el documento de metadatos.This test allows it to make sure the issuer value in the token matches the one that was found in the metadata document.

Como el punto de conexión /common no corresponde a ningún inquilino y no es un emisor, cuando examine el valor issuer en los metadatos de /common tendrá una URL con plantilla en lugar de un valor real:Because the /common endpoint doesn’t correspond to a tenant and isn’t an issuer, when you examine the issuer value in the metadata for /common it has a templated URL instead of an actual value:

https://sts.windows.net/{tenantid}/

Por lo tanto, una aplicación multiempresa no puede validar los tokens simplemente haciendo coincidir el valor issuer de los metadatos con el valor issuer del token.Therefore, a multi-tenant application can’t validate tokens just by matching the issuer value in the metadata with the issuer value in the token. Una aplicación multiempresa necesita una lógica para decidir qué valores issuer son válidos y cuáles no, según la parte del id. de inquilino del valor issuer.A multi-tenant application needs logic to decide which issuer values are valid and which are not based on the tenant ID portion of the issuer value.

Por ejemplo, si una aplicación multiinquilino solo permite el inicio de sesión desde inquilinos específicos que se han registrado para su servicio, debe comprobar el valor issuer o el valor de notificación tid en el token para asegurarse de que el inquilino se encuentra en su lista de suscriptores.For example, if a multi-tenant application only allows sign-in from specific tenants who have signed up for their service, then it must check either the issuer value or the tid claim value in the token to make sure that tenant is in their list of subscribers. Si una aplicación multiempresa solo trata con individuos y no toma ninguna decisión de acceso basada en los inquilinos, puede omitir completamente el valor issuer.If a multi-tenant application only deals with individuals and doesn’t make any access decisions based on tenants, then it can ignore the issuer value altogether.

En los ejemplos de multiinquilino, la validación del emisor está deshabilitada para permitir que cualquier inquilino de Azure°AD inicie sesión.In the multi-tenant samples, issuer validation is disabled to enable any Azure AD tenant to sign in.

Para que un usuario inicie sesión en una aplicación en Azure AD, la aplicación debe estar representada en el inquilino del usuario.For a user to sign in to an application in Azure AD, the application must be represented in the user’s tenant. Esto permite que la organización realice cosas como aplicar directivas únicas cuando los usuarios de su inquilino inician sesión en la aplicación.This allows the organization to do things like apply unique policies when users from their tenant sign in to the application. Para una aplicación de un solo inquilino, este registro es más sencillo; es lo que sucede cuando registra la aplicación en Azure Portal.For a single-tenant application, this registration easier; it’s the one that happens when you register the application in the Azure portal.

Para una aplicación multiempresa, el registro inicial de la aplicación reside en el inquilino de Azure AD utilizado por el desarrollador.For a multi-tenant application, the initial registration for the application lives in the Azure AD tenant used by the developer. Cuando usuarios de otro inquilino inician sesión en la aplicación por primera vez, Azure AD les pide que den su consentimiento a los permisos solicitados por ella.When a user from a different tenant signs in to the application for the first time, Azure AD asks them to consent to the permissions requested by the application. Si aceptan, se crea una representación de la aplicación llamada entidad de servicio en el inquilino del usuario, y el inicio de sesión puede continuar.If they consent, then a representation of the application called a service principal is created in the user’s tenant, and sign-in can continue. También se crea una delegación en el directorio que registra el consentimiento del usuario a la aplicación.A delegation is also created in the directory that records the user’s consent to the application. Para más información sobre los objetos Application y ServicePrincipal de la aplicación y sobre cómo se relacionan entre sí, consulte Objetos de aplicación y de entidad de servicio.For details on the application's Application and ServicePrincipal objects, and how they relate to each other, see Application objects and service principal objects.

Se muestra el consentimiento para aplicaciones de nivel sencillo

Esta experiencia de consentimiento depende de los permisos solicitados por la aplicación.This consent experience is affected by the permissions requested by the application. La Plataforma de identidad de Microsoft admite dos tipos de permisos: solo de aplicación y delegados.The Microsoft identity platform supports two kinds of permissions, app-only and delegated.

  • Un permiso delegado concede a una aplicación la posibilidad de actuar como un usuario que inicia sesión para un subconjunto de las cosas que el usuario puede hacer.A delegated permission grants an application the ability to act as a signed in user for a subset of the things the user can do. Por ejemplo, puede conceder a una aplicación el permiso delegado para leer el calendario del usuario que ha iniciado la sesión.For example, you can grant an application the delegated permission to read the signed in user’s calendar.
  • Un permiso de aplicación se concede directamente a la identidad de la aplicación.An app-only permission is granted directly to the identity of the application. Por ejemplo, puede conceder a una aplicación el permiso de solo aplicación para leer la lista de usuarios de un inquilino, con independencia de quién haya iniciado sesión en la aplicación.For example, you can grant an application the app-only permission to read the list of users in a tenant, regardless of who is signed in to the application.

Algunos permisos pueden tener el consentimiento de un usuario normal, mientras que otros necesitan el del administrador del inquilino.Some permissions can be consented to by a regular user, while others require a tenant administrator’s consent.

Para más información sobre el consentimiento del usuario y del administrador, consulte Configuración del flujo de trabajo de consentimiento del administrador.To learn more about user and admin consent, see Configure the admin consent workflow.

Los permisos de solo aplicación siempre requieren el consentimiento del administrador de inquilinos.App-only permissions always require a tenant administrator’s consent. Si la aplicación solicita un permiso de solo aplicación y un usuario intenta iniciar sesión en la aplicación, aparece un mensaje de error que indica que el usuario no puede dar su consentimiento.If your application requests an app-only permission and a user tries to sign in to the application, an error message is displayed saying the user isn’t able to consent.

Algunos permisos delegados también requieren el consentimiento del administrador de inquilinos.Certain delegated permissions also require a tenant administrator’s consent. Por ejemplo, la posibilidad de reescribir en Azure AD como el usuario que ha iniciado la sesión requiere el consentimiento del administrador de inquilinos.For example, the ability to write back to Azure AD as the signed in user requires a tenant administrator’s consent. Al igual que los permisos de solo aplicación, si un usuario ordinario intenta iniciar sesión en una aplicación que solicita un permiso delegado que requiere el consentimiento del administrador, la aplicación recibe un error.Like app-only permissions, if an ordinary user tries to sign in to an application that requests a delegated permission that requires administrator consent, your application receives an error. Que un permiso requiera el consentimiento del administrador viene determinado por el desarrollador que publica el recurso, y se puede encontrar en la documentación del recurso.Whether a permission requires admin consent is determined by the developer that published the resource, and can be found in the documentation for the resource. La documentación de permisos de Microsoft Graph API indica qué permisos requieren consentimiento del administrador.The permissions documentation for the Microsoft Graph API indicate which permissions require admin consent.

Si la aplicación usa permisos que requieren el consentimiento del administrador, necesita un gesto, como un botón o un vínculo donde el administrador pueda iniciar la acción.If your application uses permissions that require admin consent, have a gesture such as a button or link where the admin can initiate the action. La solicitud que la aplicación envía para esta acción es la solicitud de autorización habitual de OAuth2 o OpenID Connect que también incluye el parámetro de cadena de consulta prompt=admin_consent.The request your application sends for this action is the usual OAuth2/OpenID Connect authorization request that also includes the prompt=admin_consent query string parameter. Una vez que el administrador ha dado su consentimiento y la entidad de servicio se crea en el inquilino del cliente, las posteriores solicitudes de inicio de sesión no necesitan el parámetro prompt=admin_consent.Once the admin has consented and the service principal is created in the customer’s tenant, subsequent sign-in requests do not need the prompt=admin_consent parameter. Dado que el administrador ha decido que los permisos solicitados son aceptables, en adelante no se solicitará consentimiento a ningún otro usuario.Since the administrator has decided the requested permissions are acceptable, no other users in the tenant are prompted for consent from that point forward.

Un administrador de inquilinos puede deshabilitar la posibilidad de que los usuarios normales den su consentimiento a las aplicaciones.A tenant administrator can disable the ability for regular users to consent to applications. Si esta capacidad está deshabilitada, para que la aplicación se use en el inquilino siempre se solicitará el consentimiento del administrador.If this capability is disabled, admin consent is always required for the application to be used in the tenant. Si quiere probar la aplicación con el consentimiento de usuario final deshabilitado, puede encontrar el modificador de configuración en Azure Portal, en la sección Configuración de usuario en Aplicaciones empresariales.If you want to test your application with end-user consent disabled, you can find the configuration switch in the Azure portal in the User settings section under Enterprise applications.

El parámetro prompt=admin_consent también se puede utilizar en las aplicaciones que solicitan permisos que no requieren el consentimiento del administrador.The prompt=admin_consent parameter can also be used by applications that request permissions that do not require admin consent. Un ejemplo de cuándo se debe usar esta opción es en el caso de que la aplicación requiera una experiencia en la que el administrador del inquilino se "registra" una vez, y no se solicita que otros usuarios den su consentimiento a partir de ese momento.An example of when this would be used is if the application requires an experience where the tenant admin “signs up” one time, and no other users are prompted for consent from that point on.

Si una aplicación requiere el consentimiento del administrador y un administrador inicia sesión sin enviar el parámetro prompt=admin_consent, cuando el administrador conceda su consentimiento correctamente a la aplicación, se aplicará solo para su cuenta de usuario.If an application requires admin consent and an admin signs in without the prompt=admin_consent parameter being sent, when the admin successfully consents to the application it will apply only for their user account. Los usuarios normales seguirán sin poder iniciar sesión ni dar su consentimiento a la aplicación.Regular users will still not be able to sign in or consent to the application. Esta característica resulta útil si quiere dar al administrador de inquilinos la posibilidad de explorar la aplicación antes de permitir el acceso a otros usuarios.This feature is useful if you want to give the tenant administrator the ability to explore your application before allowing other users access.

La aplicación puede tener varios niveles, cada uno representado por su propio registro en Azure AD.Your application may have multiple tiers, each represented by its own registration in Azure AD. Por ejemplo, una aplicación nativa que llama a una API web o una aplicación web que llama a una API web.For example, a native application that calls a web API, or a web application that calls a web API. En ambos casos, el cliente (aplicación nativa o aplicación web) solicita permisos para llamar al recurso (API web).In both of these cases, the client (native app or web app) requests permissions to call the resource (web API). Para que la aplicación nativa o la aplicación web se acepten correctamente como inquilinos del cliente, todos los recursos a los que solicitan permisos deben ya existir en el inquilino del cliente.For the client to be successfully consented into a customer’s tenant, all resources to which it requests permissions must already exist in the customer’s tenant. Si no se cumple esta condición, Azure AD devuelve un error indicando que primero se debe agregar el recurso.If this condition isn’t met, Azure AD returns an error that the resource must be added first.

Múltiples niveles en un solo inquilinoMultiple tiers in a single tenant

Esto puede ser un problema si la aplicación lógica consta de dos o más registros de aplicación, por ejemplo, un cliente y un recurso independientes.This can be a problem if your logical application consists of two or more application registrations, for example a separate client and resource. ¿Cómo se convierte primero el recurso en el inquilino del cliente?How do you get the resource into the customer tenant first? Azure AD aborda este caso al habilitar el consentimiento del cliente y del recurso en un solo paso.Azure AD covers this case by enabling client and resource to be consented in a single step. El usuario ve la suma total de los permisos solicitados por el cliente y el recurso en la página de consentimiento.The user sees the sum total of the permissions requested by both the client and resource on the consent page. Para permitir este comportamiento, el registro de la aplicación del recurso debe incluir el identificador de la aplicación del cliente como un elemento knownClientApplications en su manifiesto de aplicación.To enable this behavior, the resource’s application registration must include the client’s App ID as a knownClientApplications in its application manifest. Por ejemplo:For example:

"knownClientApplications": ["94da0930-763f-45c7-8d26-04d5938baab2"]

Esto se demuestra en un ejemplo de llamada a la API web de un cliente nativo de niveles múltiples en la sección Contenido relacionado al final de este artículo.This is demonstrated in a multi-tier native client calling web API sample in the Related content section at the end of this article. En el diagrama siguiente se ofrece información general sobre el consentimiento de una aplicación de niveles múltiples registrada en un solo inquilino.The following diagram provides an overview of consent for a multi-tier app registered in a single tenant.

Se muestra el consentimiento para aplicaciones cliente conocidas de niveles múltiples

Múltiples niveles en varios inquilinosMultiple tiers in multiple tenants

Un caso parecido tiene lugar si los diferentes niveles de una aplicación se registran en distintos inquilinos.A similar case happens if the different tiers of an application are registered in different tenants. Por ejemplo, considere el caso de la creación de una aplicación cliente nativa que llama a la API de Exchange Online.For example, consider the case of building a native client application that calls the Exchange Online API. Para desarrollar la aplicación nativa y, más tarde, para que se ejecute en el inquilino de un cliente, la entidad de servicio de Exchange Online debe existir.To develop the native application, and later for the native application to run in a customer’s tenant, the Exchange Online service principal must be present. En este caso, el desarrollador y el cliente tienen que comprar Exchange Online para que la entidad de servicio se cree en sus inquilinos.In this case, the developer and customer must purchase Exchange Online for the service principal to be created in their tenants.

Si se trata de una API creada por una organización que no sea Microsoft, el desarrollador de la API debe proporcionar una forma de que sus clientes acepten dar su consentimiento a la aplicación en los inquilinos del cliente.If it's an API built by an organization other than Microsoft, the developer of the API needs to provide a way for their customers to consent the application into their customers' tenants. El diseño recomendado tiene la finalidad de que el desarrollador de terceros cree la API de tal forma que también pueda funcionar como un cliente web para implementar el registro.The recommended design is for the third-party developer to build the API such that it can also function as a web client to implement sign-up. Para ello, siga estos pasos:To do this:

  1. Consulte las secciones anteriores para asegurarse de que la API implementa los requisitos de código y el registro de aplicaciones multiempresa.Follow the earlier sections to ensure the API implements the multi-tenant application registration/code requirements.
  2. Además de exponer los roles y ámbitos de la API, asegúrese de que el registro incluye el permiso predeterminado "Iniciar sesión y leer el perfil del usuario".In addition to exposing the API's scopes/roles, make sure the registration includes the "Sign in and read user profile" permission (provided by default).
  3. Implemente una página de inicio de sesión o registro en el cliente web y siga las instrucciones sobre el consentimiento de administrador.Implement a sign-in/sign-up page in the web client and follow the admin consent guidance.
  4. Una vez que el usuario da su consentimiento a la aplicación, se crean los vínculos a la delegación de consentimiento y a la entidad de servicio en el inquilino, y la aplicación nativa puede obtener tokens para la API.Once the user consents to the application, the service principal and consent delegation links are created in their tenant, and the native application can get tokens for the API.

En el diagrama siguiente se ofrece información general sobre el consentimiento de una aplicación de múltiples niveles registrada en diferentes inquilinos.The following diagram provides an overview of consent for a multi-tier app registered in different tenants.

Se muestra el consentimiento para aplicaciones de terceros de niveles múltiples

Los usuarios y administradores pueden revocar el consentimiento a la aplicación en cualquier momento:Users and administrators can revoke consent to your application at any time:

Si un administrador da su consentimiento a una aplicación que incluye a todos los usuarios de un inquilino, los usuarios no pueden revocar el acceso de forma individual.If an administrator consents to an application for all users in a tenant, users cannot revoke access individually. Solo el administrador puede revocar el acceso y solo para la aplicación entera.Only the administrator can revoke access, and only for the whole application.

Aplicaciones multiempresa y almacenamiento en caché de los tokens de accesoMulti-tenant applications and caching access tokens

Las aplicaciones multiempresa también pueden obtener tokens de acceso para llamar a las API que están protegidas por Azure AD.Multi-tenant applications can also get access tokens to call APIs that are protected by Azure AD. Un error común al usar la biblioteca de autenticación de Microsoft (MSAL) con una aplicación multiempresa es solicitar inicialmente un token para un usuario con /common, recibir una respuesta y, luego, solicitar posteriormente un token para ese mismo usuario también mediante /common.A common error when using the Microsoft Authentication Library (MSAL) with a multi-tenant application is to initially request a token for a user using /common, receive a response, then request a subsequent token for that same user also using /common. Dado que la respuesta de Azure AD proviene de un inquilino, y no de /common, MSAL almacena en caché el token como si fuera el inquilino.Because the response from Azure AD comes from a tenant, not /common, MSAL caches the token as being from the tenant. La posterior llamada a /common para obtener un token de acceso para el usuario carece de la entrada de caché, y se pide al usuario que inicie la sesión de nuevo.The subsequent call to /common to get an access token for the user misses the cache entry, and the user is prompted to sign in again. Para evitar la pérdida de la caché, asegúrese de que las posteriores llamadas para un usuario que ya ha iniciado sesión se realizan al punto de conexión del inquilino.To avoid missing the cache, make sure subsequent calls for an already signed in user are made to the tenant’s endpoint.

Pasos siguientesNext steps

En este artículo ha aprendido a crear una aplicación que puede hacer que un usuario inicie sesión desde cualquier inquilino de Azure AD.In this article, you learned how to build an application that can sign in a user from any Azure AD tenant. Después de habilitar el inicio de sesión único (SSO) entre la aplicación y Azure AD, también puede actualizar la aplicación para acceder a las API expuestas por recursos de Microsoft, como Microsoft 365.After enabling Single Sign-On (SSO) between your app and Azure AD, you can also update your application to access APIs exposed by Microsoft resources like Microsoft 365. Esto le permite ofrecer una experiencia personalizada en su aplicación, por ejemplo, que muestre información contextual a los usuarios, como su imagen de perfil o su próxima cita de calendario.This lets you offer a personalized experience in your application, such as showing contextual information to the users, like their profile picture or their next calendar appointment.

Para más información sobre cómo realizar llamadas API a Azure AD y los servicios de Microsoft 365, como Exchange, SharePoint, OneDrive, OneNote, etc., visite Microsoft Graph API.To learn more about making API calls to Azure AD and Microsoft 365 services like Exchange, SharePoint, OneDrive, OneNote, and more, visit Microsoft Graph API.