Personalización de inicios de sesión y cierres de sesión en la autenticación de Azure App Service

En este artículo se muestra cómo personalizar los inicios de sesión de usuario y los cierres de sesión al usar la autenticación y autorización integradas en Azure App Service.

Uso de varios proveedores de inicio de sesión

La configuración de Azure Portal no ofrece una manera llave en mano de presentar varios proveedores de inicio de sesión a los usuarios (como Facebook y X). Para agregar la funcionalidad de usar varios proveedores de inicio de sesión a la aplicación:

1. En Azure Portal, en la página Autenticación y autorización, configure cada proveedor de identidades que quiera habilitar.

2. En Acción que se debe realizar cuando la solicitud no está autenticada, seleccione Permitir solicitudes anónimas (sin acción).

3. En la página de inicio de sesión, o en la barra de navegación, o en cualquier otra ubicación de la aplicación, agregue un vínculo de inicio de sesión a cada uno de los proveedores que ha habilitado (/.auth/login/<provider>). Por ejemplo:

   <a href="/.auth/login/aad">Log in with Microsoft Entra</a>
   <a href="/.auth/login/facebook">Log in with Facebook</a>
   <a href="/.auth/login/google">Log in with Google</a>
   <a href="/.auth/login/x">Log in with X</a>
   <a href="/.auth/login/apple">Log in with Apple</a>
   

Cuando el usuario selecciona uno de los vínculos, se abre la página correspondiente para el inicio de sesión.

Para redirigir al usuario a una dirección URL personalizada después del inicio de sesión, use el post_login_redirect_uri parámetro de cadena de consulta. (No confunda este parámetro con el URI de redirección en la configuración del proveedor de identidades.) Por ejemplo, para mover el usuario a /Home/Index después del inicio de sesión, use el código HTML siguiente:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

Uso del inicio de sesión dirigido por el cliente

En un inicio de sesión dirigido por el cliente, la aplicación inicia sesión del usuario en el proveedor de identidades mediante un SDK específico del proveedor. A continuación, el código de aplicación envía el token de autenticación resultante a App Service para su validación (consulte Flujo de autenticación) mediante una solicitud de POST HTTP. Esta propia validación no concede a los usuarios acceso a los recursos de aplicación deseados, pero una validación correcta proporciona a los usuarios un token de sesión que pueden usar para acceder a los recursos de la aplicación.

Para validar el token de proveedor, la aplicación de App Service debe configurarse primero con el proveedor deseado. En tiempo de ejecución, después de recuperar el token de autenticación del proveedor, publique el token en /.auth/login/<provider> para la validación. Por ejemplo:

POST https://<appname>.azurewebsites.net/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

El formato del token varía ligeramente según el proveedor:

Si el token del proveedor se valida correctamente, la API devuelve con un authenticationToken valor en el cuerpo de la respuesta. Este valor es el token de sesión. Para obtener más información sobre las notificaciones de usuario, consulte Trabajar con identidades de usuario en la autenticación de Azure App Service.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Después de tener este token de sesión, puede acceder a los recursos de aplicación protegidos agregando el encabezado X-ZUMO-AUTH a las solicitudes HTTP. Por ejemplo:

GET https://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Cerrar sesión en una sesión

Los usuarios pueden iniciar un cierre de sesión mediante el envío de una solicitud GET al punto de conexión de la aplicación /.auth/logout. La solicitud GET:

• Borra las cookies de autenticación de la sesión actual.
• Elimina los tokens del usuario actual del almacén de tokens.
• Para Microsoft Entra y Google, realiza un cierre de sesión del lado servidor en el proveedor de identidades.

Este es un vínculo de cierre de sesión sencillo en una página web:

<a href="/.auth/logout">Sign out</a>

De forma predeterminada, un cierre de sesión correcto redirige al cliente a la dirección URL /.auth/logout/complete. Puede cambiar la página de redireccionamiento posterior al cierre de sesión agregando el parámetro de consulta post_logout_redirect_uri. Por ejemplo:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Se recomienda codificar el valor de post_logout_redirect_uri.

Al usar direcciones URL completas, la dirección URL debe hospedarse en el mismo dominio o configurarse como una dirección URL de redireccionamiento externa permitida para la aplicación. En el ejemplo siguiente se redirige a una https://myexternalurl.com dirección URL que no está hospedada en el mismo dominio:

GET /.auth/logout?post_logout_redirect_uri=https%3A%2F%2Fmyexternalurl.com

Ejecute el comando siguiente en Azure Cloud Shell:

az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls "https://myexternalurl.com"

Conservar fragmentos de dirección URL

Después de que los usuarios inicien sesión en la aplicación, normalmente quieren redirigirse a la misma sección de la misma página, como /wiki/Main_Page#SectionZ. Sin embargo, dado que fragmentos de dirección URL (por ejemplo, #SectionZ) nunca se envían al servidor, no se conservan de forma predeterminada después de que el inicio de sesión de OAuth finalice y redirija de nuevo a la aplicación. A continuación, los usuarios obtienen una experiencia poco óptima cuando necesitan volver al delimitador deseado. Esta limitación se aplica a todas las soluciones de autenticación del lado servidor.

En la autenticación de App Service, puede conservar los fragmentos de dirección URL en el inicio de sesión de OAuth estableciendo WEBSITE_AUTH_PRESERVE_URL_FRAGMENT en true. Use esta configuración de aplicación en Azure Portal, o puede ejecutar el siguiente comando en Cloud Shell:

az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"

Establecer la sugerencia de dominio para las cuentas de inicio de sesión

Tanto las cuentas de Microsoft como Microsoft Entra permiten a los usuarios iniciar sesión desde varios dominios. Por ejemplo, una cuenta de Microsoft permite outlook.com,live.com, y cuentas de hotmail.com. Microsoft Entra permite cualquier número de dominios personalizados para las cuentas de inicio de sesión. Sin embargo, es posible que quiera acelerar a los usuarios directamente a su propia página de inicio de sesión de Microsoft Entra de marca (por ejemplo, contoso.com).

Para sugerir el nombre de dominio de las cuentas de inicio de sesión, siga estos pasos:

1. En el Explorador de recursos, en la parte superior de la página, seleccione Lectura y escritura.

2. En el panel izquierdo, vaya a suscripciones>subscription-name>resourceGroups>resource-group-name>providers>Microsoft.Web>sites>app-name>config>authsettingsV2.

3. Seleccione Editar.

4. Agregue una matriz loginParameters con un elemento domain_hint:

   "identityProviders": {
       "azureActiveDirectory": {
           "login": {
               "loginParameters": ["domain_hint=<___domain-name>"],
           }
       }
   }
   

5. Seleccione Put.

Esta configuración anexa el domain_hint parámetro de cadena de consulta a la dirección URL de redireccionamiento de inicio de sesión.

Autorización o denegación de usuarios

App Service se encarga del caso de autorización más sencillo (por ejemplo, rechazar solicitudes no autenticadas). Pero es posible que la aplicación requiera un comportamiento de autorización más específico, como limitar el acceso solo a un grupo específico de usuarios.

En determinados casos, debe escribir código de aplicación personalizado para permitir o denegar el acceso al usuario que ha iniciado sesión. En otros casos, App Service o el proveedor de identidades pueden ayudar sin necesidad de cambios en el código.

Nivel de servidor (solo aplicaciones de Windows)

Para cualquier aplicación de Windows, puede definir el comportamiento de autorización del servidor web IIS editando el archivo Web.config. Las aplicaciones Linux no usan IIS y no se pueden configurar a través de Web.config.

1. Ir a https://<app-name>.scm.azurewebsites.net/DebugConsole.

2. En el explorador de los archivos de App Service, vaya a site/wwwroot. Si Web.config no existe, créelo seleccionando +>Nuevo archivo.

3. Seleccione el lápiz Web.config para editar el archivo. Agregue el código de configuración siguiente y, a continuación, seleccione Guardar. Si Web.config ya existe, basta con agregar el <authorization> elemento con todo en él. En el <allow> elemento, agregue las cuentas que desea permitir.

   <?xml version="1.0" encoding="utf-8"?>
   <configuration>
      <system.web>
         <authorization>
           <allow users="user1@contoso.com,user2@contoso.com"/>
           <deny users="*"/>
         </authorization>
      </system.web>
   </configuration>
   

Nivel de proveedor de identidades

El proveedor de identidades podría proporcionar cierta autorización llave en mano. Por ejemplo:

• Puede administrar el acceso de nivel empresarial directamente en Microsoft Entra. Para obtener instrucciones, consulte Eliminación del acceso de usuario a las aplicaciones.
• Para Google, los proyectos de API de Google que pertenecen a una organización se pueden configurar para permitir el acceso solo a los usuarios de su organización. Consulte la página de soporte de Google Administrar clientes OAuth.

Nivel de aplicación

Si alguno de los otros niveles no proporciona la autorización que necesita o si no se admite su plataforma o proveedor de identidades, debe escribir código personalizado para autorizar a los usuarios en función de las notificaciones de usuario.

Contenido relacionado

• Tutorial: Autenticación y autorización de usuarios de extremo a extremo en Azure App Service
• Variables de entorno y configuración de la aplicación para la autenticación