Sia in OAuth che in UMA, una risorsa protetta è concettuale, sebbene in definitiva basata sulla nozione della primitiva "risorsa web" nell'architettura web. L'utente (proprietario della risorsa) non è la risorsa. I dati digitali o altre "cose" che il proprietario della risorsa vuole controllare l'accesso è la risorsa.
Molti deployer di OAuth parlano di tutto su un server delle risorse come "la risorsa protetta" (PR), quindi un'intera API tende a essere considerata come un'unica risorsa. UMA è stato specificamente progettato per consentire a più risorse protette (e per ognuna di esse di poter avere ambiti diversi come giustificato), per consentire casi d'uso come file e cartelle rispetto agli endpoint API. Quindi le cose sono più flessibili (e quindi complesse) in UMA, fuori dalla scatola.
La Guida all'implementazione di UMA ha una sezione chiamata Considerazioni sulla risorsa Richieste di autorizzazione del server con alcuni esempi di ambiti che, di passaggio, potrebbero suggerirti altri tipi di risorse protette.
Questa sezione nell'UDA Le specifiche di FedAuthz descrivono come è il lavoro del server delle risorse progettare i limiti delle risorse protette: "Il server di risorse definisce i limiti delle risorse e gli ambiti disponibili per ciascuna risorsa e interpreta come le richieste di risorse dei client si associano alle richieste di autorizzazione, in virtù dell'essere editore dell'API protetto e utilizzo dell'API di protezione per comunicare con il server di autorizzazione. "
Un esempio con cui mi occupo frequentemente è un dispositivo IoT consumer (o clinico). La domanda che si pone è: l'intero dispositivo (in pratica la sua intera API) dovrebbe essere una risorsa? O come dovrebbero essere suddivise le risorse al suo interno? Ad esempio, ogni serie di dati "in diretta" o in streaming provenienti dal dispositivo potrebbe essere una risorsa che l'utente vorrà controllare. Gli insiemi di dati storici già archiviati nel cloud potrebbero essere altre risorse. Le funzioni del dispositivo (panoramica della telecamera, spegnimento / accensione del dispositivo, qualunque) potrebbero essere un'altra risorsa singola, controllabile tramite gli ambiti.
Alcune delle considerazioni sulla progettazione dei confini qui hanno a che fare con l'usabilità. (Forse simile al processo di scelta degli elementi a discesa del pulsante Condividi di Google Apps! ...)
Alcune informazioni sulle definizioni: OAuth (IETF RFC 6749) definisce in modo informale una risorsa protetta come accesso -risorsa ristretta. UMA2 adotta la terminologia OAuth insieme ad alcuni miglioramenti; la sua specifica di autorizzazione federata anche definisce formalmente come applicare la protezione delle risorse: "La protezione di una risorsa nel server di autorizzazione inizia con la registrazione [risorsa] con esito positivo e termina con la cancellazione avvenuta con successo."
Spero che questo aiuti!