Ich habe ein paar Verwirrungen über OAuth-bezogene Themen und ich hoffe, dass jemand mir helfen kann, sie zu klären :) Fühlen Sie sich frei, mich an irgendeinem Punkt zu korrigieren, wo ich daneben bin.
Sagen wir also, dass meine Web-Firma eine Reihe von Websites auf verschiedenen Domains betreibt:
Nehmen wir an, es handelt sich um E-Commerce-Sites, auf denen soziale Netzwerke enthalten sind. Es gibt also Benutzerkonten mit verschiedenen gespeicherten Datenpunkten. Also hat meine Firma (nennen wir es ACME E-Commerce) alle diese Seiten für verschiedene Kunden erstellt und verwaltet.
Jetzt entscheiden wir uns, dass es für alle unsere E-Commerce-Websites bequem wäre, ein zentrales Konto zu haben; Zu den Vorteilen zählen die Verringerung der Reibungsverluste, da Kunden ihr vorhandenes Konto für die Anmeldung an einem der Standorte nutzen können, sowie die Zentralisierung von Informationen, um die Marketinggenauigkeit zu verbessern und die übermäßige Kommunikation mit den Kunden zu reduzieren. Geben Sie OAuth ein!
Wie ich aus einigen Lektüren verstehe, ist OAuth ein Authentifizierungs und Autorisierungs Standard. Authentifizierung ist "Login" und Berechtigung "Sie können diese API-Aufrufe machen", kurz und knapp, richtig? Beginnen wir mit der Authentifizierung:
AUTHENTIFIZIERUNG!
Die Idee hier ist, dass Sie auf socks.com gehen und wenn Sie sich normalerweise einloggen würden, gibt es einen "Login mit ACME ID" Button, sowie "Login To Socks.com". Du siehst das überall: Login mit Facebook, Login mit Google, etc. So haben wir "Login mit ACME ID".
Wenn der Benutzer auf "Mit ACME-ID anmelden" klickt, fordert socks.com ein unautorisiertes Anforderungs-Token an und empfängt es direkt vom OAuth-Server von ACME. Anschließend leitet es den Browser des Benutzers an die OAuth-Site von ACME weiter. Dort fügt der Benutzer den Benutzernamen und das Passwort für sein ACME-ID-Konto ein, und ACME OAuth autorisiert das Anfrage-Token und sendet es über eine Weiterleitungs-URL an socks.com zurück.
Zu diesem Zeitpunkt weiß Socks.com, dass der Benutzer bei ACME ID angemeldet ist. Wenn Socks.com Informationen aus der Ressourcen-API von ACME abfragen wollte, würde es sein autorisiertes Anforderungs-Token gegen ein Zugriffstoken austauschen und dann Anrufe tätigen, aber wir sprechen nur über die Authentifizierung und der Benutzer hat sich authentifiziert. Richtig?
Angenommen, ich habe das Recht, und selbst wenn ich etwas falsch liege, was macht Socks.com an dieser Stelle? Da es in diesem Szenario eine eigene Datenbank mit Benutzern hat, synchronisiert es diese zentrale OAuth-Authentifizierung mit seiner eigenen Datenbank? Socks.com weiß nun, dass [email protected] angemeldet ist, und fragt seine Datenbank nach dieser E-Mail-Adresse, um seine Kaufhistorie und den letzten Warenkorbinhalt zu erhalten? Es behält eine Sitzung für Joe bei, und wenn diese Sitzung abläuft, muss er sich wieder mit seiner ACME ID authentifizieren?
Ich weiß, dass Spotify so etwas macht; Sie haben "Anmelden mit Facebook". Wenn ich diese Option wähle, erscheint ein kleines Browserfenster auf der Facebook-Domain mit einem Login-Fenster. Ich logge mich ein, das Popup wird geschlossen und Spotify zeigt mich als eingeloggt ... mit meiner Facebook-E-Mail-Adresse und einem Kontonamen, der aus 8 oder so zufälligen Zahlen besteht. Das sieht so aus, als ob Spotify sieht, dass ich mich mit dem OAuth-Server von Facebook authentifiziert habe, und dann ein neues Konto für mich in ihrem eigenen System erstellt habe. Nachfolgende Facebook-OAuth-Authentifizierungen / Logins würden mich jedes Mal in denselben Spotify-Account werfen.
Was, wenn überhaupt, habe ich hier falsch?
Mit einem zentralen Authentifizierungs-Setup mit ACME ID können wir also Nutzern erlauben, sich mit derselben ID bei socks.com, boats.com und cakes.com anzumelden, und wir werden an jedem Standort für sie Accounts erstellen. Dies ist die Reibungsverminderung in Aktion, aber Adressen und Kreditkartendaten werden immer noch getrennt gespeichert, so dass wir nicht die Vorteile einer Zentralisierung erhalten. Dies geht jedoch über die Authentifizierung hinaus, wir sind in der Autorisierung!
AUTORISIERUNG!
Wir machen also ein wenig Kontodaten-Umstrukturierung und verschieben die Adress- und Kreditkartendaten aller Kunden in ihre zentralen ACME-ID-Konten. Wir richten eine API zum Anfordern und Ändern dieser Informationen ein. Wenn sich cakes.com nun mit der ACME-ID authentifiziert und sein autorisiertes Anforderungs-Token erhält, wird dieses Token an den ACME-OAuth-Server für ein Zugriffstoken an die API ausgetauscht. (Dies wird serverseitig in den Sitzungsdaten des Benutzers oder etwas gespeichert.)
Wenn der Benutzer nun auf cakes.com zur Kasse geht, können wir einen API-Aufruf an den ACME-Ressourcen-Server senden und den ACME-ID-Benutzernamen übergeben, um ein Array der Kundenadressen abzurufen und dann a zu verwenden Website. Hey, das ist ein guter Service! Cakes.com ist autorisiert durch das OAuth-Verfahren, um so etwas zu tun.
Habe ich alles genau hier?
RANDFÄLLE!
Die obige Implementierung von E-Commerce-Sites mit einem zentralen OAuth-Server ist ziemlich eindeutig, aber es gibt einige "Edge Cases", bei denen Dinge auf verschiedene Arten implementiert werden könnten:
1) Keine verteilten Benutzerkonten
Was ist, wenn ich alle Benutzer von socks.com, boats.com und cakes.com zwingen möchte, sich nur mit einer ACME ID anzumelden? Vielleicht wäre es ein "Benutzerkonto" auf jeder dieser Seiten, mit Kaufdaten und Adressdaten und so weiter, mit einem assoziierten Benutzernamen, aber keinem Passwort und keinem tatsächlichen Login-Mechanismus. Die Sitzung wird als "angemeldet" markiert, sobald die ACME ID authentifiziert wurde.
Oder vielleicht werden alle Informationen wie Kaufhistorie, Adressen und CC-Nummern zum Endpunkt der ACME-Ressource zusammengefasst, und auf den Satelliten-E-Commerce-Websites werden keine Informationen über den Kunden gespeichert? Nun, dann sind die Satelliten im Grunde genommen Slaves, die das ACME OAuth als entfernte Datenbank benutzen. Da die Kaufhistorie zentralisiert ist, müssen Sie Ihre Artikel mehr oder weniger zentralisieren, und dann würde es vielleicht auf "was ist nicht zentralisiert?" und "warum haben wir separate Websites" - außer sie müssen getrennt sein.
Also, irgendein Verdienst dafür?
2) Benutzeroberfläche-weniger Web-API für Mobile App
Nehmen wir an, Sie bauen ein iOS / Android / etc. App namens Horses, und Sie müssen einige Informationen in der Cloud über Ihre Benutzer speichern, insbesondere welche Pferde sie wirklich mögen. Trotz der Meinung, dass irgendjemand haben könnte, dass Pferde von Socken, Booten und Kuchen getrennt sind, möchten Sie Ihren Benutzern erlauben, sich mit ihrer ACME ID und einer Pferde-ID, die Sie erfinden, anzumelden.
Sie gehen jetzt im Grunde von einem Satellite-Benutzeraccount-System auf einer www.horses.com-Domain aus und erlauben optional der Person, sich mit ACME ID anzumelden und gnädig ein horses.com-Konto zu erstellen, damit sie es speichern können horses.com-bezogene Daten. Ziemlich Standard; Der einzige Unterschied ist, dass Sie nicht wirklich eine Website erstellen müssen, es ist nur eine API.
Aber was, wenn Sie nur ACME ID als Login zulassen wollten, kein horses.com Account? Wenn Sie also zur Anmeldung gehen, würde Ihre horses.com-API den OAuth-Tanz mit ACME OAuth initiieren, authentifizieren und dann einen Zugriffstoken (für horses.com) an die App übermitteln. Mit diesem Zugriffstoken werden Lese- und Schreib-API-Aufrufe an horses.com basierend auf den Pferden, die Ihr Nutzer in der App mag, durchgeführt. Bin ich hier in der richtigen Stimmung?
3) Zentrale Authentifizierung für den Zugriff auf mehrere Sites
Nehmen wir dieses Setup: ACME ID enthält Benutzername, Passwort, E-Mail, Kreditkarte & amp; Abrechnungsdaten. Socks.com, boats.com und cakes.com haben eine Kaufhistorie sowie soziale Informationen darüber, welche sockenbezogenen, bootbezogenen oder kuchenbezogenen (bzw. jeweiligen) Dinge die Person auf diesen Websites getan hat.
Nun möchten wir eine mobile App erstellen, die sich mit der ACME ID authentifiziert und Informationen aus der Ressourcen-API von ACME ID (für CC- und Verrechnungsdaten) sowie von allen Websites abrufen kann, die sich mit der ACME-ID authentifizieren. Auf diese Weise können wir Socken, Boote und Kuchen perfekt miteinander kombinieren und dann können wir den Kunden dafür bezahlen! (Sie bekommen die Idee.)
Also ... wie könnte das möglich sein?
Danke fürs Lesen!
OAuth 2.0 ist eine Spezifikation für die Autorisierung, aber NICHT für die Authentifizierung. RFC 6749, 3.1. Autorisierungs-Endpunkt sagt explizit Folgendes:
Der Autorisierungsendpunkt wird verwendet, um mit dem Ressourcenbesitzer zu interagieren und erhalte eine Autorisierungsgewährung. Der Autorisierungsserver MUSS Überprüfen Sie zuerst die Identität des Ressourcenbesitzers. Die Art und Weise, in der der Autorisierungsserver authentifiziert den Ressourcenbesitzer (z.B. Benutzername und Passwort Login, Session - Cookies) ist über den Rahmen der Diese Spezifikation.
Authentifizierung behandelt Informationen darüber, "wer man ist". Die Autorisierung behandelt Informationen darüber, wer wem welche Berechtigungen gewährt. Der Autorisierungsablauf enthält die Authentifizierung als ersten Schritt. Es ist der Grund, warum Menschen oft verwirrt sind.
Es gibt viele Bibliotheken und Dienste, die OAuth 2.0 zur Authentifizierung verwenden. Es macht die Leute viel verwirrter. Wenn Sie "OAuth-Authentifizierung" (nicht "OAuth-Autorisierung") sehen, ist dies eine Lösung, die OAuth für die Authentifizierung verwendet.
Eine ideale OAuth-Server-Implementierung trennt die Autorisierung eindeutig von der Authentifizierung. Eine solche Implementierung erfordert nur eine eindeutige Kennung des Endbenutzers, um ein Zugriffstoken auszugeben, benötigt jedoch (ID) und Passwort überhaupt nicht. Eine solche Implementierung interessiert sich nicht dafür, wie eindeutige Identifikatoren bestimmt werden. Mit anderen Worten, es interessiert nicht, wie Endbenutzer authentifiziert werden. Es erfordert nur eine eindeutige Kennung, die als Ergebnis der Endbenutzerauthentifizierung ermittelt wird.
Es ist schwierig, einen solchen idealen OAuth-Server zu entwerfen und zu implementieren, aber es ist machbar und es gibt mindestens eine kommerzielle Implementierung.
Wenn es Ihrem OAuth-Server egal ist, wie Endbenutzer überhaupt authentifiziert werden (= wenn Ihr OAuth-Server Autorisierung eindeutig von Authentifizierung unterscheidet), können Sie Ihr gesamtes System flexibler gestalten und wahrscheinlich tun, was Sie wollen.
Tags und Links oauth api authentication website user-accounts