Leer en inglés

Compartir a través de

Configuración de una aplicación de App Service o Azure Functions para usar el inicio de sesión de Microsoft Entra

  • Artículo

Nota

A partir del 1 de junio de 2024, las aplicaciones de App Service recién creadas pueden generar un nombre de host predeterminado único que use la convención de nomenclatura <app-name>-<random-hash>.<region>.azurewebsites.net. Los nombres de aplicación existentes permanecen sin cambios. Por ejemplo:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Para obtener más información, consulte Nombre de host predeterminado único para el recurso de App Service.

Seleccione otro proveedor de autenticación para acceder a él.

En este artículo se muestra cómo configurar la autenticación para Azure App Service o Azure Functions a fin de que la aplicación inicie la sesión de los usuarios con la plataforma de identidad de Microsoft (Microsoft Entra ID) como proveedor de autenticación.

Elección de un inquilino para la aplicación y sus usuarios

Antes de que la aplicación pueda iniciar la sesión de los usuarios, debe registrarla en un inquilino externo o de personal. Si va a hacer que la aplicación esté disponible para invitados empresariales o de los empleados, registre la aplicación en un inquilino de personal. Si la aplicación es para consumidores y clientes empresariales, regístrela en un inquilino externo.

  1. Inicie sesión en Azure Portal y vaya a la aplicación.

  2. En el menú izquierdo de la aplicación, seleccione Configuración>Autenticacióny, a continuación, seleccione Agregar proveedor de identidades.

  3. En la página Agregar un proveedor de identidades, seleccione Microsoft en Proveedor de identidades para iniciar sesión en las identidades de Microsoft y Microsoft Entra.

  4. En Elegir un inquilino para la aplicación y sus usuarios, seleccione Configuración de personal (inquilino actual) para empleados e invitados empresariales o seleccione Configuración externa para consumidores y clientes empresariales.

Elección del registro de aplicaciones

La característica de autenticación de App Service puede crear automáticamente un registro de aplicaciones o puede usar un registro que usted o un administrador de directorios cree de forma independiente.

Cree automáticamente un registro de aplicaciones, a menos que necesite crear uno de forma independiente. Puede personalizar el registro de aplicaciones en el Centro de administración de Microsoft Entra más adelante si quiere.

Las situaciones siguientes son los casos más comunes en los que se puede usar un registro de aplicación existente:

  • La cuenta no tiene permisos para crear registros de aplicaciones en el inquilino de Microsoft Entra.
  • Quiere usar un registro de aplicaciones de un inquilino de Microsoft Entra distinto de aquel en el que se encuentra su aplicación.
  • La opción para crear un nuevo registro no está disponible para las nubes de la administración pública.

Puede crear y usar un nuevo registro de aplicaciones (opción 1) o usar un registro existente creado de forma independiente (opción 2).

Opción 1: Creación de un registro de aplicaciones automáticamente

Use esta opción a menos que necesite crear un registro de aplicación por separado. Puede personalizar el registro de aplicaciones en Microsoft Entra después de crearlo.

Nota

La opción para crear un registro automáticamente no está disponible para las nubes de la administración pública. En su lugar, defina un registro por separado.

  1. Seleccione Crear nuevo registro de aplicaciones.

  2. Escriba el Nombre para el nuevo registro de aplicaciones.

  3. Seleccione el Tipo de cuenta admitido:

    • Inquilino actual: inquilino único. Solo las cuentas de este directorio organizativo. Todas las cuentas de usuario e invitado en su directorio pueden usar su aplicación o API. Utilice esta opción si el público objetivo es interno de la organización.
    • Cualquier directorio de Microsoft Entra: multiinquilino. Cuentas de cualquier directorio organizativo Todos los usuarios con una cuenta profesional o educativa de Microsoft pueden usar la aplicación o API. Estas cuentas incluyen escuelas y empresas que usan Office 365. Use esta opción si la audiencia de destino son clientes empresariales o del sector educativo, así como para habilitar la opción multiinquilino.
    • Cualquier directorio de Microsoft Entra y cuentas personales de Microsoft. Cuentas en cualquier directorio de la organización y cuentas personales de Microsoft (por ejemplo, Skype, Xbox). Cualquier usuario con una cuenta profesional o educativa, o bien con una cuenta Microsoft personal puede usar la aplicación o API, se incluyen los centros educativos y las empresas que usen Office 365, así como las cuentas personales que se usan para iniciar sesión en servicios como Xbox y Skype. Use esta opción para definir como destino el conjunto más amplio de identidades de Microsoft, así como para habilitar la opción multiinquilino.
    • Solo cuentas personales de Microsoft. Cuentas personales que se usan para iniciar sesión en servicios como Xbox y Skype. Use esta opción para definir como destino el conjunto más amplio de identidades de Microsoft.

Puede cambiar el nombre del registro o los tipos de cuenta admitidos más adelante si quiere.

Se crea un secreto de cliente como una configuración de la aplicación con espacios fijos denominada MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Si desea administrar el secreto en Azure Key Vault, puede actualizar esa configuración más adelante para usar referencias de Key Vault.

Opción 2: uso de un registro existente creado por separado

Seleccione:

  • Elegir un registro de aplicación existente en este directorio y seleccionar un registro de aplicación en la lista desplegable.

  • Proporcionar los detalles de un registro de aplicaciones existente y proporcione lo siguiente:

    • Identificador de cliente de la aplicación.
    • Secreto de cliente (recomendado). Valor secreto que utiliza la aplicación para demostrar su identidad al solicitar un token. Este valor se guarda en la configuración de la aplicación como una configuración de la aplicación con espacios fijos denominada MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Si no se establece el secreto de cliente, las operaciones de inicio de sesión del servicio usan el flujo de concesión implícita de OAuth 2.0, que no se recomienda.
    • Dirección URL del emisor, con el formato <authentication-endpoint>/<tenant-id>/v2.0. Reemplace <authentication-endpoint> por el valor de punto de conexión de autenticación específico para el entorno de nube. Por ejemplo, un inquilino personal en Azure global usaría "https://sts.windows.net" como punto de conexión de autenticación.

Si necesita crear manualmente un registro de aplicación en un inquilino del personal, consulte Registro de una aplicación con la plataforma de identidad de Microsoft. Durante el proceso de registro, asegúrese de anotar los valores de identificador de la aplicación (cliente) y el secreto de cliente.

Durante el proceso de registro, en la sección URI de redireccionamiento, seleccione Web para plataforma y escriba <app-url>/.auth/login/aad/callback. Por ejemplo, https://contoso.azurewebsites.net/.auth/login/aad/callback.

Después de la creación, modifique el registro de aplicaciones:

  1. En el panel de navegación izquierdo, seleccione Exponer una API>Agregar>Guardar. Este valor identifica de forma única la aplicación cuando se usa como un recurso, lo que permite solicitar tokens que concedan acceso. El valor es un prefijo para los ámbitos que cree.

    Para una aplicación de un solo inquilino, puede usar el valor predeterminado, que tiene el formato api://<application-client-id>. También puede especificar un URI más legible, como https://contoso.com/api, en función de uno de los dominios comprobados para el inquilino. Para una aplicación multiinquilino, debe proporcionar un URI personalizado. Para obtener más información sobre los formatos aceptados para los URI de id. de aplicación, consulte Procedimientos recomendados de seguridad para las propiedades de la aplicación en Microsoft Entra ID.

  2. Seleccione Agregar un ámbito.

    1. En Nombre de ámbito, escriba user_impersonation.
    2. En Quién puede dar el consentimiento, seleccione Administradores y usuarios si desea permitir que los usuarios consientan este ámbito.
    3. Escriba el nombre del ámbito de consentimiento. Escriba una descripción que desee que los usuarios vean en la página de consentimiento. Por ejemplo, escriba Acceder a <application-name> .
    4. Seleccione la opción Agregar un ámbito.

  3. (Recomendado) Para crear un secreto de cliente:

    1. En la barra de navegación de la izquierda, seleccione Certificados y secretos> Secretos de cliente>Nuevo secreto de cliente.
    2. Escriba una descripción y un tiempo de expiración y seleccione Agregar.
    3. En el campo Valor, copie el valor del secreto de cliente. Después de salir de esta página, no vuelve a aparecer.

  4. (Opcional) Para agregar varios valores en Direcciones URL de respuesta, seleccione Autenticación.

Configuración de comprobaciones adicionales

Comprobaciones adicionales determina qué solicitudes pueden acceder a la aplicación. Puede personalizar este comportamiento ahora o ajustar esta configuración más adelante desde la pantalla principal Autenticación; para ello, elija Editar junto a Configuración de la autenticación.

En Requisito de aplicación cliente, elija si quiere:

  • Permitir solicitudes solo desde esta propia aplicación
  • Permitir solicitudes de aplicaciones cliente específicas
  • Permitir solicitudes desde cualquier aplicación (no recomendado)

En Requisito de identidad, elija si quiere:

  • Permitir solicitudes desde cualquier identidad
  • Permitir solicitudes de identidades específicas

En Requisito de inquilino, elija si quiere:

  • Permitir solicitudes solo desde el inquilino del emisor
  • Permitir solicitudes de inquilinos específicos
  • Usar restricciones predeterminadas en función del emisor

Es posible que la aplicación tenga que tomar otras decisiones de autorización en el código. Para más información, vea Uso de una directiva de autorización integrada.

Configurar los ajustes de autenticación

Estas opciones determinan cómo responde la aplicación a las solicitudes no autenticadas. Las selecciones predeterminadas redirigen todas las solicitudes para iniciar sesión con este nuevo proveedor. Puede cambiar este comportamiento ahora o ajustar esta configuración más adelante desde la pantalla principal Autenticación; para ello, elija Editar junto a Configuración de la autenticación. Para más información, consulte Flujo de autenticación.

En Restringir el acceso, decida si quiere:

  • Requerir autenticación
  • Permitir el acceso no autenticado

En Solicitudes no autenticadas

  • HTTP 302 Redireccionamiento encontrado: opción recomendada para sitios web
  • HTTP 401 No autorizado: opción recomendada para las API
  • HTTP 403 Prohibido
  • HTTP 404 No encontrado

Seleccione Almacén de tokens (recomendado). El almacén de tokens recopila, almacena y actualiza tokens para la aplicación. Puede deshabilitar este comportamiento más adelante si la aplicación no necesita tokens o si necesita optimizar el rendimiento.

Agregar el proveedor de identidades

Si ha seleccionado la configuración de personal, puede seleccionar Siguiente: Permisos y agregue los permisos de Microsoft Graph que necesita la aplicación. Estos permisos se agregan al registro de la aplicación, pero también puede cambiarlos más adelante. Si ha seleccionado la configuración externa, puede agregar permisos de Microsoft Graph más adelante.

  • Seleccione Agregar.

De este modo ya estará listo para usar la plataforma de identidad de Microsoft para realizar la autenticación en la aplicación. El proveedor aparece en la pantalla Autenticación. Desde allí, puede editar o eliminar esta configuración de proveedor.

Para obtener un ejemplo de configuración del inicio de sesión de Microsoft Entra para una aplicación web que accede a Azure Storage y Microsoft Graph, consulte Agregar autenticación de aplicaciones a la aplicación web.

Autorización de solicitudes

De forma predeterminada, la autenticación de App Service solo controla autenticación. Determina si el autor de la llamada es quien dice que son. La autorización, que determina si ese autor de la llamada debería tener acceso a algún recurso, es un paso más allá de la autenticación. Para más información, consulte Conceptos básicos de autorización.

La aplicación puede tomar decisiones de autorización en el código. La autenticación de App Service proporciona algunas comprobaciones integradas, lo que puede ayudar, pero es posible que solo no sean suficientes para cubrir las necesidades de autorización de la aplicación.

Sugerencia

Las aplicaciones multiinquilino deberían validar el identificador del emisor y del inquilino de la solicitud como parte de este proceso para asegurarse de que se permitan los valores. Cuando se configure la autenticación de App Service para un escenario multiinquilino, no validará de qué inquilino procede la solicitud. Es posible que una aplicación tenga que limitarse a inquilinos específicos, en función, por ejemplo, de si la organización se hubiera registrado para el servicio. Consulte Actualizar el código para administrar varios valores de emisor.

Realización de validaciones desde el código de la aplicación

Al realizar comprobaciones de autorización en el código de la aplicación, puede usar la información de notificaciones que la autenticación de App Service pone a disposición. Para obtener más información, consulte Notificaciones de usuario de Access en el código de la aplicación.

El encabezado insertado x-ms-client-principal contiene un objeto JSON codificado en Base64 con las notificaciones declaradas sobre el autor de la llamada. De forma predeterminada, estas notificaciones pasarán por una asignación de notificaciones, por lo que es posible que los nombres de notificación no siempre coincidan con lo que vería en el token. Por ejemplo, la notificación tid se asigna a http://schemas.microsoft.com/identity/claims/tenantid en su lugar.

También puede trabajar directamente con el token de acceso subyacente desde el encabezado insertado x-ms-token-aad-access-token.

Uso de una directiva de autorización integrada

El registro de aplicación creado autentica las solicitudes entrantes para el inquilino de Microsoft Entra. De forma predeterminada, también permite que cualquier usuario del inquilino acceda a la aplicación. Este enfoque es adecuado para muchas aplicaciones. Algunas aplicaciones deben restringir aún más el acceso mediante la toma de decisiones de autorización. El código de la aplicación suele ser la mejor manera de controlar la lógica de autorización personalizada. Sin embargo, en escenarios comunes, la plataforma de identidad de Microsoft proporciona comprobaciones integradas que puede usar para limitar el acceso.

En esta sección se muestra cómo habilitar las comprobaciones integradas con la API de autenticación V2 de App Service. Actualmente, la única manera de configurar estas comprobaciones integradas es mediante plantillas de Azure Resource Manager o la API de REST.

Dentro del objeto de la API, la configuración del proveedor de identidades de Microsoft Entra tiene una validation sección que puede incluir un defaultAuthorizationPolicy objeto como en la siguiente estructura:

JSON 
{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Propiedad Descripción
defaultAuthorizationPolicy Un grupo de requisitos que se deben cumplir para acceder a la aplicación. Se concede acceso basado en una lógica AND sobre cada una de las propiedades configuradas. Cuando allowedApplications y allowedPrincipals están configurados, la solicitud entrante debe cumplir ambos requisitos para poder aceptarse.
allowedApplications Lista de permitidos de la aplicación de cadena identificadores de cliente que representan el recurso cliente que llama a la aplicación. Cuando esta propiedad se configura como una matriz no vacía, solo se aceptan los tokens obtenidos por una aplicación especificada en la lista.

Esta directiva evalúa la notificación appid o azp del token entrante, que debe ser un token de acceso. Consulte Notificaciones de carga.
allowedPrincipals Un grupo de comprobaciones que determinan si la entidad de seguridad representada por la solicitud entrante puede acceder a la aplicación. La satisfacción de allowedPrincipals se basa en una lógica OR sobre las propiedades configuradas.
identities (en allowedPrincipals) Una lista permitida de cadenas identificadores de objetos que representa a los usuarios o aplicaciones que tienen acceso. Cuando esta propiedad se configura como una matriz no vacía, se puede cumplir el requisito allowedPrincipals si se especifica el usuario o la aplicación representados por la solicitud en la lista. Hay un límite de 500 caracteres totales en la lista de identidades.

Esta directiva evalúa la notificación oid del token entrante. Consulte Notificaciones de carga.

Además, algunas comprobaciones se pueden configurar mediante una configuración de la aplicación, independientemente de la versión de API que se use. La configuración de la aplicación WEBSITE_AUTH_AAD_ALLOWED_TENANTS se puede configurar con una lista separada por comas de hasta 10 identificadores de inquilino, por ejemplo, aaaabbbb-0000-cccc-1111-dddd2222eeee.

Esta configuración puede requerir que el token entrante sea de uno de los inquilinos especificados, según lo especificado por la notificación tid. La configuración de la aplicación WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL se puede configurar para true o 1 para requerir que el token entrante incluya una notificación oid. Si allowedPrincipals.identities se ha configurado, esta configuración se omite y se trata como true porque la notificación de oid se comprueba en esta lista proporcionada de identidades.

Las solicitudes que producen errores en estas comprobaciones integradas reciben una respuesta HTTP 403 Forbidden.

Configuración de las aplicaciones cliente para acceder a la instancia de App Service

En la sección anterior, registró la instancia de App Service o Azure Functions para autenticar a los usuarios. En esta sección se explica cómo registrar clientes nativos o aplicaciones de demonio en Microsoft Entra. Pueden solicitar acceso a las API expuestas por App Service en nombre de los usuarios o a sí mismos, como en una arquitectura de N niveles. Si solo desea autenticar a los usuarios, los pasos de esta sección no son necesarios.

Aplicación cliente nativa

Puede registrar clientes nativos para solicitar acceso a las API de la aplicación de App Service en nombre de un usuario que ha iniciado sesión.

  1. En el menú del portal, seleccione Microsoft Entra ID.

  2. En el panel de navegación izquierdo, seleccione Administrar>Registros de aplicaciones y, a continuación, seleccione Nuevo registro.

  3. En la página Register an application (Registrar una aplicación), escriba el nombre del registro de aplicaciones.

  4. En URI de redirección, seleccione cliente público o nativo (móvil y escritorio) y escriba la dirección URL <app-url>/.auth/login/aad/callback. Por ejemplo, https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Seleccione Registrar.

  6. Una vez creado el registro de aplicación, copie el valor de Id. de aplicación (cliente) .

    Nota

    Para una aplicación de Microsoft Store, use el valor de SID del paquete como URI en su lugar.

  7. En el panel de navegación izquierdo, seleccione Administrar>Permisos de API. A continuación, seleccione Agregar un permiso>Mis API.

  8. Seleccione el registro de aplicaciones que creó anteriormente para la aplicación de App Service. Si no ve el registro de la aplicación, asegúrese de agregar el ámbito de user_impersonation en el registro de la aplicación.

  9. En Permisos delegados, seleccione user_impersonation y luego seleccione Agregar permisos.

Ha configurado una aplicación cliente nativa que puede solicitar acceso a la aplicación de App Service en nombre de un usuario.

Aplicación cliente de demonio (llamadas de servicio a servicio)

En una arquitectura de n niveles, la aplicación cliente puede adquirir un token para llamar a un App Service o aplicación de funciones en nombre de la propia aplicación cliente, no en nombre de un usuario. Este escenario es útil para las aplicaciones de demonio no interactivas que realizan tareas sin un usuario que ha iniciado sesión. Usa la concesión de credenciales del cliente OAuth 2.0 estándar. Para obtener más información, consulte La Plataforma de identidad de Microsoft y el flujo de credenciales de cliente de OAuth 2.0.

  1. En el menú Azure Portal, seleccione Microsoft Entra ID.
  2. En el panel de navegación izquierdo, seleccione Administra>Registros de aplicaciones>Nuevo registro.
  3. En la página Register an application (Registrar una aplicación), escriba el nombre del registro de aplicaciones.
  4. En el caso de una aplicación de demonio, no necesita un URI de redireccionamiento para que pueda mantenerlo vacío.
  5. Seleccione Registrar.
  6. Una vez creado el registro de aplicación, copie el valor de Id. de aplicación (cliente) .
  7. En el panel de navegación izquierdo, seleccione Administrar>Certificados y secretos. A continuación, seleccione Secretos de cliente>Nuevo secreto de cliente.
  8. Escriba una descripción y un tiempo de expiración y seleccione Agregar.
  9. En el campo Valor, copie el valor del secreto de cliente. Después de salir de esta página, no vuelve a aparecer.

Ahora puede solicitar un token de acceso mediante el identificador de cliente y el secreto de cliente. Establezca el parámetro resource en el URI de identificador de aplicación de la aplicación de destino. A continuación, el token de acceso resultante se puede presentar a la aplicación de destino mediante el encabezado de autorización estándar OAuth 2.0. La autenticación de App Service valida y usa el token como de costumbre para indicar ahora que el autor de la llamada está autenticado. En este caso, el autor de la llamada es una aplicación, no un usuario.

Este enfoque permite cualquier aplicación cliente en el inquilino de Microsoft Entra para solicitar un token de acceso y autenticarse en la aplicación de destino. Si también desea aplicar autorización para permitir solo determinadas aplicaciones cliente, debe realizar una configuración adicional.

  1. Definir un rol de aplicación en el manifiesto del registro de la aplicación que representa la aplicación App Service o aplicación de funciones que desea proteger.

  2. En el registro de aplicaciones que representa el cliente que debe autorizarse, seleccione Permisos de API>Agregar un permiso>Mis API.

  3. Seleccione el registro de la aplicación que creó anteriormente. Si no ve el registro de la aplicación, asegúrese de que ha agregado un rol de aplicación.

  4. En Permisos de aplicación, seleccione el rol de aplicación que creó anteriormente. Seleccione Agregar permisos.

  5. Asegúrese de seleccionar Conceder consentimiento del administrador para autorizar la aplicación cliente para que solicite el permiso.

    De forma similar al escenario anterior (antes de agregar roles), ahora puede solicitar un token de acceso para el mismo destinoresource, y el token de acceso incluye una notificación de roles que contiene los roles de aplicación autorizados para la aplicación cliente.

Dentro del código de App Service o de aplicación de funciones de destino, ahora puede validar que los roles esperados están presentes en el token. La autenticación de App Service no realiza esta validación. Para más información, consulte Access user claims (Acceso a las notificaciones de usuario).

Ha configurado una aplicación cliente de demonio que puede acceder a la aplicación de App Service mediante su propia identidad.

procedimientos recomendados

Independientemente de la configuración que use para establecer la autenticación, los siguientes procedimientos recomendados mantienen al inquilino y las aplicaciones más seguros:

  • Configure cada aplicación de App Service con su propio registro de aplicaciones en Microsoft Entra.
  • Asigne a cada aplicación de App Service sus propios permisos y consentimiento.
  • Evite el uso compartido de permisos entre entornos. Use registros de aplicaciones independientes para ranuras de implementación independientes. Al probar nuevo código, esta práctica puede ayudar a evitar que los problemas afecten a la aplicación de producción.

Migración a Microsoft Graph

Es posible que algunas aplicaciones anteriores también estén configuradas con una dependencia de Azure AD Graph en desuso, que está programada para la retirada completa. Por ejemplo, el código de la aplicación puede haber llamado a Azure AD Graph para comprobar la pertenencia a grupos como parte de un filtro de autorización en una canalización de middleware. Las aplicaciones deben moverse al Microsoft Graph. Para obtener más información, consulte Migrar las aplicaciones de Azure AD Graph a Microsoft Graph.

Durante esta migración, es posible que tenga que realizar algunos cambios en la configuración de la autenticación de App Service. Después de agregar permisos de Microsoft Graph al registro de la aplicación, puede hacer lo siguiente:

  1. Actualizar la dirección URL del emisor para incluir el sufijo /v2.0 si aún no está incluido.

  2. Quitar las solicitudes de permisos de Azure AD Graph de la configuración de inicio de sesión. Las propiedades que se van a cambiar dependen de la versión de la API de administración que use:

    • Si usa la API V1 (/authsettings), esta configuración se encuentra en la matriz de additionalLoginParams.
    • Si usa la API V2 (/authsettingsV2), esta configuración se encuentra en la matriz de loginParameters.

    Debe quitar cualquier referencia a https://graph.windows.net, por ejemplo. Este cambio incluye el parámetro resource, que no es compatible con el punto de conexión de /v2.0 o cualquier ámbito que solicite específicamente que provena de Azure AD Graph.

    También debe actualizar la configuración para solicitar los nuevos permisos de Microsoft Graph que configuró para el registro de la aplicación. Puede usar el ámbito .default para simplificar esta configuración en muchos casos. Para ello, agregue un nuevo parámetro de inicio de sesión scope=openid profile email https://graph.microsoft.com/.default.

Con estos cambios, cuando la autenticación de App Service intenta iniciar sesión, ya no solicita permisos a Azure AD Graph. En su lugar, obtiene un token para Microsoft Graph. Cualquier uso de ese token del código de la aplicación también debe actualizarse, como se describe en Migrar las aplicaciones de Azure AD Graph a Microsoft Graph.

Pasos siguientes