Zunächst einmal sollten wir uns darüber im Klaren sein, dass OAuth und OpenID zwei verschiedene Dinge sind. OpenID ist gedacht für nur Authentifizierung . OAuth ist für die Authentifizierung und Autorisierung gedacht. In diesem Fall bezieht sich die Autorisierung auf die Idee, dass eine Client-Anwendung autorisiert um auf die einem authentifizierten Benutzer zugeordneten Daten zuzugreifen und diese zu aktualisieren.
Ich möchte, dass sich die Websites von Drittanbietern bei einem Benutzerkonto auf der Website anmelden können, aber nur Daten lesen und schreiben, die ihnen gehören, und nicht auf Daten zugreifen können, die anderen Websites von Drittanbietern gehören.
Wenn sich die Daten, die auf den Websites von Drittanbietern gespeichert sind, und die auf Ihrem Authentifizierungsserver gespeicherten Daten gegenseitig ausschließen, sollten Sie bei OpenID bleiben.
Wenn Sie jedoch möchten, dass Ihre Drittanbieter-Websites Informationen über den Benutzer aktualisieren, die an alle anderen Drittanbieter-Websites weitergegeben werden sollen (d. h. Vorname, Nachname, Adresse, Kreditkarteninformationen usw.), dann sollten Sie OAuth verwenden. Ich bin mir bewusst, dass es eine Erweiterung der OpenID-Spezifikation gibt, die diese Art von Dingen ermöglicht (und in der Tat können Sie diese an Ihre eigene Implementierung anpassen), aber im allgemeinen Sinne gehört diese Art von Dingen in OAuth.
Ich bin etwas verwirrt über die Details der oAuth. Muss ich eine Art API erstellen oder ist oAuth das einzige, was ich implementieren muss?
Neben den anfänglichen Details der Token-Anforderung und der Autorisierung der Client-Anwendung durch den OAuth-Server müssen Sie zusätzliche Methoden zum Abrufen und Aktualisieren von Informationen über den authentifizierten Benutzer implementieren. Bei Twitter beispielsweise muss Ihre Anwendung mit einem bestimmten Benutzer authentifiziert und autorisiert sein, den Status des Benutzers zu aktualisieren. Diese Methode zur Statusaktualisierung ist Teil der API von Twitter, zusätzlich zur OAuth-Basisimplementierung.
Wenn ich oAuth implementiere, werden andere Dritte Websites von Drittanbietern auf die Daten der Website zugreifen? Hält jemand dass dies eine schlechte Idee ist? ja/nein und warum?
Diese Websites können nur auf die Daten des Benutzers zugreifen, der sich bei Ihrem OAuth-Server authentifiziert hat. et diese Website zum Zugriff auf ihre Daten ermächtigt haben. Allerdings können nur die Websites mit einem gültigen Consumer Key die richtigen Token anfordern, um eine OAuth-Sitzung zu beginnen. Daher können nur die Websites, die Sie autorisiert haben, mit Ihrem Server interagieren.
Es besteht immer die Möglichkeit, dass diese Token durch Fixierung der Sitzung . Aber diese Sorge sollte Sie nicht davon abhalten, Ihren OAuth-Dienst zu implementieren. Das heißt nicht, dass Sie sich keine Gedanken darüber machen müssen. Lassen Sie es nur nicht zu einem Hindernis werden.
Kann ich zulassen, dass andere Websites von Drittanbietern den Benutzer auf der Hauptwebsite registrieren, ohne dass der Benutzer die Hauptwebsite besuchen muss?
Nicht mit der aktuellen Spezifikation, wie sie von OAuth definiert wurde. Die Idee hinter OAuth ist, dass sich Ihre Benutzer beim OAuth-Server registrieren. Ihre Drittanbieter-Clients verwenden diesen Server als Authentifizierungspunkt. Das bedeutet jedoch nicht, dass Sie nicht eine Art API implementieren können, um einen Benutzer zu registrieren, wenn die Anwendung über eine Art "Master"-Konto verfügt, mit dem er sich anmelden kann (obwohl dies ein eigenes Sicherheitsrisiko darstellt). Es wird nur nicht empfohlen.
Und wie kann ich mit oAuth sicherstellen, dass eine Website eines Drittanbieters keine Benutzerdaten einer anderen Website eines Drittanbieters liest/schreibt/verändert?
Nur weil Sie OAuth verwenden, bedeutet das nicht, dass Ihre Websites von Drittanbietern keine Daten in ihren eigenen Datenspeichern speichern können. Sowohl Flickr als auch Twitter bieten OAuth-Dienste an, aber keiner von beiden speichert die Informationen des anderen auf seinen Servern (keine Flickr-Fotos werden in den Datenbanken von Twitter gespeichert).
Solange Sie die anwendungsspezifischen Informationen nicht auf Ihrem OAuth-Server speichern, sollten Sie keine Probleme haben. Denken Sie daran, dass der OAuth-Server dazu da ist, Benutzer zu authentifizieren und die grundlegenden Informationen zu speichern, die von ALLEN Anwendungen gemeinsam genutzt werden sollten. Ich wiederhole hier noch einmal: Wenn Sie nur den Benutzer authentifizieren wollen, dann bleiben Sie bei OpenID.
Editar
Kann ich die Berechtigungen so aufteilen, dass der Benutzer, wenn er Site A autorisiert, diese nicht für sein gesamtes Konto autorisiert, sondern nur für den Zugriff auf seine eigenen Daten in seinem Konto? Kann oAuth dies tun?
In Ihrer Implementierung können Sie. Es wäre eine Frage der Überprüfung des Verbraucherschlüssels, der mit dem Zugriffstoken verbunden ist, das für den Zugriff auf diesen OAuth-Endpunkt verwendet wird. Denken Sie daran, dass jeder Aufruf des autorisierten Teils Ihrer API ein Zugriffs-Token enthalten muss. Wenn Sie also diesen Endpunkt für eine bestimmte Anwendung sperren wollen, ist es sinnvoll, ihn anhand des Zugriffstokens und des Verbraucherschlüssels zu überprüfen.
