Aumento de la resistencia de la autenticación y la autorización en las aplicaciones demonio que se desarrollan
Aprenda a usar la plataforma de identidad de Microsoft y Microsoft Entra ID para aumentar la resistencia de las aplicaciones demonio. Obtenga más información sobre procesos en segundo plano, servicios, aplicaciones de servidor a servidor y aplicaciones sin usuarios.
Vea ¿Qué es la plataforma de identidad de Microsoft?
En el diagrama siguiente se muestra una aplicación de demonio que realiza una llamada a Plataforma de identidad de Microsoft.
Identidades administradas de recursos de Azure
Si va a compilar aplicaciones de demonio en Microsoft Azure, use identidades administradas para recursos de Azure, que controlan secretos y credenciales. Esta característica mejora la resistencia gestionando la expiración, la rotación o la confianza de los certificados.
Consulte Qué son las identidades administradas de recursos de Azure.
Las identidades administradas usan tokens de acceso de larga duración e información de Plataforma de identidad de Microsoft para adquirir nuevos tokens antes de que expiren los tokens. La aplicación se ejecuta al adquirir nuevos tokens.
Las identidades administradas usan puntos de conexión regionales, lo que ayuda a evitar errores fuera de la región mediante la consolidación de las dependencias del servicio. Los puntos de conexión regionales ayudan a mantener el tráfico en un área geográfica. Por ejemplo, si los recursos de Azure están en WestUS2, todo el tráfico permanecerá en WestUS2.
Biblioteca de autenticación de Microsoft
Si desarrolla aplicaciones de demonio y no usa identidades administradas, use la Biblioteca de autenticación de Microsoft (MSAL) para la autenticación y autorización. MSAL facilita el proceso de proporcionar credenciales de cliente. Por ejemplo, la aplicación no necesita crear y firmar aserciones de token web JSON con credenciales basadas en certificados.
Consulte Introducción a la Biblioteca de autenticación de Microsoft (MSAL).
Microsoft.Identity.Web para desarrolladores de .NET
Si desarrolla aplicaciones de demonio en ASP.NET Core, use la biblioteca Microsoft.Identity.Web para facilitar la autorización. Incluye estrategias de caché de tokens distribuidos para las aplicaciones distribuidas que se ejecutan en varias regiones.
Más información:
Almacenamiento y almacenamiento en caché de tokens
Si no usa MSAL para la autenticación y autorización, hay procedimientos recomendados para almacenar y almacenar tokens en caché. MSAL implementa y sigue estos procedimientos recomendados.
Una aplicación adquiere tokens de un proveedor de identidades (IdP) para autorizar a la aplicación a llamar a API protegidas. Cuando la aplicación recibe tokens, la respuesta con los tokens también contiene una propiedad expires\_in que indica a la aplicación durante cuánto tiempo se debe almacenar en caché, y volver a usar, el token. Asegúrese de que las aplicaciones usan la propiedad expires\_in para determinar la duración del token. Confirme que la aplicación no intenta descodificar un token de acceso de API. El uso del token almacenado en caché evita el tráfico innecesario entre la aplicación y la plataforma del Microsoft Identity. Los usuarios inician sesión en la aplicación durante la vigencia del token.
Códigos de error HTTP 429 y 5xx
Use las secciones siguientes para obtener información sobre los códigos de error HTTP 429 y 5xx
HTTP 429
Hay errores HTTP que afectan a la resistencia. Si la aplicación recibe un código de error HTTP 429, Demasiadas solicitudes, Plataforma de identidad de Microsoft está limitando las solicitudes, lo que impide que la aplicación reciba tokens. Asegúrese de que las aplicaciones no intenten adquirir un token hasta que expire el tiempo en el campo de respuesta Retry-After. El error 429 suele indicar que la aplicación no almacena en caché y reutiliza los tokens correctamente.
HTTP 5xx
Si una aplicación recibe un código de error HTTP 5x, no debe entrar en un bucle de reintentos rápidos. Asegúrese de que las aplicaciones esperan hasta que expire el campo Retry-After. Si la respuesta no proporciona ningún encabezado "Retry-After", haga un reintento de retroceso exponencial con el primer reintento al menos 5 segundos después de la respuesta.
Cuando una solicitud agota el tiempo de espera, confirme que las aplicaciones no vuelven a intentarlo de inmediato. Use el reintento de retroceso exponencial citado anteriormente.
Pasos siguientes
- Aumento de la resistencia de la autenticación y la autorización en las aplicaciones cliente que se desarrollan
- Compilación de resistencia en la infraestructura de administración de identidades y acceso
- Aumento de la resistencia en la administración de identidades y acceso de clientes con Azure AD B2C