OAuth è un protocollo gratuito che consente a un sito Web , software o applicazione (denominato "consumatore") di essere autorizzato a utilizzare l' API sicura di un altro sito Web (denominato "fornitore") per conto di un utente. OAuth non è un protocollo di autenticazione , ma un protocollo di "delega di autorizzazione".
OAuth consente agli utenti di dare, al sito o software "consumatore", l'accesso alle sue informazioni personali che ha memorizzato sul sito "fornitore" del servizio o dei dati, ciò proteggendo lo pseudonimo e la password degli utenti. Ad esempio, un sito di manipolazione video potrà modificare i video registrati su Dailymotion di un utente dei due siti, su sua richiesta.
Il protocollo è stato creato da Blaine Cook e Chris Messina e la sua parte principale, OAuth Core 1.0, è finalizzata3 ottobre 2007.
OAuth è iniziato in Novembre 2006, mentre Blaine Cook ha implementato OpenID per Twitter . Con Chris Messina, hanno incontrato David Recordon e Larry Halff per discutere la possibilità di utilizzare OpenID e API di Twitter per delegare l'autenticazione. Hanno concluso che non esisteva uno standard aperto per la delega dell'accesso alle API.
È stato creato un gruppo di lavoro in aprile 2007scrivere una prima bozza di proposta per un protocollo aperto. DeWitt Clinton di Google è stato informato del progetto OAuth e ha dichiarato la sua disponibilità a supportare lo standard. NelLuglio 2007, il team ha scritto le prime specifiche in Draft. Il3 ottobre 2007, è stata rilasciata la versione OAuth Core 1.0.
Il 24 giugno 2009, la versione OAuth Core 1.0a ha corretto un difetto di sicurezza.
Nel aprile 2010, RFC 5849 standardizza OAuth 1.0a.
Nel ottobre 2012, RFC 6749 e RFC 6750 standardizzano OAuth 2.0.
OAuth nella versione 2.0 si basa su scambi tra quattro giocatori. Il proprietario della risorsa può concedere l'accesso alla risorsa per un'applicazione client . Il server di autorizzazione occupa il ruolo centrale all'interno del protocollo, è responsabile dell'autenticazione del proprietario della risorsa e del rilascio della sua autorizzazione sotto forma di token chiamato token di accesso . Il server delle risorse corrisponde al server in cui sono archiviate le risorse protette.
Quando l'applicazione client desidera richiedere una risorsa all'utente, invia una richiesta al server di autorizzazione costituito sia da un URI di ritorno che da un ambito. L' ambito definisce il tipo e l'ambito delle risorse richieste. Su questa base, il server di autorizzazione autentica l'utente e raccoglie il suo consenso per la trasmissione della risorsa. Il server di autorizzazione invierà un codice di autorizzazione al client come parametro dell'indirizzo URI di ritorno. Quando l'utente si connette a questo URI completato con il codice di autorizzazione , il client invia il codice di autorizzazione al server di autorizzazione per ricevere un token di accesso . Infine, il client invia il token di accesso al server delle risorse per ottenere le risorse dell'utente.
Questo meccanismo avanti e indietro con il codice di autorizzazione e il token di accesso presenta diversi vantaggi: