Cose importanti che devi sapere su oauth

Oauth è qualcosa che ogni sviluppatore deve conoscere. Se stai facendo un'applicazione autonoma o un'applicazione di terze parti che si integra con qualche altro servizio HTTP, devi sapere come funziona OAuth per fornire ai tuoi utenti un servizio facile da usare e ben integrato.

L'idea è di consentire alle applicazioni client un accesso limitato alle informazioni dell'utente senza mai condividere le credenziali dell'utente o la password. Oauth Framework è responsabile degli scambi richiesti prima che una domanda riceva le tue informazioni.

Supponiamo di voler iscriverti a Dev.a (che è un ottimo posto per gli sviluppatori di scambiare idee) ti consentono di iscriverti usando il tuo account GitHub. Come succede? Come vorrebbero sapere che possiedi l'account GitHub, con cui ti iscrivi?

Ancora più importante, come si assicura che Dev.non sta oltrepassando i suoi confini quando si tratta delle tue informazioni memorizzate con github?

Partecipanti oauth

Atterremo all'esempio del plug -in GitHub di Atom Editor che consente agli sviluppatori di spingere il codice a GitHub utilizzando direttamente l'interfaccia Atom. La ragione di ciò come esempio è perché GitHub non nasconde i dettagli dietro la scena e puoi vedere cosa sta succedendo sotto il cofano.

Prima di entrare nelle minuzie del lavoro di Oauth. Imposiamo le basi riconoscendo tutti i partecipanti allo scambio:

1. Proprietario o utente delle risorse: Questo utente è quello di cui è necessario accedere alle informazioni sull'account (leggi e/o scrittura) per farlo funzionare con un'applicazione.
2. Cliente: Questa è l'applicazione che sta cercando la tua autorizzazione per accedere alle tue informazioni da un servizio diverso. Nel nostro esempio, Atom Editor è il cliente.
3. Risorsa: La risorsa è le informazioni effettive sedute nei server in una posizione remota. È possibile accedere a un API se al cliente vengono concesse autorizzazioni appropriate.
4. Server di autorizzazione: Interfacciato anche con tramite un'API. Questo server è mantenuto dal provider di servizi (GitHub nel nostro esempio). Sia il server di autorizzazione che il server di risorse sono indicati come API perché sono gestiti da un'entità, in questo caso GitHub ed esposte come API allo sviluppatore client.

Registrazione OAuth

Il processo inizia quando l'applicazione client viene sviluppata. Puoi andare al fornitore di risorse e iscriverti al portale del loro sviluppatore o alla sezione API del sito Web. Dovrai inoltre fornire un URL di callback in cui l'utente verrebbe reindirizzato dopo aver accettato o rifiutato per fornire alle autorizzazioni necessarie.

Ad esempio, se vai su GitHub → Impostazioni → Impostazioni sviluppatori e fai clic su "Registra una nuova applicazione". Questo ti fornirebbe un Identificativo cliente che può essere reso pubblico e a Segreto del cliente che, l'organizzazione sviluppatore deve mantenere ... beh un segreto.

Dopo che l'ID client e il segreto ti vengono forniti, lo sviluppatore, tu dovere Tienili al sicuro in quanto non verranno mostrati dal server di autorizzazione. Lo stesso vale per qualsiasi altro token che verrebbe lanciato (più su token più tardi).

Oauth 2 flusso di lavoro

Hai registrato la tua domanda. È stato sviluppato e testato e ora gli utenti sono pronti a usarlo. Un nuovo utente durante la registrazione con il tuo servizio verrà visualizzata l'opzione di "Accedi con GitHub". Questo è il primo passo.

Passaggio 1: richiesta di autorizzazione

La richiesta di autorizzazione è la parte in cui una nuova finestra (o un prompt simile) si apre con la pagina Web delle risorse e chiede agli utenti di accedere. Se hai già effettuato l'accesso, su quel dispositivo, questo passaggio viene saltato e ti viene semplicemente chiesto da GitHub se si desidera accedere all'app client Atom. Questo è molto più trasparente in caso di atom.

Visitando l'URL, ti viene chiesto il permesso.

Notare l'URL che mostra che questa è una pagina web sicura (https) di github.INC. Ora tu, l'utente, puoi essere certo di interagire direttamente con GitHub. Atom sta semplicemente aspettando, abbastanza fuori mano.

A differenza di Atom, la maggior parte delle app client carica automaticamente la pagina di accesso o autorizzazioni. Mentre questo è molto conveniente, può anche essere utilizzato in modo improprio, se l'app client decide di aprire un collegamento di phishing. Per evitarlo, devi sempre controllare l'URL a cui sei reindirizzato e assicurarti che sia URL corretto e stia usando il protocollo HTTPS.

Passaggio 2: ottenere la sovvenzione di autorizzazione

Per avvisare il cliente Atom, ti viene assegnato un token (una sovvenzione di autorizzazione) che viene quindi inviato al cliente Atom.

Una volta che l'utente lo fa, il lavoro dell'utente è finito. (In effetti, un utente tipico non è nemmeno a conoscenza dello scambio di sovvenzione di autorizzazione. L'esempio di GitHub è stato scelto per dimostrare che questo è ciò che accade).

Passaggio 3: ottenere il token di accesso

La sovvenzione di autorizzazione non è ancora l'entità che fornisce al cliente l'accesso alle informazioni dell'utente. Che si ottiene utilizzando qualcosa chiamato token di accesso. Che l'app client proverà a partecipare a questo passaggio.

Per fare ciò, il client dovrà ora fornire la sovvenzione di autorizzazione al server di autorizzazione insieme a una prova della propria identità. L'identità viene verificata utilizzando l'ID client e il segreto client che sono stati forniti all'app client in precedenza.

La verifica dell'identità viene eseguita per garantire che l'utente non sia indotto a utilizzare un'app nefasta che finge di essere un'app legittima. Ad esempio, se qualcuno decide di nominare il proprio eseguibile come Atom con lo stesso nome, logo e funzionalità l'utente potrebbe essere ingannato nel dare accesso a un client che può abusare delle tue informazioni. Possono curiosare o addirittura agire senza il tuo consenso. Il server di autorizzazione garantisce che il client sia effettivamente ciò che appare ai suoi utenti.

Una volta verificata l'identità e l'accettazione della sovvenzione di autorizzazione, il server di autorizzazione lancia un token all'app client. Pensa al token come una combinazione di nome utente e password che può essere dato al server di risorse per accedere a una particolare risorsa protetta a cui il proprietario delle risorse ha permesso di accedere.

Infine, utilizzando questo token, l'app può ora ottenere l'accesso alle informazioni dell'utente richieste e ad altre risorse dal server delle risorse.

Si noti, come in questo intero scambio il nome utente e la password effettivi non hanno mai condiviso con il client? Questa è la bellezza di Oauth. Invece di fornire nome utente e password che concederebbero all'app tutto l'accesso alla risorsa, utilizza invece token. E un token può ottenere solo un accesso limitato alla risorsa.

Revocazione delle autorizzazioni

Supponiamo di perdere l'accesso al tuo dispositivo che aveva l'app client autorizzata. È possibile accedere a GitHub e andare su Impostazioni → Applicazioni → App OAuth autorizzate per revocare la sovvenzione per l'autorizzazione e il token di accesso. Farò lo stesso, dal momento che, negli screenshot di cui sopra, la sovvenzione di autorizzazione è stata mostrata pubblicamente.

Ora che hai una visione a occhio di uccello di come Oauth 2.Puoi leggere di più sulle sovvenzioni di autorizzazione e su altri dettagli più fini del protocollo e su come vengono effettuate le chiamate API qui.