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

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 para que la aplicación inicie sesión de los usuarios con la plataforma de identidad de Microsoft (Microsoft Entra ID) como proveedor de autenticación.

La característica de autenticación de App Service puede crear automáticamente un registro de aplicaciones con la plataforma de identidad de Microsoft. También es posible usar un registro que el usuario o un administrador de directorios cree por separado.

• Creación de un nuevo registro de aplicaciones automáticamente
• Uso de un registro existente creado por separado

Opción 1: creación de un nuevo 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 ID una vez creado.

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

2. Seleccione Autenticación en el menú de la izquierda. Seleccione Agregar el proveedor de identidades.

3. Seleccione Microsoft en la lista desplegable del proveedor de identidades. La opción para crear un nuevo registro está seleccionada de forma predeterminada. Puede cambiar el nombre del registro o los tipos de cuenta admitidos.

   Se creará un secreto de cliente y se almacenará como una configuración de aplicación con espacios fijos denominada MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Puede actualizar esa configuración más adelante para usar referencias de Key Vault si desea administrar el secreto en Azure Key Vault.

4. Si este es el primer proveedor de identidades configurado para la aplicación, también se mostrará una sección de configuración de autenticación de App Service. De lo contrario, puede pasar al siguiente paso.

   Estas opciones determinan el modo en que la aplicación responde a las solicitudes no autenticadas y las selecciones predeterminadas redirigirán 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 obtener más información acerca de estas opciones, consulte Flujo de autenticación.

5. (Opcional) Seleccione Siguiente: Permisos y agregue los permisos de Microsoft Graph que necesita la aplicación. Estos se agregarán al registro de la aplicación, pero también puede cambiarlos más adelante.

6. 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 se mostrará en la pantalla Autenticación. Desde allí, puede editar o eliminar esta configuración de proveedor.

Para obtener un ejemplo de configuración de inicio de sesión de Microsoft Entra para una aplicación web con acceso a Azure Storage y Microsoft Graph, consulte este tutorial.

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

Puede configurar la autenticación de App Service para usar un registro de aplicaciones existente. 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.

Paso 1: Crear un registro de aplicaciones en Microsoft Entra para la aplicación App Service

Al hacerlo, recopile la siguiente información que necesitará más adelante cuando configure la autenticación en la aplicación App Service:

• Id. de cliente
• Id. de inquilino
• Secreto de cliente (opcional, pero recomendado)
• URI de Id. de aplicación

Las instrucciones para crear un registro de aplicaciones dependen de si usa un inquilino de recursos o un inquilino de cliente. Use las pestañas siguientes para seleccionar el conjunto adecuado de instrucciones para su escenario.

Para registrar la aplicación, lleve a cabo los siguientes pasos:

1. Inicie sesión en Azure Portal, busque y seleccione App Services y luego elija la aplicación. Anote la Dirección URL de la aplicación. La usará para configurar el registro de la aplicación de Microsoft Entra.

2. Vaya al inquilino en el portal:

   • Inquilino de personal
   • Inquilino del cliente

   En el menú del portal, seleccione Microsoft Entra ID. Si el inquilino que usa es diferente del que usa para configurar la aplicación de App Service, primero deberá cambiar los directorios.

3. En la pantalla "Información general", anote el identificador de inquilino, así como el dominio principal.

4. En el panel de navegación izquierdo, seleccione Registros de aplicaciones>Nuevo registro.

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

6. En Tipos de cuenta admitidos, seleccione el tipo de cuenta que puede acceder a esta aplicación.

7. En la sección URI de redirección, seleccione Web para plataforma y escriba <app-url>/.auth/login/aad/callback. Por ejemplo, https://contoso.azurewebsites.net/.auth/login/aad/callback.

8. Seleccione Registrar.

9. Una vez creado el registro de la aplicación, copie el Id. de aplicación (cliente) y el Id. de directorio (inquilino) para usarlos más adelante.

10. En el panel de navegación izquierdo, seleccione Autenticación. En Flujos de concesión implícita e híbridos, habilite Tokens de id. para permitir que el usuario de OpenID Connect inicie sesión desde App Service. Seleccione Guardar.

11. (Opcional) En el panel de navegación izquierdo, seleccione Personalización de marca y propiedades. En URL de página principal, escriba la dirección URL de la aplicación de App Service y seleccione Guardar.

12. 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 recurso, lo que permite solicitar tokens que concedan acceso. Se usa como 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 más información sobre los formatos aceptados para los URI de id. de aplicación, consulte la referencia de procedimientos recomendados de registros de aplicaciones.

13. 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. En los cuadros de texto, escriba el nombre y la descripción del ámbito de consentimiento que quiere que vean los usuarios en la página de consentimiento. Por ejemplo, escriba Acceder a <application-name> .
    4. Seleccione la opción Agregar un ámbito.

14. (Opcional) 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. No se volverá a mostrar una vez que salga de esta página.

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

16. Termine de configurar el registro de aplicación:

    • Inquilino de personal
    • Inquilino del cliente

    No se requieren pasos adicionales para un inquilino personal.

Paso 2: Habilitar Microsoft Entra ID en la aplicación de App Service

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

2. En el panel de navegación izquierdo, seleccione Autenticación>Agregar el proveedor de identidades>Microsoft.

3. Seleccione el tipo de inquilino del registro de la aplicación que creó.

4. Configure la aplicación para usar el registro que creó mediante las instrucciones para el tipo de inquilino adecuado:

   • Inquilino de personal
   • Inquilino del cliente

   Para el Tipo de registro de aplicación, seleccione uno de los siguientes:

   • Seleccione un registro de aplicación existente en este directorio: seleccione un registro de aplicaciones del directorio actual y recopilará automáticamente la información necesaria de la aplicación. El sistema intentará crear un nuevo secreto de cliente en el registro de la aplicación y configurará automáticamente la aplicación para usarla. Se establece una dirección URL de emisor predeterminada en función de los tipos de cuenta admitidos configurados en el registro de la aplicación. Si piensa cambiar este valor predeterminado, consulte la tabla siguiente.
   • Proporcione los detalles de un registro de aplicación existente: especifique los detalles de un registro de aplicación de otro inquilino o si su cuenta no tiene permiso en el inquilino actual para consultar los registros. Para esta opción, es necesario rellenar manualmente los valores de configuración según la tabla siguiente.

   El punto de conexión de autenticación de un inquilino personal debe ser un valor específico para el entorno de nube. Por ejemplo, un inquilino personal en Azure global usaría "https://login.microsoftonline.com" como punto de conexión de autenticación. Anote el valor del punto de conexión de autenticación, ya que será necesario para construir la dirección URL del emisor correcta.

   Al rellenar los detalles de configuración directamente, use los valores recopilados durante el proceso de creación del registro de la aplicación:

   Campo	Descripción
   Id. de aplicación (cliente)	Use el identificador de la aplicación (cliente) del registro de aplicaciones.
   Secreto del cliente	Use el secreto de cliente que generó en el registro de la aplicación. Con un secreto de cliente, se usa el flujo híbrido y el App Service devolverá el acceso y los tokens de actualización. Cuando no se establece el secreto de cliente, se usa el flujo implícito y solo se devuelve un token de identificador. Estos tokens los envía el proveedor y se almacenan en el almacén de tokens de autenticación de App Service.
   Dirección URL del emisor	Use <authentication-endpoint>/<tenant-id>/v2.0 y reemplace <authentication-endpoint> por el punto de conexión de autenticación que determinó en el paso anterior para el tipo de inquilino y el entorno de nube, además de reemplazar <tenant-id> por el identificador de directorio (inquilino) en el que se creó el registro de la aplicación. Para las aplicaciones que usan Azure AD v1, omita /v2.0 en la dirección URL. Este valor se usa para redirigir a los usuarios al inquilino de Microsoft Entra correcto, así como para descargar los metadatos adecuados para determinar las claves de firma de tokens y el valor de notificación del emisor del token correspondientes, por ejemplo. Cualquier configuración distinta de un punto de conexión específico del inquilino se tratará como multiinquilino. En configuraciones multiinquilino, el sistema no realiza ninguna validación del emisor o del identificador del inquilino, y estas comprobaciones deberán controlarse completamente en la lógica de autorización de la aplicación.
   Audiencias de token permitidas	Este campo es opcional. De forma implícita, el Id. de aplicación (cliente) se considera siempre que es un público permitido. Si la aplicación representa una API a la que llamarán otros clientes, también será necesario agregar el URI del identificador de aplicación que configuró en el registro de la aplicación. Hay un límite de 500 caracteres totales en la lista de audiencias permitidas.

   El secreto de cliente se almacenará como una configuración de la aplicación con espacios fijos denominada MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Puede actualizar esa configuración más adelante para usar referencias de Key Vault si desea administrar el secreto en Azure Key Vault.

5. Si este es el primer proveedor de identidades configurado para la aplicación, también se mostrará una sección de configuración de autenticación de App Service. De lo contrario, puede pasar al siguiente paso.

   Estas opciones determinan el modo en que la aplicación responde a las solicitudes no autenticadas y las selecciones predeterminadas redirigirán 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 obtener más información acerca de estas opciones, consulte Flujo de autenticación.

6. 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 se mostrará en la pantalla Autenticación. Desde allí, puede editar o eliminar esta configuración de proveedor.

Autorización de solicitudes

De forma predeterminada, la autenticación de App Service solo controla la autenticación, lo que determinará que el autor de la llamada sea quien dice ser. La autorización, que determina si ese autor de la llamada debería tener acceso a algún recurso, es un paso adicional más allá de la autenticación. Puede obtener más información sobre estos conceptos en Conceptos básicos de autorización de la plataforma de identidad de Microsoft.

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

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, es posible aprovechar la información de notificaciones que la autenticación de App Service pone a disposició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 manera predeterminada, esto permite que cualquier usuario del inquilino acceda a la aplicación, lo que resulta adecuado para muchas aplicaciones. Sin embargo, algunas aplicaciones deben restringir aún más el acceso y se deben tomar 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 a través de las 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:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}

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: "559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc") para requerir que el token entrante provenga 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 en "verdadero" o "1" para requerir que el token entrante incluya una notificación oid. Esta configuración se omitirá y se tratará como verdadero si allowedPrincipals.identities se hubiera configurado (ya que la notificación oid se comprobará con esta lista de identidades proporcionada).

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 aplicaciones de demonio o de cliente nativas en Microsoft Entra ID para que puedan solicitar acceso a las API expuestas por la instancia de App Service en nombre de los usuarios o en su propio nombre, como en una arquitectura de n niveles. No es necesario completar los pasos de esta sección si solo desea autenticar a los usuarios.

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 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 URI de redirección, seleccione Cliente público (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 menú de la izquierda, seleccione Permisos de API>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 aplicación, compruebe que agregó el ámbito user_impersonation en Creación de un registro de aplicaciones en Microsoft Entra ID para la aplicación App Service.

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

Ahora 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.

1. En el menú del portal, seleccione Microsoft Entra ID.
2. En el panel de navegación izquierdo, seleccione 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 la barra de navegación de la izquierda, seleccione Certificados y secretos> 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. No se volverá a mostrar una vez que salga de esta página.

Ahora puede solicitar un token de acceso mediante el Id. de cliente y el secreto de cliente estableciendo el resourceparámetro en el URI del id. de aplicación de la aplicación de destino. Después, 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, y la autenticación de App Service validará y usará el token como de costumbre para indicar ahora que el autor de llamada (una aplicación en este caso, no un usuario) está autenticado.

En la actualidad, esto permite a cualquier aplicación cliente en el inquilino de Microsoft Entra 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. Defina un rol de aplicación en el manifiesto del registro de la aplicación que representa App Service o la aplicación de función que quiere proteger.
2. En el registro de la aplicación que representa el cliente que debe ser autorizado, seleccione Permisos de API>Agregar un permiso>Mis API.
3. Seleccione el registro de aplicaciones 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 y, a continuación, seleccione Agregar permisos.
5. Asegúrese de seleccionar Conceder consentimiento del administrador para autorizar la aplicación cliente para que solicite el permiso.
6. Al igual que en el escenario anterior (antes de que se agregaran los roles), ahora puede solicitar un token de acceso para el mismo destinoresource, y el token de acceso incluirá una roles solicitud que contiene los roles de aplicación que se autorizaron para la aplicación cliente.
7. En el App Service de destino o el código de la aplicación de funciones, ahora puede validar que los roles esperados están presentes en el token (esto no se realiza mediante autenticación de App Service). Para más información, consulte Access user claims (Acceso a las notificaciones de usuario).

Ahora ha configurado una aplicación cliente demonio que puede acceder a la aplicación de App Service con su propia identidad.

Procedimientos recomendados

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

• Configure cada aplicación App Service con su propio registro de aplicaciones en Microsoft Entra ID.
• Asigne a cada aplicación de App Service sus propios permisos y consentimiento.
• Evite el uso compartido de permisos entre entornos mediante registros de aplicación 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 se hayan configurado 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 pasar a Microsoft Graph siguiendo las instrucciones proporcionadas por Microsoft Entra ID como parte del proceso de desuso de Azure AD Graph. En las instrucciones siguientes, es posible que tenga que realizar algunos cambios en la configuración de autenticación de App Service. Una vez que haya agregado los 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), esto estaría en la matriz additionalLoginParams.
   • Si usa la API V2 (/authsettingsV2), esto estaría en la matriz loginParameters.

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

   También tendría que actualizar la configuración para solicitar los nuevos permisos de Microsoft Graph configurados 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 solicitará permisos a Azure AD Graph y, en su lugar, obtendrá un token para Microsoft Graph. Cualquier uso de ese token del código de la aplicación también tendría que actualizarse, según las instrucciones proporcionadas por Microsoft Entra ID.

Pasos siguientes

• Introducción a la autenticación y autorización en App Service.
• Tutorial: Autenticación y autorización de usuarios de extremo a extremo en Azure App Service

• Tutorial: Autenticación y autorización de usuarios en una aplicación web con acceso a Azure Storage y Microsoft Graph
• Tutorial: Autenticación y autorización de usuarios de extremo a extremo en Azure App Service