Autorizzazione fine con OAuth2

Question

Autorizzazione fine con OAuth2

#1 da (2 voti)
#2 da (0 voti)

0

Nella mia comprensione di OAuth2, è possibile utilizzare lo ambito per specificare l'accesso a quanto richiesto e concesso dal proprietario del codice.

Nella maggior parte dei casi, ho riscontrato che l'elenco degli ambiti è chiuso e specifica "tipi" di elementi a cui è possibile accedere, ad esempio profilo , email , openid da Accesso a Google .

Ha senso codificare l'accesso a risorse specifiche nell'ambito? Come account: {numero account}: rw

Questo è il caso in cui l'utente ha più risorse distinte gestite dal server di risorse e vorrebbe autorizzare l'accesso di terze parti a risorse specifiche ma invece di "tipo" di risorsa. Ad esempio l'applicazione ipotetica gestirà le cartelle di dati e l'utente U concederebbe l'accesso in lettura alla sua cartella "/ A" ma non qualsiasi altra cartella all'applicazione B

Capisco che in questo caso sia il server di autorizzazione che quello di risorsa dovrebbero analizzare e gestire specificamente tali ambiti aperti.

Ci sono altri problemi con questo approccio?

OAuth2 è anche la tecnologia giusta per questo caso? Se non cosa usare invece?

authorization oauth2

posta AGrzes 20.10.2017 - 10:36

fonte

2 risposte

Leggi altre domande sui tag authorization oauth2

È sicuro installare CCleaner ora? Esiste un rischio per la sicurezza nell'avere i miei segnalibri accessibili al pubblico?

score 2 · Answer 1

Penso che l'intento degli obiettivi di OAuth fosse quello di fornire una struttura per il consenso delegato, che è una forma di autorizzazione discrezionale, ma diversa dall'autorizzazione basata su policy, che è ciò che sembra si stia tentando di realizzare. Il server delle risorse ha la responsabilità di applicare sia la delega che l'approccio basato su policy. Gli ambiti finiscono per essere un'affermazione simile, se si tenta di modellare l'autorizzazione basata su policy e simile al controllo degli accessi basato sui ruoli, crescerà in modo esponenziale con la matrice di autorizzazione (risorsa-azione) (account di lettura, account di scrittura, ecc. ) Gli sviluppatori del tuo server delle risorse devono sapere che cosa significa applicare ciascun ambito: @PreAuthorize ("# oauth2.hasScope ('read-account')") in modo da poter vedere la complessa logica if-then-else che può risultare.

Considera di esternalizzare la tua decisione politica dal tuo Resource Server facendo in modo che utilizzi tutto il contesto che ha (attributi id_token, metadati della risorsa, footprint del cliente, ambiti) per fare una richiesta di un servizio di decisione politica con "can [subject] do [azione] su [risorsa] in questo [contesto / env]? " Il servizio di decisione politica è un dominio che contiene il tuo rischio, contesto e regole guidate da regole come "I client esterni possono leggere i dettagli dell'account quando il proprietario della risorsa ha una relazione con il proprietario dell'account quando viene utilizzata l'autenticazione a 2 fattori." Cerca s

score 0 · Answer 2

TL; DR;

Questo è un difetto di progettazione. Gli ambiti rappresentano la risorsa e in connessione con il client (applicazione) informa che questa applicazione ha accesso alla risorsa. Questo livello di granularità non è una buona idea. In questo caso, si finirebbe con un elenco molto difficile da gestire dei privilegi, direi, per le applicazioni (non gli utenti). Questo non è come dovrebbe essere fatto.

Gli ambiti nella loro definizione sono piuttosto i valori che identificano le risorse, non i privilegi. Quando si invia un ambito al server di autorizzazione, per ambito si informano le risorse a cui si desidera accedere con il client (ad esempio l'applicazione), non con l'utente. Questa è la tua risorsa che dovrebbe interpretare se l'utente che presenta il token di accesso (con gli ambiti) è legittimo ad accedervi.

Hai chiesto informazioni sull'ambito in OAuth2 ma ricorda che OAuth2 è solo un framework per AUTORIZZAZIONE, piuttosto non definito per l'autenticazione. Per l'autenticazione dell'utente è necessario utilizzare, ad esempio, OpenIDConnect (OIDC) che è basato su OAuth2.

OIDC presenta il token di identità che è il vettore dei dati dell'utente. Se ottieni il token di identità e accedi al token dal server di autorizzazione, la tua risorsa deciderà se l'utente in questione avrà accesso ai dati che desidera.