Personalización del inicio y cierre de sesión en la autenticación de Azure App Service

  • Artículo

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

Uso de varios proveedores de inicio de sesión

La configuración del portal no ofrece una manera preparada para presentar varios proveedores de inicio de sesión a los usuarios (por ejemplo, Facebook y Twitter). Sin embargo, no es difícil agregar la funcionalidad a la aplicación. A continuación se describen los pasos necesarios:

Primero, en la página Autenticación / Autorización de Azure Portal, configure cada uno de los proveedores de identidades que desea habilitar.

En Action to take when request is not authenticated (Acción necesaria cuando la solicitud no está autenticada), seleccione Allow Anonymous requests (no action) (Permitir solicitudes anónimas (sin acción)).

En la página de inicio de sesión, 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 the Microsoft Identity Platform</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/twitter">Log in with Twitter</a>
<a href="/.auth/login/apple">Log in with Apple</a>

Cuando el usuario haga clic en uno de los vínculos, la página de inicio de sesión correspondiente se abrirá para que el usuario inicie sesión.

Para redirigir al usuario después del inicio de sesión a una dirección URL personalizada, use el parámetro de cadena de consulta post_login_redirect_uri (que no debe confundirse con el URI de redireccionamiento den su configuración de proveedor de identidades). Por ejemplo, para redirigir al usuario a /Home/Index después de iniciar sesión, utilice el siguiente código HTML:

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

Inicio de sesión dirigido por el cliente

En un inicio de sesión dirigido por el cliente, la aplicación inicia la sesión del usuario en el proveedor de identidades mediante un SDK específico del proveedor. Luego, el código de la 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 HTTP POST. Esta validación en sí misma no le otorga acceso a los recursos de aplicación que quiere, pero una validación exitosa le dará un token de sesión que puede usar para obtener acceso a los recursos de la aplicación.

Para validar el token del proveedor, la aplicación App Service debe configurarse primero con el proveedor que quiera usar. En el entorno de ejecución, después de recuperar el token de autenticación de su proveedor, publique el token en /.auth/login/<provider> para su 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. Consulte la tabla siguiente para más detalles:

Valor del proveedor Necesario en el cuerpo de la solicitud Comentarios
aad {"access_token":"<access_token>"} Las propiedades id_token, refresh_token y expires_inson opcionales.
microsoftaccount {"access_token":"<access_token>"} o {"authentication_token": "<token>" authentication_token se prefiere a access_token. La propiedad expires_in es opcional.
Al solicitar el token de los servicios Live, solicite siempre el ámbito wl.basic.
google {"id_token":"<id_token>"} La propiedad authorization_code es opcional. Si se proporciona un valor de authorization_code, se agregarán un token de acceso y un token de actualización al almacén de tokens. Cuando se especifica, authorization_code también puede ir acompañado opcionalmente por una propiedad redirect_uri.
facebook {"access_token":"<user_access_token>"} Use un token de acceso de usuario válido de Facebook.
twitter {"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"}

Nota:

El proveedor de GitHub para la autenticación de App Service no admite el inicio de sesión y el cierre de sesión personalizados.

Si el token del proveedor se valida correctamente, la API regresa con un elemento authenticationToken en el cuerpo de la respuesta, que es su token de sesión.

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

Una vez que tenga este token de sesión, puede obtener acceso a los recursos de aplicación protegidos agregando el encabezado X-ZUMO-AUTH a sus solicitudes HTTP. Por ejemplo:

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

Cierre de sesión de 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 hace lo siguiente:

  • 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 ID y Google, realiza un cierre de sesión del servidor en el proveedor de identidades.

A continuación, se muestra un vínculo de cierre de sesión simple en una página web:

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

De forma predeterminada, un cierre de sesión correcto redirige el cliente a la dirección URL /.auth/logout/complete. Puede cambiar la página de redirección del inicio de sesión posterior 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 utilizar direcciones URL completas, la dirección URL debe hospedarse en el mismo dominio o configurarse como una dirección URL de redirección externa permitida para la aplicación. En el ejemplo siguiente, para redirigir a https://myexternalurl.com que no se hospedado en el mismo dominio:

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

Ejecute el siguiente comando en Azure Cloud Shell:

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

Conservación de los fragmentos de dirección URL

Después de que los usuarios inician sesión en la aplicación, normalmente desean redirigirse a la misma sección de la misma página, como /wiki/Main_Page#SectionZ. Sin embargo, dado que los 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 se complete y se redirija a la aplicación. Los usuarios obtienen una experiencia poco óptima cuando necesitan volver a navegar al delimitador deseado. Esta limitación se aplica a todas las soluciones de autenticación del servidor.

En la autenticación de App Service, puede conservar los fragmentos de dirección URL en el inicio de sesión de OAuth. Para ello, establezca un valor de aplicación denominado WEBSITE_AUTH_PRESERVE_URL_FRAGMENT en true. Puede hacerlo el Azure Portal, o simplemente ejecute el siguiente comando en Azure Cloud Shell:

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

Limitación del dominio de cuentas de inicio de sesión

Tanto la cuenta de Microsoft como Microsoft Entra ID le permiten iniciar sesión desde varios dominios. Por ejemplo, Cuenta Microsoft permite cuentas de outlook.com, live.com y hotmail.com. Microsoft Entra ID permite cualquier número de dominios personalizados para las cuentas de inicio de sesión. Sin embargo, puede que quiera acelerar el proceso para que los usuarios accedan directamente a su propia página de inicio de sesión personalizada de Microsoft Entra (por ejemplo, contoso.com). Para sugerir el nombre de dominio de las cuentas de inicio de sesión, siga estos pasos.

  1. En https://resources.azure.com, en la parte superior de la página, seleccione Lectura y escritura.

  2. En el explorador de la izquierda, desplácese hasta suscripciones><subscription-name>resourceGroups><resource-group-name>>proveedores>Microsoft.Web>sitios><app-name>>configuración>authsettingsV2.

  3. Haga clic en Editar.

  4. Agregue una matriz loginParameters con un elemento domain_hint.

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

  5. Haga clic en Put.

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

Importante

Es posible que el cliente quite el parámetro domain_hint después de recibir la dirección URL de redireccionamiento y, a continuación, inicie sesión con otro dominio. Por lo tanto, aunque esta función es cómoda, no es una característica de seguridad.

Autorización o denegación de usuarios

Si bien App Service se encarga del caso de autorización más sencillo (es decir, rechazar las solicitudes no autenticadas), es posible que la aplicación requiera un comportamiento de autorización más específico, como limitar el acceso a un solo grupo específico de usuarios. En algunos casos, debe escribir código de aplicación personalizado para permitir o denegar el acceso al usuario que inició sesión. En otros casos, App Service o el proveedor de identidades pueden ayudar sin necesidad de realizar cambios en el código.

Nivel de servidor (solo aplicaciones de Windows)

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

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

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

  3. Seleccione el lápiz de Web. config para editarlo. Agregue el código de configuración siguiente y haga clic en Guardar. Si ya existe Web.config, simplemente agregue el elemento <authorization> con todo lo que contiene. Agregue las cuentas que desea permitir al elemento <allow>.

    <?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 puede proporcionar cierta autorización llave en mano. Por ejemplo:

Nivel de aplicación

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

Más recursos