OAuth 2.0: Vorteile und Anwendungsfälle - warum?

Könnte jemand erklären, was an OAuth2 gut ist und warum wir es implementieren sollten? Ich frage, weil ich etwas verwirrt bin - hier sind meine aktuellen Gedanken:

OAuth1-Anforderungen (genauer HMAC) scheinen logisch, leicht zu verstehen, leicht zu entwickeln und wirklich, wirklich sicher zu sein.

OAuth2 bringt stattdessen Autorisierungsanforderungen, Zugriffstoken und Aktualisierungstoken, und Sie müssen zu Beginn einer Sitzung drei Anforderungen stellen, um die gewünschten Daten abzurufen. Und selbst dann schlägt eine Ihrer Anforderungen möglicherweise fehl, wenn das Token abläuft.

Um ein weiteres Zugriffstoken zu erhalten, verwenden Sie ein Aktualisierungstoken, das gleichzeitig mit dem Zugriffstoken übergeben wurde. Macht dies das Zugriffstoken aus Sicherheitsgründen nutzlos?

Wie / r / netsec kürzlich gezeigt hat, ist SSL nicht ganz sicher, sodass mich der Drang verwirrt, alles auf TLS / SSL anstatt auf einen sicheren HMAC zu übertragen.

OAuth argumentiert, dass es nicht um 100% ige Sicherheit geht, sondern darum, dass es veröffentlicht und fertiggestellt wird. Das klingt aus Sicht eines Anbieters nicht gerade vielversprechend. Ich kann sehen, was der Entwurf erreichen will, wenn er die 6 verschiedenen Flüsse erwähnt, aber er passt einfach nicht in meinen Kopf.

Ich denke, es könnte mehr mein Kampf sein, die Vorteile und Argumente zu verstehen, als es tatsächlich abzulehnen, also könnte dies ein wenig ein ungerechtfertigter Angriff sein, und es tut mir leid, wenn dies wie ein Scherz erscheinen könnte.

Hintergrund: Ich habe Client- und Server-Stacks für OAuth 1.0a und 2.0 geschrieben.

Sowohl OAuth 1.0a als auch 2.0 unterstützen die zweibeinige Authentifizierung , bei der einem Server die Identität eines Benutzers zugesichert wird, und die dreibeinige Authentifizierung , bei der ein Server von einem Inhaltsanbieter der Identität des Benutzers sichergestellt wird. Bei der dreibeinigen Authentifizierung kommen Autorisierungsanfragen und Zugriffstoken ins Spiel, und es ist wichtig zu beachten, dass OAuth 1 diese auch hat.

Das Komplexe: Dreibeinige Authentifizierung

Ein Hauptpunkt der OAuth-Spezifikationen besteht darin, dass ein Inhaltsanbieter (z. B. Facebook, Twitter usw.) einem Server (z. B. einer Web-App, die im Namen des Kunden mit dem Inhaltsanbieter sprechen möchte ) versichert, dass der Kunde eine Identität hat . Die dreibeinige Authentifizierung bietet die Möglichkeit, dies zu tun, ohne dass der Client oder Server jemals die Details dieser Identität (z. B. Benutzername und Kennwort) kennen muss.

Ohne (?) Zu tief in die Details von OAuth einzudringen:

1. Der Client sendet eine Autorisierungsanforderung an den Server, die bestätigt, dass der Client ein legitimer Client seines Dienstes ist.
2. Der Server leitet den Client an den Inhaltsanbieter weiter, um den Zugriff auf seine Ressourcen anzufordern.
3. Der Inhaltsanbieter überprüft die Identität des Benutzers und fordert häufig dessen Erlaubnis zum Zugriff auf die Ressourcen an.
4. Der Inhaltsanbieter leitet den Client zurück zum Server und benachrichtigt ihn über Erfolg oder Misserfolg. Diese Anfrage enthält einen Autorisierungscode für den Erfolg.
5. Der Server sendet eine Out-of-Band-Anfrage an den Inhaltsanbieter und tauscht den Autorisierungscode gegen ein Zugriffstoken aus.

Der Server kann nun im Namen des Benutzers Anforderungen an den Inhaltsanbieter stellen, indem er das Zugriffstoken übergibt.

Jeder Austausch (Client-> Server, Server-> Inhaltsanbieter) beinhaltet die Validierung eines gemeinsam genutzten Geheimnisses. Da OAuth 1 jedoch über eine unverschlüsselte Verbindung ausgeführt werden kann, kann jede Validierung das Geheimnis nicht über die Leitung weitergeben.

Wie Sie bereits bemerkt haben, geschieht dies mit HMAC. Der Client verwendet das Geheimnis, das er mit dem Server teilt, um die Argumente für seine Autorisierungsanforderung zu signieren. Der Server nimmt die Argumente entgegen, signiert sie selbst mit dem Schlüssel des Clients und kann feststellen, ob es sich um einen legitimen Client handelt (siehe Schritt 1 oben).

Für diese Signatur müssen sich sowohl der Client als auch der Server auf die Reihenfolge der Argumente einigen (damit sie genau dieselbe Zeichenfolge signieren). Eine der Hauptbeschwerden bei OAuth 1 besteht darin, dass sowohl der Server als auch die Clients sortieren und Zeichen identisch. Dies ist fummeliger Code und entweder ist es richtig oder Sie bekommen 401 Unauthorizedmit wenig Hilfe. Dies erhöht die Barriere für das Schreiben eines Kunden.

Durch die Anforderung, dass die Autorisierungsanforderung über SSL ausgeführt werden muss, entfällt für OAuth 2.0 das Sortieren und Signieren von Argumenten insgesamt. Der Client gibt sein Geheimnis an den Server weiter, der es direkt überprüft.

Die gleichen Anforderungen gelten für die Verbindung zwischen Server und Inhaltsanbieter. Da dies SSL ist, wird eine Barriere für das Schreiben eines Servers, der auf OAuth-Dienste zugreift, beseitigt.

Dies erleichtert die Arbeit in den obigen Schritten 1, 2 und 5 erheblich.

Zu diesem Zeitpunkt verfügt unser Server über ein permanentes Zugriffstoken, das einem Benutzernamen / Kennwort entspricht, das dem Benutzer entspricht. Es kann im Namen des Benutzers Anforderungen an den Inhaltsanbieter stellen, indem dieses Zugriffstoken als Teil der Anforderung übergeben wird (als Abfrageargument, HTTP-Header oder POST-Formulardaten).

Wenn auf den Inhaltsdienst nur über SSL zugegriffen wird, sind wir fertig. Wenn es über einfaches HTTP verfügbar ist, möchten wir dieses permanente Zugriffstoken auf irgendeine Weise schützen. Jeder, der an der Verbindung schnüffelt, kann für immer auf den Inhalt des Benutzers zugreifen.

Die Lösung in OAuth 2 erfolgt mit einem Aktualisierungstoken . Das Aktualisierungstoken wird zum permanenten Kennwortäquivalent und wird immer nur über SSL übertragen . Wenn der Server Zugriff auf den Inhaltsdienst benötigt, tauscht er das Aktualisierungstoken gegen ein kurzlebiges Zugriffstoken aus. Auf diese Weise werden alle schnüffelbaren HTTP-Zugriffe mit einem Token ausgeführt, das abläuft. Google verwendet für seine OAuth 2-APIs einen Ablauf von 5 Minuten.

Abgesehen von den Aktualisierungstoken vereinfacht OAuth 2 die gesamte Kommunikation zwischen Client, Server und Inhaltsanbieter. Die Aktualisierungstoken sind nur vorhanden, um Sicherheit zu bieten, wenn unverschlüsselt auf Inhalte zugegriffen wird.

Zweibeinige Authentifizierung

Manchmal muss ein Server jedoch nur den Zugriff auf seinen eigenen Inhalt steuern. Durch die zweibeinige Authentifizierung kann der Client den Benutzer direkt beim Server authentifizieren.

OAuth 2 standardisiert einige Erweiterungen von OAuth 1, die weit verbreitet waren. Die, die ich am besten kenne, wurde von Twitter als xAuth eingeführt . Sie können es in OAuth 2 als Kennwortanmeldeinformationen für Ressourcenbesitzer anzeigen .

Wenn Sie dem Client die Anmeldeinformationen des Benutzers (Benutzername und Kennwort) anvertrauen können, können diese diese im Wesentlichen direkt mit dem Inhaltsanbieter gegen ein Zugriffstoken austauschen. Dies macht OAuth für mobile Apps viel nützlicher. Bei der dreibeinigen Authentifizierung müssen Sie eine HTTP-Ansicht einbetten, um den Autorisierungsprozess mit dem Inhaltsserver abzuwickeln.

Bei OAuth 1 war dies nicht Teil des offiziellen Standards und erforderte dasselbe Signaturverfahren wie alle anderen Anforderungen.

Ich habe gerade die Serverseite von OAuth 2 mit Kennwortanmeldeinformationen für Ressourceneigentümer implementiert, und aus Sicht eines Clients ist das Abrufen des Zugriffstokens einfach geworden: Fordern Sie ein Zugriffstoken vom Server an und übergeben Sie die Client-ID / das Client-Geheimnis als HTTP-Autorisierungsheader und das Login / Passwort des Benutzers als Formulardaten.

Vorteil: Einfachheit

Aus Sicht eines Implementierers sind die Hauptvorteile, die ich in OAuth 2 sehe, die geringere Komplexität. Das Anforderungssignierungsverfahren ist nicht erforderlich, was nicht gerade schwierig, aber sicherlich umständlich ist. Dies reduziert den Arbeitsaufwand als Kunde eines Dienstes erheblich. Hier möchten Sie (in der modernen, mobilen Welt) die Schmerzen am meisten minimieren. Die reduzierte Komplexität auf der Seite des Server-> Inhaltsanbieters macht es im Rechenzentrum skalierbarer.

Und es kodifiziert einige Erweiterungen von OAuth 1.0a (wie xAuth) in den Standard, die jetzt weit verbreitet sind.

Erstens, wie in der OAuth-Authentifizierung deutlich angegeben

OAuth 2.0 ist kein Authentifizierungsprotokoll.

Die Authentifizierung im Kontext eines Benutzers, der auf eine Anwendung zugreift, teilt einer Anwendung mit, wer der aktuelle Benutzer ist und ob er vorhanden ist oder nicht. Ein vollständiges Authentifizierungsprotokoll enthält wahrscheinlich auch eine Reihe von Attributen zu diesem Benutzer, z. B. eine eindeutige Kennung, eine E-Mail-Adresse und den Namen, wenn die Anwendung "Guten Morgen" sagt.

OAuth teilt der Anwendung jedoch nichts davon mit. OAuth sagt absolut nichts über den Benutzer aus, noch sagt es aus, wie der Benutzer seine Anwesenheit bewiesen hat oder ob er noch da ist. Was einen OAuth-Client betrifft, hat er nach einem Token gefragt, ein Token erhalten und dieses Token schließlich verwendet, um auf eine API zuzugreifen. Es weiß nichts darüber, wer die Anwendung autorisiert hat oder ob überhaupt ein Benutzer dort war.

Es gibt einen Standard für die Benutzerauthentifizierung mit OAuth: OpenID Connect, kompatibel mit OAuth2.

Das OpenID Connect ID-Token ist ein signiertes JSON-Web-Token (JWT), das der Clientanwendung zusammen mit dem regulären OAuth-Zugriffstoken übergeben wird. Das ID-Token enthält eine Reihe von Ansprüchen bezüglich der Authentifizierungssitzung, einschließlich einer Kennung für den Benutzer (Sub), der Kennung für den Identitätsanbieter, der das Token ausgestellt hat (iss), und der Kennung des Clients, für den dieses Token erstellt wurde ( aud).

In Go können Sie sich Coreos / Dex, einen OpenID Connect Identity (OIDC) und einen OAuth 2.0-Anbieter mit steckbarem Connector ansehen.

Antwort von diesem Beitrag vonc

Ich würde diese Frage etwas anders beantworten, und ich werde sehr präzise und kurz sein, hauptsächlich weil @Peter T alles beantwortet hat.

Der Hauptgewinn, den ich aus diesem Standard sehe, besteht darin, zwei Prinzipien zu respektieren:

1. Trennung von Bedenken.
2. Entkopplung der Authentifizierung von der Webanwendung, die normalerweise dem Geschäft dient.

Auf diese Weise

1. Sie können eine Alternative zu Single SignOn implementieren: Wenn Sie mehrere Anwendungen haben, die einem STS vertrauen. Was ich meine, ein Benutzername für alle Anwendungen.
2. Sie können Ihrer Webanwendung (dem Client) den Zugriff auf Ressourcen ermöglichen, die dem Benutzer und nicht der Webanwendung (dem Client) gehören.
3. Sie können den Authentifizierungsprozess an einen vertrauenswürdigen Dritten übertragen, ohne sich Gedanken über die Überprüfung der Benutzerauthentizität machen zu müssen.