Cose importanti che devi sapere su OAuth

OAuth è qualcosa che ogni sviluppatore deve conoscere. Se stai realizzando 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 o la password dell'utente. Il framework OAuth è responsabile degli scambi necessari prima che un'applicazione ottenga le tue informazioni.

Supponiamo che tu voglia iscriverti a Dev.a (che è un ottimo posto per gli sviluppatori per scambiare idee) ti permettono di registrarti usando il tuo account GitHub. Come succede?? Come fanno a sapere che possiedi l'account GitHub con cui ti stai registrando??

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

Partecipanti OAuth

Ci atterremo all'esempio del plug-in GitHub dell'editor Atom che consente agli sviluppatori di inviare il codice a GitHub direttamente utilizzando l'interfaccia Atom. La ragione di questo come esempio è perché GitHub non nasconde i dettagli dietro le quinte e puoi vedere cosa sta succedendo sotto il cofano.

Prima di entrare nei dettagli del funzionamento di OAuth. Prepariamo il terreno riconoscendo tutti i partecipanti allo scambio:

1. Proprietario o utente della risorsa: Questo utente è quello di cui è necessario accedere alle informazioni sull'account (leggere e/o scrivere) per farlo funzionare con un'applicazione.
2. Cliente: Questa è l'applicazione che richiede la tua autorizzazione per accedere alle tue informazioni da un altro servizio. Nel nostro esempio, Atom editor è il client.
3. Risorsa: La risorsa sono le tue informazioni effettive che si trovano nei server in una posizione remota. È possibile accedervi tramite un'API se al client vengono concesse le autorizzazioni appropriate.
4. Server di autorizzazione: Interfacciabile anche tramite API. Questo server è gestito dal fornitore 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 esposti come API allo sviluppatore del client.

Registrazione OAuth

Il processo inizia quando l'applicazione client è in fase di sviluppo. Puoi andare al fornitore di risorse e iscriverti al portale degli sviluppatori o alla sezione API del sito web. Dovrai anche fornire un URL di richiamata in cui l'utente verrebbe reindirizzato dopo aver accettato o rifiutato per dare all'app le autorizzazioni necessarie.

Ad esempio, se vai su GitHub→ Impostazioni → Impostazioni sviluppatore 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 di sviluppatori deve mantenere... beh un segreto.

Dopo che l'ID cliente e il segreto sono stati forniti a te, lo sviluppatore, tu dovere mantienili al sicuro in quanto non verranno più mostrati dal server di autorizzazione. Lo stesso vale per qualsiasi altro token che verrebbe lanciato in giro (più sui token in seguito).

Flusso di lavoro OAuth 2

Hai registrato la tua candidatura. È stato sviluppato e testato e ora gli utenti sono pronti per usarlo. A un nuovo utente al momento della registrazione al tuo servizio verrà mostrata l'opzione "Accedi con GitHub". Questo è il primo passo.

Passaggio 1: richiesta di autorizzazione

La richiesta di autorizzazione è la parte in cui si apre una nuova finestra (o un prompt simile) con la pagina Web della risorsa e chiede agli utenti di accedere. Se hai già effettuato l'accesso, su quel dispositivo, questo passaggio viene saltato e GitHub ti chiede semplicemente se desideri consentire l'accesso all'app client Atom. Questo è molto più trasparente nel caso di Atom perché ti chiedono di andare manualmente sul sito Web di GitHub e concedere loro l'autorizzazione.

Visitando l'URL, ti viene chiesto il permesso.

Nota 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, piuttosto fuori mano.

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

Passaggio 2: ottenere la concessione di autorizzazione

Per notificare il client Atom, ti viene dato un token (una concessione di autorizzazione) che viene poi inviato al client Atom.

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

Passaggio 3: ottenere il token di accesso

La concessione dell'autorizzazione non è ancora l'entità che dà al client l'accesso alle informazioni dell'utente. Ciò si ottiene utilizzando qualcosa chiamato token di accesso. Quale l'app client tenterà di ottenere in questo passaggio.

Per fare ciò, il client dovrà ora fornire la concessione 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 forniti in precedenza all'app client.

La verifica dell'identità viene eseguita per garantire che l'utente non venga indotto con l'inganno a utilizzare un'app dannosa 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 indotto con l'inganno a concedere l'accesso a un client che può abusare delle tue informazioni. Possono curiosare o anche agire senza il tuo consenso. Il server di autorizzazione assicura che il client sia effettivamente ciò che appare ai suoi utenti.

Una volta verificata l'identità e accettata la concessione dell'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 data al server delle risorse per accedere a una particolare risorsa protetta a cui il proprietario della risorsa ti ha permesso di accedere.

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

Nota come in questo intero scambio il nome utente e la password effettivi non sono mai stati condivisi con il cliente? Questa è la bellezza di OAuth. Invece di fornire nome utente e password che concederebbero all'app tutto l'accesso alla risorsa, utilizza invece i token. E un token può ottenere solo un accesso limitato alla risorsa.

Revoca dei permessi

Supponiamo che tu perda l'accesso al tuo dispositivo che conteneva l'app client autorizzata. Puoi accedere a GitHub e andare su Impostazioni → Applicazioni → App OAuth autorizzate per revocare la concessione di autorizzazione e il token di accesso. Farò lo stesso, poiché negli screenshot sopra è stata mostrata pubblicamente la concessione dell'autorizzazione.

Ora che hai una visione d'insieme di come OAuth 2.Puoi leggere di più sulle concessioni di autorizzazione e altri dettagli più fini del protocollo e su come vengono effettuate le chiamate API qui.