UMA 2.0: autorización gestionada por el usuario
UMA (User-Managed Access) 2.0 es un perfil sobre OAuth 2.0 que permite a una persona autorizar el acceso de otra persona a sus recursos mediante políticas propias. Resuelve el caso que OAuth original ignora, donde el resource owner y el requesting party son entidades distintas. Ocupa un nicho entre OAuth plano, los modelos ReBAC modernos y los emergentes wallets de identidad descentralizada.
Este artículo forma parte de la serie La evolución de la seguridad en aplicaciones modernas.
OAuth 2.0 es, a pesar de su nombre, un framework de delegación de acceso: una persona autoriza a una aplicación a actuar en su nombre sobre recursos propios. El modelo funciona cuando el resource owner y el usuario que inicia sesión en el cliente son la misma persona, pero se rompe en cuanto aparece un tercero. UMA (User-Managed Access) 2.0 es la respuesta de la Kantara Initiative a ese hueco, y vive desde 2017 como un perfil de OAuth que formaliza el caso “yo comparto algo mío contigo”.
Por qué existe UMA 2.0
El caso canónico es cotidiano fuera del software: compartir un informe médico con un familiar, dar acceso puntual a un asesor fiscal a una declaración, permitir a un cuidador consultar los datos de un paciente. En todos, el dueño del recurso no está presente en el flujo de acceso y el solicitante no es una aplicación actuando en nombre del dueño, sino otra persona con sus propias credenciales. OAuth puro obliga a modelar este escenario como si el solicitante fuera “la aplicación del dueño”, lo cual falsea la auditoría y obliga a compartir credenciales o a inventar cuentas técnicas.
UMA aporta tres ideas que OAuth no tenía. La primera es separar al resource owner del requesting party como ciudadanos de primera clase en el protocolo. La segunda es permitir que las políticas de acceso residan en el authorization server y sean definidas por el dueño del recurso, no por el desarrollador de la aplicación mediante scopes fijos. La tercera es introducir una fase de negociación asíncrona: el solicitante puede pedir acceso antes de tener permiso, y el authorization server decide recopilando claims del requesting party y evaluando políticas del owner.
UMA 1.0 salió en 2015 y resultó demasiado compleja en la práctica. La versión 2.0 simplificó el modelo, alineó la terminología con OAuth 2.0 y OpenID Connect y redujo el número de endpoints, manteniendo las mismas capacidades. Hoy cuando se dice UMA se habla de UMA 2.0.
Cómo funciona el modelo
UMA 2.0 define cinco roles. El Resource Owner (RO) es la persona que posee los recursos y define quién puede acceder. El Resource Server (RS) los aloja, por ejemplo una historia clínica electrónica o una plataforma de almacenamiento. El Authorization Server (AS) mantiene el registro de recursos y las políticas del RO, y emite tokens. El Client es la aplicación que usa el Requesting Party (RqP), la persona distinta del RO que intenta acceder.
El flujo se descompone en cuatro fases. En la primera, Resource Registration, el RS registra cada recurso protegido en el AS con un identificador y un conjunto de scopes posibles. Este paso es previo y ocurre cuando el RS conoce el recurso, no cuando alguien intenta acceder.
En la segunda, el Client intenta acceder al RS sin token válido y recibe una respuesta 401 con un Permission Ticket emitido por el AS, más la URL del AS. El ticket es opaco para el cliente y representa el intento de acceso a un recurso concreto con unos scopes concretos.
En la tercera fase, el Client acude al AS con el Permission Ticket y solicita un RPT (Requesting Party Token). El AS exige que el RqP se autentique, normalmente mediante OpenID Connect contra un claims provider, y obtiene claims sobre su identidad: correo verificado, pertenencia a un grupo, relación familiar declarada, nivel de garantía del proveedor de identidad. El AS evalúa entonces las políticas que el RO ha definido previamente sobre ese recurso; políticas que pueden ser tan simples como “cualquiera con este correo” o tan complejas como “médicos del hospital X durante la próxima hora”.
Si la evaluación tiene éxito, el AS emite el RPT y el cliente lo presenta al RS, que lo valida y sirve el recurso. Si faltan claims, el AS responde con un need_info que lista qué le falta, y el cliente puede proporcionarlos iterativamente. Esta conversación por pasos es lo que permite flujos donde el RqP no estaba autenticado al iniciar la petición.
Diferencia con OAuth plano
En OAuth, los scopes son acordados entre el desarrollador del cliente y el del resource server. El usuario consiente un paquete predefinido. En UMA, el RO define sus propias reglas sobre recursos individuales y puede cambiarlas sin tocar el código del cliente ni del servidor. Donde OAuth ofrece delegación estática, UMA ofrece autorización dinámica definida por el dueño.
Integración con OpenID Connect
UMA 2.0 no define cómo se autentica al requesting party; delega esa tarea. La práctica habitual es usar OpenID Connect para que el AS recoja un ID Token del RqP y extraiga claims. Esto permite reutilizar IdP corporativos, sociales o federados y separa claramente la identidad de la autorización, que es el punto del protocolo.
Cuándo sí tiene sentido
UMA encaja donde hay un modelo real de compartición persona a persona con políticas que el propio usuario necesita controlar y que la plataforma no puede codificar de antemano. El ejemplo más claro es la sanidad: sistemas de historia clínica en los que el paciente decide qué profesional, durante qué periodo y sobre qué categoría de datos puede consultar. Varios proyectos de eHealth en Europa, especialmente en el norte, han experimentado con UMA como capa de consentimiento paciente-céntrico.
Otro terreno natural son las finanzas personales compartidas, donde un titular delega a un asesor o a un familiar el acceso a cuentas agregadas con granularidad fina. El ecosistema emergente de wallets de identidad autosoberana también mira a UMA como un protocolo compatible para compartir verifiable credentials con verificadores bajo políticas del holder.
La Kantara Initiative mantiene el grupo CIS (Consent & Information Sharing), que usa UMA como base para discutir consent receipts y compartición persistente.
UMA brilla cuando la política la escribe el dueño del dato, cuando las reglas son específicas de cada recurso y cuando se necesita auditoría clara del consentimiento. Si esas tres condiciones no se dan, añade complejidad sin beneficio.
Cuándo no compensa
Para la mayoría de aplicaciones SaaS, UMA es sobreingeniería. Cuando la compartición la gestiona la propia plataforma con su modelo interno (listas de colaboradores, roles por workspace, enlaces compartidos) la lógica vive en el resource server y OAuth plano basta para que la aplicación actúe en nombre del usuario. No hay tercera parte con identidad propia que necesite tokens diferenciados.
El modelo ReBAC, descrito en literatura como OpenFGA o SpiceDB, cubre parte del mismo espacio con un planteamiento distinto: en lugar de un AS con políticas declarativas del usuario, se modelan relaciones (documento compartido con usuario X con rol editor) y se consultan en tiempo real. Para aplicaciones modernas tipo productividad, ReBAC ha ganado la conversación porque integra mejor con el modelo de datos de la aplicación.
Otro freno es operativo. UMA multiplica los endpoints, introduce la noción de Permission Ticket que el cliente debe manejar y exige un AS capaz de almacenar y evaluar políticas definidas por usuarios, no solo validar credenciales de clientes. Pocos productos comerciales lo implementan bien, siendo Keycloak uno de los pocos con soporte decente fuera de actores especializados. Ese ecosistema pobre realimenta la falta de adopción.
Por último, aplicaciones donde un scope estático más un esquema de permisos en el resource server es suficiente, no ganan nada adoptando UMA. Si ninguna política del dueño va a cambiar dinámicamente y el universo de peers es acotado, el coste de adopción supera los beneficios.
Encaje en el ecosistema
UMA convive con piezas adyacentes en vez de competir con ellas. Usa OAuth 2.0 como base, se apoya en OpenID Connect para identidad del requesting party y puede integrarse con Token Exchange cuando el cliente necesita convertir credenciales entre dominios. En arquitecturas de identidad descentralizada, UMA puede actuar como el plano de políticas sobre el que se comparten verifiable credentials, complementando modelos de CIAM orientados a consumidor. Y cuando una decisión de acceso debe ser revocada en cascada, CAEP y Shared Signals ofrecen la propagación que UMA por sí sola no resuelve.
Artículos relacionados en esta serie
Referencias
- Kantara Initiative (enero 2018). Federated Authorization for User-Managed Access (UMA) 2.0.
- Kantara Initiative (enero 2018). User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization.
- RFC 6749 (octubre 2012). The OAuth 2.0 Authorization Framework.
- Maler, E., Machulak, M., Richer, J. (2017). UMA 2.0 Core Specifications.
- Kantara Initiative CIS WG (2022). Consent Receipt Specification v1.1.