OAuth ist ein kostenloses Protokoll , mit dem Sie eine Website , Software oder Anwendung (als "Verbraucher" bezeichnet) autorisieren können , die sichere API einer anderen Website (als "Lieferant" bezeichnet) im Namen eines Benutzers zu verwenden. OAuth ist kein Authentifizierungsprotokoll , sondern ein "Delegation of Authorization" -Protokoll .
Mit OAuth können Benutzer der Website oder Software des Verbrauchers Zugriff auf seine persönlichen Informationen gewähren, die er auf der Website des Anbieters des Dienstes oder der Daten gespeichert hat, wobei das Pseudonym und die Kennwortbenutzer geschützt werden. Beispielsweise kann eine Videomanipulationssite auf Anfrage die auf Dailymotion aufgezeichneten Videos eines Benutzers der beiden Sites bearbeiten .
Das Protokoll wird von Blaine Cook und Chris Messina erstellt und sein Hauptteil, OAuth Core 1.0, wird am fertiggestellt3. Oktober 2007.
OAuth begann in November 2006, während Blaine Cook OpenID für Twitter implementierte . Mit Chris Messina trafen sie David Recordon und Larry Halff, um die Möglichkeit zu diskutieren, OpenID und API von Twitter zur Delegierung der Authentifizierung zu verwenden. Sie kamen zu dem Schluss, dass es keinen offenen Standard für die API-Zugriffsdelegierung gibt.
Eine Arbeitsgruppe wurde in erstellt April 2007einen ersten Entwurf eines Vorschlags für ein offenes Protokoll zu schreiben. DeWitt Clinton von Google wurde über das OAuth-Projekt informiert und erklärte sich bereit, den Standard zu unterstützen. ImJuli 2007Das Team schrieb die ersten Spezifikationen in Draft. Das3. Oktober 2007wurde die OAuth Core 1.0-Version veröffentlicht.
Das 24. Juni 2009, Version OAuth Core 1.0a hat eine Sicherheitslücke behoben.
Im April 2010, RFC 5849 standardisiert OAuth 1.0a.
Im Oktober 2012, RFC 6749 und RFC 6750 standardisieren OAuth 2.0.
OAuth in Version 2.0 basiert auf dem Austausch zwischen vier Spielern. Der Ressourcenbesitzer kann einer Clientanwendung Zugriff auf die Ressource gewähren . Der Autorisierungsserver nimmt die zentrale Rolle innerhalb des Protokolls ein. Er ist für die Authentifizierung des Ressourcenbesitzers und die Erteilung seiner Autorisierung in Form eines Tokens namens Zugriffstoken verantwortlich . Der Ressourcenserver entspricht dem Server, auf dem die geschützten Ressourcen gespeichert sind.
Wenn die Clientanwendung eine Ressource vom Benutzer anfordern möchte, sendet sie eine Anforderung an den Autorisierungsserver, die sowohl aus einem Rückgabe-URI als auch einem Bereich besteht. Der Bereich definiert den Typ und den Umfang der angeforderten Ressourcen. Auf dieser Basis authentifiziert der Autorisierungsserver den Benutzer und holt seine Zustimmung zur Übertragung der Ressource ein. Der Autorisierungsserver sendet einen Autorisierungscode als Parameter der Rückgabe-URI-Adresse an den Client. Wenn der Benutzer eine Verbindung zu diesem URI herstellt, der mit dem Autorisierungscode abgeschlossen ist , sendet der Client den Autorisierungscode an den Autorisierungsserver zurück , um ein Zugriffstoken zu erhalten . Schließlich sendet der Client das Zugriffstoken an den Ressourcenserver , um die Ressourcen des Benutzers abzurufen.
Dieser Hin- und Her-Mechanismus mit dem Autorisierungscode und dem Zugriffstoken bietet mehrere Vorteile: