OAuth2 e autenticazione

1.What is the difference between authentication and authorization?

Authentication è il processo tramite il quale un server controlla se un utente è effettivamente l'utente che dichiara di essere. Questo di solito viene fatto, quando l'utente fornisce il nome utente e una password, mentre il server controlla queste credenziali (nome utente, password) con quelle memorizzate nel suo database, quando il primo utente ha creato il suo account. Autorizzazione si verifica quando un'entità fornisce l'autorizzazione a un'altra entità per eseguire un'azione. In questo caso, ad esempio, è quando un sito desidera accedere ai dati di un utente, che sono memorizzati e di proprietà in un sito Web diverso.

2.What is OAuth2 meant to do?

Ufficialmente, OAuth2 consente a un utente di consentire a un sito Web del cliente C di accedere ai propri dati da un sito Web del server delle risorse RS dopo l'autenticazione tramite un sito Web del server di autenticazione AS. Questo sembra abbastanza complesso, quindi per semplificare, un esempio comune è quando un utente accede a un sito Web usando il suo account Facebook. In tal caso, il sito Web del cliente e il sito Web del server delle risorse sono gli stessi (C = RS = il sito Web visitato) e il server di autenticazione è Facebook (AS = facebook). Si noti che questo è stato creato, in modo che la C, RS non impari la password dell'utente, pur essendo in grado di autenticarlo.

3.WhyisOAuth2implicitflowinsecureforauthenticationwhilestillsecureforauthorization?

Laspecificitàconilflussoimplicitoèilfattocheiltokendiaccessoèdatoallouser-agentperinoltrareall'applicazione.Quindi,sibasaesclusivamentesull'URIdireindirizzamento.Pertanto,questoflussononautentical'identitàdell'applicazione,poichénonvièalcunariservatezzasegretadelclient(tokendiaccessoespostoall'utenteeapplicazioniinesecuzioneneldispositivomobile)

4.WhatisthedifferencebetweenOAuth2implicitflowandOauth2authenticationcodeflowandwhentousewhich?

Comedescrittoinprecedenza,nelflussoimplicitoiltokendiaccessovieneinoltratoall'applicazionedall'agenteutente.D'altraparte,nelflussodelcodicediautorizzazione,ilserverwebdelclientottieneprimauncodicediautorizzazione(dopocheilproprietario/utentedellarisorsahadatol'accesso),quindieffettuaunachiamataall'APIpassando(clientID,secretID)conilcodicediautorizzazioneperottenereiltokendiaccesso.Questoèfatto,cosìcheincasodiconnessioniHTTP(senzacrittografiaSSL),iltokendiaccessononèaccessibileaman-in-the-middle(router,proxy,ecc.).Quindi,ilprimoèadattoperleapplicazionimobili,mentreilsecondoèadattoperleapplicazionilatoserver.

5.DoesOAuth2authenticationcodeflowworkforauthentication?

Sì,ilflussodelcodicediautorizzazioneautenticaanchel'utentetramiteilserverdiautenticazione.

6.ShouldyouuseOpenIDinsteadofOAuth2forauthentication?

Sì.

OpenIDvieneutilizzatoperl'autenticazione.UnesempioèquandovogliamochegliutentipossanoaccedereinpiùsitiWebconunsingolosetdicredenziali(sign-sign-on).

OAuthvieneutilizzatoperl'autorizzazione,comedescrittoinprecedenza.SinoticheOAuthpuòessereleggermenteregolato(comenell'esempioprecedente,doveC=RS)pereseguire(pseudo-)l'autenticazione,tramiteautorizzazione.Ma,sevogliamosolol'autenticazione,possiamousareOpenID.

7.Whyisgooglesayingthattheir"OAuth2" framework can be used for both authentication and authorization.

Credo che le vere ragioni alla base di questa decisione progettuale possano essere date solo dai corrispondenti ingegneri di Google, ma potrei supporre che invece di usare sia OpenID che OAuth, hanno scelto di utilizzare un singolo protocollo per entrambi gli usi, al fine di semplificare cose. Tuttavia, sii consapevole del fatto che l'autenticazione tramite OAuth viene eseguita autentificando qualcuno, attraverso i dati che possiede. Un esempio noioso sarebbe che quando sto cercando di entrare nel mio edificio di lavoro, non mi chiedono le mie credenziali, perché la mia carta dei dipendenti è ovviamente nel mio collo. In questo modo l'autenticazione viene eseguita tramite OAuth, abbastanza semplificata. Quindi, puoi vedere che questo può fare diverse assunzioni che non sempre si tengono in ogni scenario. E questo è il motivo per cui in genere si consiglia di utilizzare OAuth solo per l'autorizzazione e utilizzare OpenID, nel caso in cui sia necessario implementare l'autenticazione.

Un link piacevole che descrive i vari flussi di OAuth per reference

@RaptisDimos ha dato una buona risposta, ma penso che spenderò al punto # 3.

3. Why is OAuth2 implicit flow insecure for authentication while still secure for authorization?

Il problema con il flusso implicito quando si tenta di utilizzarlo per l'autenticazione è che il client riceve direttamente un token di accesso e che il token di accesso non è associato a nessun client specifico. Ciò significa che il client non sa se questo token è stato pensato per lui o un'altra applicazione.

Questo token viene quindi utilizzato per accedere ai dati del proprietario. Quando si desidera "autenticare" il proprietario, di solito si estrae la sua e-mail dai suoi dati e l'utente viene autenticato nella propria applicazione (client). Ma non sai chi ha passato quel token di accesso al tuo cliente. Era il vero proprietario o un attaccante che ospita un altro servizio?

Esempio di attacco

• Client_Good: un buon client che utilizza l'API di google per autenticare il suo utente utilizzando il flusso implicito
• Client_Bad: un client dannoso che utilizza l'API di google e attacca Client_Good

Client_Bad può essere qualsiasi servizio. Ad esempio, un'applicazione web che ti consente di caricare immagini nella tua unità di google. Per raggiungere tale obiettivo, Client_Bad necessita di un token di accesso da Google. Quindi ti chiederà di fornirgliene uno. Quindi, potrai utilizzare il suo servizio per caricare la tua foto.

Quello che non sapevi è che il token di accesso che hai appena dato a Client_Bad per caricare immagini è anche un token di accesso valido che può essere usato con Client_Good per autenticarti. Ora, il proprietario di Client_Bad può impersonarti in Client_Good. Se Client_Good fosse un servizio critico, potresti essere in serio problema.

Perché è sicuro per l'autorizzazione allora?

È sicuro perché se concedi l'autorizzazione a Client_Bad per caricare l'immagine per tuo conto, non importa se lo sta facendo direttamente o sta passando da un altro servizio per farlo.

Ad esempio, potrebbe esserci un terzo client, Client_Picture, che si limita a caricare l'immagine sul tuo disco google. Quando chiedi a Client_Bad di caricare i tuoi contenuti, Client_Bad potrebbe delegare tale attività a Client_Picture e non ti importerebbe avere lo stesso risultato.

Bene, c'è il fatto che ora una tonnellata di terze parti potrebbe avere accesso ai tuoi dati ma, di nuovo, hai accettato che Client_Bad potesse fare tutto ciò che desidera con questo token di accesso quando lo hai dato. È come passare la chiave della tua auto al tuo vicino. Hai dato a qualcun altro il diritto di usare quell'auto, potrebbe quindi prestarlo a un altro vicino per un po 'e poi restituirlo a te. Il fatto è che non lo sai e tu "ti sei accordato" quando hai dato il controllo.

Nota : A volte mi chiedo se nessuno capisce la spiegazione o se ho detto qualcosa di sbagliato ... Comunque, è spiegato nella sezione 10.16 della specifica OAuth2 in altre parole se questo aiuta.