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

En este artículo se muestra cómo configurar la autenticación para Azure App Service o Azure Functions de modo que la aplicación inicie la sesión de los usuarios con la plataforma de identidad de Microsoft (Azure AD) 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.

Nota

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

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

Esta opción está diseñada para simplificar la autenticación y requiere unos pocos clics.

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

  2. Seleccione Autenticación en el menú de la izquierda. Haga clic en Agregar 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) Haga clic en Siguiente: Permisos y agregue los ámbitos que necesite la aplicación. Estos se agregarán al registro de la aplicación, pero también puede cambiarlos más adelante.

  6. Haga clic en 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 Azure AD 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

También puede registrar manualmente la aplicación en la plataforma de identidad de Microsoft, personalizando el registro y configurando la autenticación de App Service con los detalles de registro. Esto resulta útil, por ejemplo, si quiere usar un registro de aplicaciones de un inquilino de Azure AD diferente de aquel donde está la aplicación.

Creación de un registro de aplicaciones en Azure AD para la aplicación App Service

En primer lugar, creará el registro de la aplicación. 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)
  • URI de Id. de aplicación

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 Azure Active Directory.

  2. En el menú del portal, seleccione Azure Active Directory, vaya a la pestaña Registros de aplicaciones y 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 Web y escriba <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 la aplicación, copie el Id. de aplicación (cliente) y el Id. de directorio (inquilino) para usarlos más adelante.

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

  8. (Opcional) Seleccione Personalización de marca. En URL de página principal, escriba la dirección URL de la aplicación de App Service y seleccione Guardar.

  9. Seleccione Exponer una API y haga clic en Establecer junto a "URI de id. de aplicación". 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.

    El valor se guarda automáticamente.

  10. Seleccione Agregar un ámbito.

    1. En Agregar un ámbito, el URI del identificador de aplicación es el valor que estableció en un paso anterior. Selecciona Guardar y continuar.
    2. En Nombre de ámbito, escriba user_impersonation.
    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.
  11. (Opcional) Para crear un secreto de cliente, seleccione Certificados y secretos>Secretos de cliente>Nuevo secreto de cliente. Escriba una descripción y un tiempo de expiración y seleccione Agregar. Copie el valor del secreto del cliente que se muestra en la página. No se volverá a mostrar.

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

Habilitación de Azure Active Directory en la aplicación de App Service

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

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

  3. Seleccione Microsoft en la lista desplegable del proveedor de identidades.

  4. En App registration type (Tipo de registro de aplicaciones), puede elegir Pick an existing app registration in this directory (Seleccionar in registro de aplicaciones existente en este directorio), que recopilará automáticamente la información necesaria de la aplicación. Si el registro procede de otro inquilino o no tiene permiso para ver el objeto de registro, elija Proporcione los detalles de un registro de aplicación existente. . Para esta opción, tendrá que rellenar los siguientes detalles de configuració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 EasyAuth.
    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 del entorno en la nube (por ejemplo, "https://login.microsoftonline.com" para Azure global), además de reemplazar <tenant-id> por el identificador de directorio (inquilino) en el que se creó el registro de la aplicación. Este valor se usa para redirigir a los usuarios al inquilino de Azure AD 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. Para las aplicaciones que usan Azure AD v1, omita /v2.0 en la dirección URL.
    Audiencias de token permitidas De forma implícita, el Id. de aplicación (cliente) se considera siempre que es un público permitido. Si se trata de una aplicación en la nube o de servidor y desea aceptar tokens de autenticación de una aplicación de App Service cliente (el token de autenticación se puede recuperar en el encabezado X-MS-TOKEN-AAD-ID-TOKEN), agregue aquí el Id. de aplicación (cliente) de la aplicación cliente.

    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. Haga clic en 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.

Validaciones adicionales (opcional)

Los pasos definidos anteriormente le permiten autenticar las solicitudes recibidas en el inquilino de Azure AD. 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 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 Azure Active Directory tiene una valdation sección que puede incluir un defaultAuthorizationPolicy objeto como en la siguiente estructura:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Propiedad Descripción
defaultAuthorizationPolicy Agrupación 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 identificadores de cliente de aplicación de cadena que representan el recurso del cliente que llama a la aplicación. Cuando esta propiedad se configura como una matriz no vacía, solo se aceptarán 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 la referencia de notificaciones de la Plataforma de identidad de Microsoft.
allowedPrincipals Agrupación 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) Lista de permitidos de identificadores de objeto de cadena que representan 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.

Esta directiva evalúa la notificación oid del token entrante. Consulte la referencia de notificaciones de la Plataforma de identidad de Microsoft.

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 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. 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 Azure Portal, seleccione Azure Active Directory>Registros de aplicaciones>Nuevo registro.

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

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

    Nota

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

  4. Seleccione Crear.

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

  6. Seleccione Permisos de API>Agregar permiso>Mis API.

  7. 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 Azure AD para la aplicación App Service.

  8. 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)

La aplicación puede adquirir un token para llamar a una API web hospedada en App Service o la aplicación de funciones en nombre propio (no en el 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 Azure Portal, seleccione Azure Active Directory>Registros de aplicaciones>Nuevo registro.
  2. En la página Register an application (Registrar una aplicación), escriba el nombre del registro de aplicaciones de demonio.
  3. En el caso de una aplicación de demonio, no necesita un URI de redireccionamiento para que pueda mantenerlo vacío.
  4. Seleccione Crear.
  5. Una vez creado el registro de aplicación, copie el valor de Id. de aplicación (cliente) .
  6. Seleccione Certificados y secretos>Nuevo secreto de cliente>Agregar. Copie el valor del secreto del cliente que se muestra en la página. No se volverá a mostrar.

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 o autorización de App Service validarán y usarán 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 Azure AD 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 hacer clic en Conceder consentimiento del administrador para autorizar a la aplicación cliente solicitar 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 función, ahora puede validar que los roles esperados están presentes en el token (esto no se realiza mediante autenticación o autorizació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.

Nota

Los tokens de acceso proporcionados a la aplicación a través de EasyAuth no tienen ámbitos para otras API, como Graph, incluso si la aplicación tiene permisos para acceder a esas API. Para usar estas API, deberá usar Azure Resource Manager para configurar el token devuelto para que se pueda usar para autenticarse en otros servicios. Para más información, consulte Tutorial: Acceso a Microsoft Graph desde una aplicación .NET protegida como usuario.

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:

  • Asigne a cada aplicación de App Service sus propios permisos y consentimiento.
  • Configure cada aplicación de App Service con su propio registro.
  • 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.

Pasos siguientes