Quando si implementa un provider OAuth, qual è la giusta granularità per un "ambito"?

4

Se sono un fornitore OAuth e voglio consentire all'utente di limitare le app solo a un sottoinsieme di risorse (ad esempio, solo le risorse nella cartella X), qual è il meccanismo giusto per farlo? Sembrerebbe che gli Scopes lo siano, ma per questo non trovo nessun precedente.

Spesso vedo gli ambiti implementati come diverse autorizzazioni , ad es. "sola lettura" o "lettura-scrittura". Si tratta spesso di classificazioni molto approssimative e richiedono che se sia necessario un accesso approfondito a un determinato insieme di risorse, esso debba essere esteso anche in modo tale che si ottenga l'accesso in lettura e scrittura a tutto anche se è necessario modificare solo una cosa.

A volte vedo gli ambiti implementati come categorie di risorse per accedere, ad es. "foto" o "indirizzo email". Questo ha senso solo se disponi di un insieme di categorie di risorse significative, predefinite e definite.

Quando guardo gli ambiti di Google Drive , ad esempio, sembra che non ci sia modo di limitare l'app accesso a una raccolta di file. Mi scuso se non sto guardando abbastanza bene, ma questo sembra essere molto utile e semplicemente non esiste. Drive ha un ambito "per file" ma ha un comportamento molto specifico a cui non sono interessato.

In qualità di fornitore OAuth, quali sono gli argomenti per / contro la creazione di ambiti per le risorse create dall'utente? Cioè, perché Google non può consentire un ambito per ciascuna delle cartelle dell'utente? Presumibilmente, l'app avrebbe bisogno dell'autorizzazione per elencare prima le cartelle in modo che l'utente potesse selezionarle, quindi l'app potrebbe richiedere ulteriori autorizzazioni alle cartelle. Ciò significherebbe più finestre di dialogo di OAuth, quindi posso immaginare che la risposta sia semplicemente difficile da fare una buona esperienza. Ho avuto difficoltà a trovare discussioni su questi compromessi altrove.

    
posta Greg S 10.03.2014 - 22:02
fonte

1 risposta

2

Potresti in alternativa prendere in considerazione qualcosa come un Web Powerbox invece, eventualmente combinato con un setup grafico a albero di Rumpelstiltskin . OAuth basicamente ha l'autorità sbagliata che chiede / concede al paradigma di fare un utile lavoro multi-granulare con. Con una soluzione powerbox, l'app chiede al powerbox di chiedere all'utente di selezionare un'entità che il powerbox assegna all'utente. Tutto ciò di cui l'app ha quindi bisogno è un ambito per il powerbox, ad esempio consentendo all'app di chiedere al powerbox di chiedere all'utente di selezionare un aspetto di sola lettura di un determinato tipo dall'albero delle directory. Con un treegato di Rumpelstiltskin, è possibile costruire un albero di directory con un nome di autenticazione (password-capability) per ogni nodo senza la necessità di gestire i dati relazionali (sql e roba). Combinando i due, un utente di un'app potrebbe delegare l'accesso ad altri utenti della stessa o di una app correlata.

    
risposta data 11.03.2014 - 08:22
fonte

Leggi altre domande sui tag