Al desarrollar servicios web, puede que necesite obtener tokens mediante el flujo delegado (OBO) de OAuth 2.0. El flujo delegado (OBO) se usa cuando una aplicación invoca a un servicio o una API web que, a su vez, tiene que llamar a otro servicio u otra API web. OBO propaga la identidad y los permisos del usuario delegado en la cadena de solicitud. Cuando una aplicación necesita usar tokens de acceso y de actualización indefinidamente, normalmente en escenarios de acceso sin conexión, es fundamental almacenar los tokens de actualización de forma segura.
Advertencia
Considere atentamente el riesgo y la responsabilidad que conlleva almacenar los tokens de seguridad, ya que estos tokens pueden conceder a un actor malintencionado acceso a los recursos protegidos por la instancia de Microsoft Entra ID. Una brecha de seguridad de una aplicación que tenga como destino cuentas en cualquier directorio de la organización (cualquier directorio de Microsoft Entra: multiinquilino) puede ser especialmente desastrosa.
El almacenamiento de tokens de acceso supone un riesgo de seguridad mayor, ya que un token de acceso por sí mismo puede acceder a los recursos. El enfoque recomendado es no almacenar los tokens de acceso, sino obtener los tokens de acceso según sea necesario. Almacene de forma segura solo los tokens de actualización, con tanto rigor como si fueran tokens de acceso.
Si es necesario, puede revocar los tokens de actualización si se ponen en peligro.
Posibles casos de uso
Esta solución usa Azure Key Vault, Azure Functions y Azure DevOps para actualizar y almacenar de forma segura los tokens de actualización delegados.
Architecture
Descargue un archivo Visio de esta arquitectura.
Flujo de datos
- Azure Key Vault contiene claves de cifrado secretas para cada inquilino de Microsoft Entra ID.
- Una función Azure Functions desencadenada por temporizador de obtiene la clave secreta más reciente de Key Vault. Otra función de Azure Functions recupera el token de actualización de la Plataforma de identidad de Microsoft y lo guarda con la versión más reciente de la clave secreta.
- Una base de datos almacena la clave cifrada y los datos opacos más recientes.
- Una canalización de entrega continua de Azure DevOps administra y sincroniza los procesos de rotación de los secretos y actualización de los tokens.
Azure Pipelines resulta práctico para agregar la estrategia de rotación de claves si ya usa canalizaciones para la infraestructura como código (IaC) o la integración y entrega continuas (CI/CD). No es necesario usar Azure Pipelines, siempre y cuando limite las rutas de acceso para establecer y recuperar los secretos.
Aplique la siguiente directiva para permitir que la entidad de servicio de la conexión de servicio de Azure DevOps establezca los secretos en Key Vault. Reemplace las variables <Key Vault Name> y <Service Connection Principal> por los valores correctos para su entorno.
az keyvault set-policy --name $<Key Vault Name> --spn $<Service Connection Principal> --secret-permissions set
Después de configurar Azure Pipelines para crear y actualizar las claves, puede programar la ejecución periódica de la canalización. La canalización actualiza el secreto de Key Vault para sincronizar con la rotación de claves y guarda el token cifrado con la nueva versión secreta. Para más información, consulte Configuración de programaciones para las canalizaciones.
Identidad administrada
La manera recomendada de que un servicio de Azure, como Azure Functions, acceda a Key Vault es usar la identidad administrada del servicio. Puede conceder acceso mediante Azure Portal, la CLI de Azure o una plantilla de Azure Resource Manager (ARM) para los escenarios de IaC.
Azure portal
En Azure Portal, agregue una directiva de acceso de Key Vault para permitir que el identificador de objeto de la identidad administrada de Azure Functions pueda obtener y establecer los secretos. Para más información, consulte Adición de una identidad asignada por el sistema y Uso de referencias de Key Vault para App Service y Azure Functions.
Azure CLI
También puede establecer la directiva de Azure Key Vault mediante la CLI de Azure:
az keyvault set-policy --name $<Key Vault Name> --spn $<Service Connection Principal> --secret-permissions set
az keyvault set-policy --name $<Key Vault Name> --spn $<Managed Identity Principal> --secret-permissions get
Plantilla ARM
La siguiente plantilla de ARM proporciona a Azure Functions acceso a Azure Key Vault. Reemplace las variables *** por los valores correctos para su entorno.
{
"type": "Microsoft.KeyVault/vaults",
"apiVersion": "2019-09-01",
"name": "***",
"location": "***",
"properties": {
"sku": {
"family": "A",
"name": "standard"
},
"tenantId": "***",
"enableSoftDelete": true,
"enabledForDeployment": false,
"enabledForTemplateDeployment": false,
"enabledForDiskEncryption": false,
"accessPolicies": [
{
"tenantId": "***",
"objectId": "<Managed Identity Principal>",
"permissions": {
"secrets": [
"get"
]
}
},
{
"tenantId": "***",
"objectId": "<Service Connection Principal>",
"permissions": {
"secrets": [
"set"
]
}
}
]
}
}
Almacenamiento de tokens
Puede usar cualquier base de datos para almacenar los tokens en formato cifrado. En el diagrama siguiente se muestra la secuencia para almacenar tokens de actualización en una base de datos:
La secuencia tiene dos funciones, userId() y secretId(). Puede definir estas funciones como una combinación de token.oid, token.tid y token.sub. Para más información, consulte Uso del id_token.
Con la clave criptográfica almacenada como un secreto, puede buscar la versión más reciente de la clave en Azure Key Vault.
Uso de tokens
El uso de la clave es sencillo. La secuencia siguiente consulta la clave según la versión de la clave más reciente.
La actualización del token es ortogonal a la función DoWork, por lo que Azure Functions puede realizar la llamada a DoWork y la actualización de tokens de forma asincrónica con Durable Functions. Para más información sobre las funciones desencadenadas por HTTP con Durable Functions, consulte Características de HTTP.
No se recomienda usar Azure Key Vault en la canalización de solicitudes HTTP, por lo que debe almacenar en memoria caché las respuestas siempre que sea razonable. En el ejemplo, la respuesta de Key Vault a la llamada a getSecret(secretId, secretVersion) se puede almacenar en memoria caché.
Rotación de claves y actualización de tokens
Puede rotar la clave secreta al mismo tiempo que actualiza el token de actualización, por lo que el token más reciente se cifra con la versión más reciente del secreto de cifrado. Este proceso usa la compatibilidad integrada de Azure Functions con los desencadenadores de temporizador. Para más información, consulte Desencadenador de temporizador de Azure Functions.
En el siguiente diagrama de secuencia se ilustra el proceso de sincronización de la actualización de tokens con la rotación de claves:
Control de acceso y usuarios
La Plataforma de identidad de Microsoft ofrece la capacidad de revocar los tokens de actualización en caso de peligro. Consulte Revocación de tokens y Revoke-AzureADUserAllRefreshToken.
Nota:
Los módulos de PowerShell de Azure AD y MSOnline están en desuso a partir del 30 de marzo de 2024. Para obtener más información, lea la actualización de desuso. Desde esta fecha, el soporte de estos módulos se limita a la asistencia de migración al SDK de PowerShell de Microsoft Graph y a las correcciones de seguridad. Los módulos en desuso seguirán funcionando hasta el 30 de marzo de 2025.
Se recomienda migrar a PowerShell de Microsoft Graph para interactuar con Microsoft Entra ID (anteriormente Azure AD). Para preguntas comunes sobre la migración, consulte las Preguntas más frecuentes sobre migración. Nota: Las versiones 1.0.x de MSOnline podrían experimentar interrupciones después del 30 de junio de 2024.
Para quitar un usuario de Microsoft Entra ID, basta con quitar el registro del usuario. Para eliminar el acceso a la aplicación por usuario, elimine la parte refreshToken de los datos del usuario.
Para eliminar el acceso de un grupo de usuarios, como todos los usuarios de un inquilino de destino, puede usar Azure Pipelines para eliminar el secreto del grupo en función de secretId().
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Jason Mostella | Ingeniero de software sénior