Tanto en OAuth como en UMA, un recurso protegido es conceptual, aunque en última instancia se basa en la noción de primitivo de "recurso web" en la arquitectura web. El usuario (propietario del recurso) no es el recurso. Los datos digitales u otras "cosas" a las que el propietario del recurso quiere controlar el acceso es el recurso.
Muchos implementadores de OAuth hablan de todo en un servidor de recursos como "el recurso protegido" (PR), por lo que una API completa tiende a considerarse como un recurso. UMA se diseñó específicamente para habilitar múltiples recursos protegidos (y para que cada uno de ellos pueda tener diferentes ámbitos según se justifique), para permitir casos de uso como archivos y carpetas frente a solo puntos finales de API. Así que las cosas son más flexibles (y por lo tanto complejas) en UMA, listas para usar.
La Guía del implementador de UMA tiene una sección llamada con algunos ejemplos de ámbitos que, de paso, pueden sugerir tipos adicionales de recursos protegidos para usted.
Esta sección en la UMA La especificación de FedAuthz explica cómo el trabajo del servidor de recursos es diseñar límites de recursos protegidos: "El servidor de recursos define los límites de los recursos y los ámbitos disponibles para cada recurso, e interpreta cómo las solicitudes de recursos de los clientes se asignan a las solicitudes de permisos, en virtud de ser el El editor de la API está protegido y utiliza la API de protección para comunicarse con el servidor de autorización. "
Un ejemplo con el que trato frecuentemente es un dispositivo IoT para el consumidor (o clínico). La pregunta que surge es: ¿Debería todo el dispositivo (básicamente su API completa) ser un recurso? O, ¿cómo deberían desglosarse los recursos dentro de él? Por ejemplo, cada conjunto de datos "en vivo" / de transmisión proveniente del dispositivo puede ser un recurso que el usuario querrá controlar. Los conjuntos de datos históricos ya almacenados en la nube pueden ser otros recursos. Las funciones del dispositivo (cámara panorámica, apagar / encender el dispositivo, lo que sea) pueden ser otro recurso único, controlable a través de ámbitos.
Algunas de las consideraciones de diseño de límites aquí tienen que ver con la usabilidad. (¡Quizás similar al proceso de elegir los elementos desplegables del botón Compartir de Google Apps! ...)
Algunos antecedentes sobre definiciones: OAuth (IETF RFC 6749) define informalmente un recurso protegido como acceso -Recurso restringido. UMA2 adopta la terminología de OAuth junto con algunas mejoras; su especificación de Autorización Federada también define formalmente cómo efectuar la protección de recursos: "La protección de un recurso en el servidor de autorizaciones comienza con el registro exitoso de [recursos] y termina con el desregistro exitoso".
Espero que esto ayude!