Verwendung von OAuth mit Forms auth

Wir machen das tatsächlich bei unserem Projekt. Die Lösung war wirklich einfach. Hier waren die wichtigsten Punkte

• Beachten Sie, dass die OAuth-Spezifikation empfiehlt, das OAuth-Bearer-Token nicht auf dem Client zu speichern.
• Stellen Sie sicher, dass der Anwendungsserver die Authentifizierungsanforderungen an den oauth-Provider sendet. Tun Sie es nicht vom Client (außer im Autorisierungsschritt, weil Sie wirklich keine Wahl haben).
• Nutzen Sie das Framework. Lassen Sie den Mitgliedschaftsanbieter das Authentifizierungsticket verwalten.
• Erstellen Sie Ihren benutzerdefinierten Mitgliedschaftsanbieter und lassen Sie ihn den Authentifizierungsprozess mit Ihrem Drittanbieter verwalten.
• Sobald die Authentifizierung erfolgreich ist, speichern Sie die Tokens in der Sitzung oder in einem Fall mit der Benutzeridentität. Mit anderen Worten, behalte die Zugriffs- und Aktualisierungstoken auf dem Server.
• Ermöglichen Sie dem Framework, das Authentifizierungsticket wie normalerweise
zu generieren
• Zwischen dem Authentifizierungsticket und dem Sitzungscookie können Sie das Zugriffstoken aus der Sitzung / dem Antrag abrufen, um Ressourcenanforderungen zu stellen.
• Wenn Sie den 3rd-Party-Login zuordnen, müssen Sie einen Anruf mit dem Zugriffstoken an den Provider machen, um Informationen wie eine Facebook-Benutzer-ID zu erhalten. Verwenden Sie das, um Ihren internen Benutzer mit dem Facebook-Benutzer zu verknüpfen.

Andere Dinge zu beachten:

• Stellen Sie sicher, dass Sie die Sitzung beim Abmelden zerstören. Mehrere Frameworks löschen die Cookie-Werte, recyceln jedoch die Session-ID. Stellen Sie sicher, dass die Sitzungs-ID nicht wiederverwendet wird.
• Verwenden Sie ein Anti-Fälschungs-Token mit jeder Anfrage, die Session-Informationen benötigt, die eigentlich alles beinhalten sollten. Dadurch können Sie sicherstellen, dass der Sitzungscookie nicht entführt wurde.

Nun, ich denke, das ist ein wichtiger Punkt: Normalerweise verwenden Sie bei Anbietern wie Facebook und Twitter den Autorisierungsfluss, was bedeutet, dass Sie ihr Formular verwenden müssen, um sich anzumelden. Sie gehen damit um, nicht du. Es gibt einen Benutzernamen / ein Passwort "option" (grant_type: password) mit OAuth 2.0, aber ich weiß nicht, ob diese Provider es zulassen, da dieser Flow die Anwendung nicht benötigt, um sich zu identifizieren.

Ich denke, Sie haben es ziemlich gut verstanden. Der Ablauf der Autorisierungsgewährung würde etwa so aussehen:

Der Ablauf für die Passwortvergabe wäre ziemlich gleich, aber ohne die Schritte Weiterleitung und Autorisierung. Sie würden sich einfach mit Ihrem eigenen Formular anmelden und den Server dazu veranlassen, die Authentifizierungsanfrage an den Provider zu stellen, indem Sie den Passwort-Berechtigungstyp verwenden.

Wenn Sie es nur für die Authentifizierung verwenden, würden Sie mit diesem bestimmten Zugriffstoken keine Anfrage an seinen Ressourcenserver stellen. Ich müsste mehr über Ihre Architektur wissen, um mehr zu sagen. Wenn Sie jedoch einen internen Identitätsanbieter haben, der Rollen und Identität verarbeitet, können Sie einen Anbieter für Verbundidentitäten in Betracht ziehen, der Token von Drittanbietern in Ihr internes Format umwandeln und zusammen mit dem Token von Drittanbietern speichern kann. Auf diese Weise können Sie bei Bedarf noch Anfragen an die Drittpartei stellen und haben immer noch das, was Sie benötigen, um sich intern zu bewegen, wenn das sinnvoll ist. Wenn das überhaupt ein Problem ist, lassen Sie es mich wissen und ich werde das Bein auch erklären.