Trabajo con tokens de OAuth en la autenticación de Azure App Service
En este artículo se muestra cómo trabajar con tokens de OAuth mientras utiliza la autenticación y autorización integradas en App Service.
Recuperación de los tokens en el código de aplicación
Desde el código de servidor, los tokens específicos del proveedor se inyectan en el encabezado de solicitud, por lo que puede acceder a ellos fácilmente. En la siguiente tabla se muestran los posibles nombres de encabezado de token:
| Proveedor | Nombres de encabezados |
|---|---|
| Microsoft Entra | X-MS-TOKEN-AAD-ID-TOKEN X-MS-TOKEN-AAD-ACCESS-TOKEN X-MS-TOKEN-AAD-EXPIRES-ON X-MS-TOKEN-AAD-REFRESH-TOKEN |
| Token de Facebook | X-MS-TOKEN-FACEBOOK-ACCESS-TOKEN X-MS-TOKEN-FACEBOOK-EXPIRES-ON |
X-MS-TOKEN-GOOGLE-ID-TOKEN X-MS-TOKEN-GOOGLE-ACCESS-TOKEN X-MS-TOKEN-GOOGLE-EXPIRES-ON X-MS-TOKEN-GOOGLE-REFRESH-TOKEN |
|
| X | X-MS-TOKEN-TWITTER-ACCESS-TOKEN X-MS-TOKEN-TWITTER-ACCESS-TOKEN-SECRET |
Nota:
Los distintos marcos de lenguaje pueden presentar estos encabezados al código de la aplicación en formatos diferentes, como minúsculas o mayúsculas.
Desde el código de cliente (por ejemplo, una aplicación móvil o JavaScript en el explorador), envíe la solicitud GET HTTP a /.auth/me (el almacén de tokens debe estar habilitado). El JSON devuelto tiene los tokens específicos del proveedor.
Nota
Los tokens de acceso son para acceder a recursos de proveedor, por lo que solo están presentes si se configura el proveedor con un secreto de cliente. Para ver cómo obtener tokens de actualización, consulte Tokens de acceso de actualización.
Actualización de tokens de autenticación
Cuando el token de acceso de su proveedor (no el token de sesión) expire, debe volver a autenticar al usuario antes de volver a usar ese token. Puede evitar la expiración del token mediante la realización de una llamada GET al punto de conexión /.auth/refresh de la aplicación. Cuando se llama, App Service actualiza automáticamente los tokens de acceso en el almacén de tokens para el usuario autenticado. Las solicitudes posteriores para los tokens por código de aplicación obtienen los tokens actualizados. Sin embargo, para que la actualización de token funcione, el almacén de tokens debe contener tokens de actualización para el proveedor. Cada proveedor documenta la manera de obtener tokens de actualización, pero en la lista siguiente se muestra un breve resumen:
Google: anexe un parámetro de cadena de consulta
access_type=offlineen su llamada API/.auth/login/google. Para más información, consulte Tokens de actualización de Google.Facebook: no proporciona tokens de actualización. Los tokens de larga duración expiran en 60 días (vea Facebook Expiration and Extension of Access Tokens (Expiración y extensión de tokens de acceso de Facebook)).
X: los tokens de acceso no expiran (consulte preguntas más frecuentes sobre OAuth).
Microsoft: en https://resources.azure.com, haga lo siguiente:
En la parte superior de la página, seleccione Lectura y escritura.
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.
Haga clic en Editar.
Modifique la siguiente propiedad.
"identityProviders": { "azureActiveDirectory": { "login": { "loginParameters": ["scope=openid profile email offline_access"] } } }Haga clic en Put.
Nota
El ámbito que proporciona un token de actualización es offline_access. Consulte como se usa en Tutorial: Autenticación y autorización de usuarios de extremo a extremo en Azure App Service. App Service ya ha solicitado los demás ámbitos de forma predeterminada. Para información sobre estos ámbitos predeterminados, consulte Ámbitos de conexión de OpenID.
Una vez configurado el proveedor, puede buscar el token de actualización y el tiempo de expiración para el token de acceso en el almacén de tokens.
Para actualizar el token de acceso en cualquier momento, simplemente llame a /.auth/refresh en cualquier lenguaje. El fragmento de código siguiente utiliza jQuery para actualizar los tokens de acceso de un cliente de JavaScript.
function refreshTokens() {
let refreshUrl = "/.auth/refresh";
$.ajax(refreshUrl) .done(function() {
console.log("Token refresh completed successfully.");
}) .fail(function() {
console.log("Token refresh failed. See application logs for details.");
});
}
Si un usuario revoca los permisos concedidos a la aplicación, la llamada a /.auth/me puede producir un error con un respuesta 403 Forbidden. Para diagnosticar errores, compruebe los registros de aplicación para más detalles.
Ampliación del período de gracia de expiración del token de sesión
La sesión autenticada expira después de 8 horas. Después de que expire una sesión autenticada, hay un período de gracia de 72 horas de forma predeterminada. Dentro de este período de gracia, puede actualizar el token de sesión con App Service sin volver a autenticar al usuario. Simplemente puede llamar a /.auth/refresh cuando el token de sesión deje de ser válido y no es necesario que realice un seguimiento usted mismo de la expiración del token. Una vez que transcurra el período de gracia de 72 horas, el usuario debe iniciar sesión de nuevo para obtener un token de sesión válido.
Si 72 horas no es tiempo suficiente para usted, puede ampliar este período de expiración. Extender la expiración durante un período prolongado podría tener implicaciones de seguridad importantes (por ejemplo, cuando un token de autenticación se pierde o roba). Por tanto, debe dejarla en el valor predeterminado de 72 horas o establecer el período de extensión en el valor más pequeño.
Para extender el período de expiración predeterminado, ejecute el siguiente comando en Cloud Shell.
az webapp auth update --resource-group <group_name> --name <app_name> --token-refresh-extension-hours <hours>
Nota
El período de gracia solo se aplica a la sesión autenticada de App Service, no a los tokens de los proveedores de identidades. No hay ningún período de gracia para los tokens del proveedor expirados.