OAuth è un protocollo di autenticazione e autorizzazione, originariamente sviluppato per applicazioni Web, nato all'interno di Twitter nel 2006.

Consente a software di terze parti di fare qualcosa per conto tuo, per un tempo limitato e senza fornire a tale software un accesso permanente e permanente alle informazioni riservate. L'analogia più comune sono le chiavi del cameriere.

Analizziamo un po 'più a fondo e scopriamo di più su OAuth.

Q: Quindi, chiavi di consegna. Intendi quelle chiavi normalmente consegnate agli assistenti di parcheggio negli hotel?

A: Sì. Queste chiavi consentono di aprire, avviare e guidare la tua auto, ma solo per un viaggio molto breve e senza aprire il bagagliaio. OAuth funziona come una chiave di valet per i tuoi dati. Fornisce accesso temporaneo e limitato a qualcosa che è tuo, senza dare il pieno controllo.

D: Ora capisco cosa intendi ma ... è un problema del mondo reale?

R: È diventato uno quando i servizi online e i social network in tutte le loro forme, da Twitter e Flickr al remote banking, sono diventati non solo onnipresenti, ma interconnessi: sono molto più utili quando puoi farli lavorare insieme.

D: Si fa riferimento a casi come la pubblicazione di una galleria su Flickr su Facebook.

A: Sì, esattamente. Essere in grado di farlo senza reinserire tutto manualmente è grandioso. Tuttavia, farlo senza qualcosa come OAuth può significare dare a quei siti pieno accesso a tutti i tuoi contenuti (come file, elenchi di contatti o pieno accesso ai servizi).

D: Ecco perché hai parlato sia dell'autenticazione che dell'autorizzazione?

A: corretto. Autenticazione significa avere un modo per dimostrare che sei veramente tu. Si noti che, in generale, non fa differenza se "tu" è un essere umano o un programma software. Mentre l'autorizzazione è un servizio separato, ugualmente necessario. Se una persona o un programma software ha già dimostrato a Facebook chi sono, ciò non significa che abbiano il permesso di aggiornare il nostro stato come se fossero noi.

D: Non è stato possibile utilizzare OpenID per questo?

A: OpenID si occupa solo di autenticazione. OAuth, invece, aiuta in tutti quei casi in cui (usando la terminologia OAuth) alcuni software (client) che vorrebbero accedere ai dati per conto di chi ha il diritto di autorizzare tale accesso (proprietario delle risorse) è completamente separato e sconosciuto a , il software o il servizio che archivia effettivamente tali risorse.

Q: Aspetta un secondo! Qualcosa di simile è stato possibile anni prima di OAuth!

R: Sì, ma nella maggior parte dei casi significava utilizzare solo un account di una rete di siti Web già cooperativi, o dare ad almeno uno di essi i tuoi nomi utente e password su tutti gli altri. OAuth tenta di chiudere questo buco di sicurezza.

D: Intendi autorizzare l'accesso a ciò che si trova all'interno di un account web senza fornire la mia password e il nome utente?

R: Supponiamo che tu abbia fatto un commento su alcuni blog e desideri che quel blog lo pubblichi su Twitter per tuo conto, per risparmiare la digitazione. Quando comunichi al software del blog di farlo (ad esempio facendo clic su un pulsante), invierà una richiesta a Twitter, che include una chiave di identificazione e l'elenco di dati o servizi a cui vorrebbe accedere per tuo conto. Twitter (non il blog!) Ti presenterà un modulo web di autorizzazione personalizzato ospitato sul suo server. Se accedi correttamente su Twitter e rispondi "sì" a quella richiesta, avrai autorizzato Twitter a soddisfare la richiesta di quel blog. Senza passare la password e il nome utente.

Q: fantastico! Allora cosa?

A: Twitter dirà al tuo browser di tornare al blog, ma con un URL speciale che include un "token di accesso" o una chiave di autorizzazione monouso. A quel punto il software del blog sarà in grado di presentare quel token su Twitter, come prova che è quello che ha appena avuto il permesso di fare qualcosa o con il tuo account.

D: Funzionerà con tutti i siti Web compatibili con OAuth, non solo con Twitter?

A: È corretto. Finché quei siti Web non rifiutano la richiesta iniziale, ovviamente. Oltre alla comodità per l'utente finale, un altro potente driver per OAuth era il desiderio di rendere la vita più difficile per spambots e altre applicazioni dannose.

Q: Come farebbe OAuth?

A: A prescindere dall'autorizzazione dell'utente, un programma software può funzionare come descritto solo se è autorizzato a farlo dal sito Web a cui desidera accedere. OAuth realizza questo utilizzando più chiavi di identificazione, o credenziali, in parallelo.

D: Quali sono queste credenziali e chi le emette?

A: Quella che abbiamo già menzionato, quelle usate per dichiarare che l'accesso da qualche programma è permesso senza fornire la tua password, sono chiamate credenziali di token. Prima di arrivare a quel punto, tuttavia, il client deve aver inviato al server le sue credenziali client valide.

In generale, vengono emessi dal server Web stesso. Quando gli sviluppatori di alcuni software desiderano aggiungere funzionalità OAuth, si registrano con il server per ottenere tali credenziali o chiavi. Questo rende un po 'più facile fermare alcuni malware, ma ha anche rotto molti programmi esistenti.

D: Continui a parlare di siti web. Ciò significa che OAuth è inutilizzabile dal software desktop?

A: Questa è una domanda trabocchetto. Tecnicamente, in OAuth non c'è nulla che impedisca ai client di essere applicazioni desktop tradizionali in esecuzione all'interno del computer. In pratica, farlo (almeno con OAuth 1.0) rende la vita più difficile per gli sviluppatori in buona fede, o l'intero concetto di credenziali del cliente quasi inutile. Soprattutto quando si utilizza un software open source.

Q: Argh! Ora è male, ma perché?

A: Perché lo schema che ho descritto funziona perfettamente quando le credenziali del client sono incorporate nel codice sorgente e / o nei programmi compilati che vengono eseguiti solo all'interno di alcuni server Web, dove nessuno può leggere le credenziali nel codice sorgente o, utilizzando editor esadecimali e strumenti simili, nei file eseguibili.

D: Ecco perché il problema è ancora più grande con il software desktop open source?

A: Precisamente. Se metti qualcosa che dovrebbe rimanere privato in qualche codice sorgente che tutti hanno il diritto di scaricare e studiare ... non è privato per definizione, è?

Q: Certo, ma questo rende solo lo schema meno utile. Perché hai anche detto che OAuth rompe il software esistente?

A: Perché prima di OAuth 1.0, chiunque avesse una conoscenza di base di shell scripting e cUrl (incluso il tuo veramente!) Potrebbe, in pochi minuti, concludere uno script che si collegherebbe automaticamente su Twitter, leggere una timeline o postare una Tweet. OAuth ha reso impossibile questo senza credenziali client valide e registrate. Anche quando ottenere quelle credenziali richiede molto più tempo rispetto alla scrittura dello script in primo luogo!

D: Non c'è modo di applicare patch a quegli script?

A: Certo che c'è: basta usare una delle tante librerie software che sono già state registrate. Tuttavia, questo rende ancora più difficili da scrivere e gestire quegli script rispetto a prima. Fino al rilascio di OAuth 2.0, almeno.

D: Vuoi dire che arriva una versione 2.0? quando?

A: La previsione, mentre scriviamo, è che OAuth 2.0 dovrebbe essere completato entro la fine del 2011.

Q: Cosa c'è di nuovo in OAuth 2.0? Risolverà questi problemi?

A: Potrebbe. Uno dei cambiamenti più importanti è l'aggiunta o ridefinizione di diversi cosiddetti "flussi" per ottenere credenziali nel modo più diretto, anche in scenari in cui i client non sono server Web ma, ad esempio, software in esecuzione su dispositivi mobili. C'è anche un flusso basato sui cookie che dovrebbe consentire di resuscitare i vecchi script di web automation basati su CURL. Ci dovrebbero anche essere diverse ottimizzazioni delle prestazioni, perché OAuth 1.0 non scala molto bene.

Q: Dove posso trovare di più?

L'introduzione ufficiale di OAuth.