OAuth jest wolny protokół , który pozwala www , oprogramowania lub aplikacji (nazywane „konsument”), aby zostać upoważniony do korzystania z bezpiecznego API innej stronie internetowej (zwanej „dostawca”) w imieniu użytkownika.. OAuth nie jest protokołem uwierzytelniania , ale protokołem „delegowania autoryzacji”.
OAuth umożliwia użytkownikom udzielanie witrynie „konsumenta” lub oprogramowaniu dostępu do swoich danych osobowych przechowywanych na stronie „dostawcy” usługi lub danych, przy jednoczesnej ochronie pseudonimu i hasła użytkowników. Na przykład witryna do manipulacji wideo będzie mogła edytować filmy nagrane w Dailymotion użytkownika obu witryn, na jego żądanie.
Protokół został stworzony przez Blaine'a Cooka i Chrisa Messinę, a jego główna część, OAuth Core 1.0, została sfinalizowana3 października 2007.
OAuth uruchomiono za Listopad 2006, podczas gdy Blaine Cook zaimplementował OpenID dla Twittera . Chris Messina, poznali Davida Recordon i Larry Halff aby omówić możliwość OpenID i API na Twitterze delegować uwierzytelniania. Doszli do wniosku, że nie ma otwartego standardu delegowania dostępu do API.
W r. Utworzono grupę roboczą kwiecień 2007napisać pierwszą wersję roboczą propozycji otwartego protokołu. DeWitt Clinton z Google został poinformowany o projekcie OAuth i wyraził chęć wspierania standardu. WLipiec 2007, zespół napisał pierwsze specyfikacje w wersji roboczej. Plik3 października 2007, została wydana wersja OAuth Core 1.0.
Plik 24 czerwca 2009, wersja OAuth Core 1.0a poprawiła lukę w zabezpieczeniach.
W kwiecień 2010, RFC 5849 standaryzuje OAuth 1.0a.
W październik 2012, RFC 6749 i RFC 6750 standaryzują OAuth 2.0.
OAuth w wersji 2.0 opiera się na wymianach między czterema graczami. Właściciel zasób jest w stanie udzielić dostępu do zasobu dla klienta aplikacji . Serwer autoryzacyjny pełni centralną rolę w protokole, jest odpowiedzialny za uwierzytelnienie właściciela zasobu i wydanie jego autoryzacji w postaci tokena zwanego access tokenem . Serwer zasobów odpowiada serwerowi, na którym przechowywane są chronione zasoby.
Gdy aplikacja kliencka chce zażądać zasobu od użytkownika, wysyła żądanie do serwera autoryzacji zawierające zarówno zwrotny identyfikator URI, jak i zakres. Zakres określa rodzaj i zakres wymaganych zasobów. Na tej podstawie serwer autoryzacyjny uwierzytelnia użytkownika i zbiera jego zgodę na przesyłanie zasobu. Serwer autoryzacyjny wyśle do klienta kod autoryzacji jako parametr zwrotnego adresu URI. Gdy użytkownik połączy się z tym URI uzupełnionym kodem autoryzacyjnym , klient odeśle kod autoryzacyjny z powrotem do serwera autoryzacyjnego , aby otrzymać token dostępu . Na koniec klient wysyła token dostępu do serwera zasobów, aby uzyskać zasoby użytkownika.
Ten mechanizm wymiany danych z kodem autoryzacyjnym i tokenem dostępu ma kilka zalet: