Also. Ich habe Domäne A.com, von denen die Benutzerauthentifizierung bei Domäne B.com erfolgt. Derzeit habe ich es so eingerichtet, dass das Login-Formular auf B.com gepostet wird, was (wenn erfolgreich) den Sitzungscookie setzt und eine Weiterleitung an A.com/loggedin auslöst. Da das Formular jedoch an B.com gesendet wird und der Cookie auf diese Domäne eingestellt ist, ist der Sitzungscookie bei einer JSON-Anfrage von A.com nicht verfügbar und ich habe keine Ahnung, ob er angemeldet ist oder nicht. Die Frage wird dann, wie man das Problem löst?
Ich habe über eine Lösung nachgedacht, bei der ich ein Token zum Umleitungs-URI hinzufügen würde, das dann für die einmalige authentifizierte Sitzungserstellung mit A.com verwendet werden könnte (der Browser könnte dieses Token verwenden, um die Sitzung mit B zu autorisieren) .com, so dass der Cookie auf A.com gesetzt würde und bei JSON-Anfragen verfügbar wäre. Danach würde das Token vonc) ungültig gemacht werden.
Allerdings bin ich mir nicht sicher, wie sicher diese Lösung wäre? Oder gibt es eine andere sicherere Lösung?
Ihre aktuelle Lösung sieht gut aus und kann in diesem Szenario verwendet werden. Aber aus Sicherheitsgründen sollten Sie, statt ein einfaches Token bereitzustellen, dieses mit einer guten Verschlüsselungsmethode verschlüsseln und basierend darauf können Sie Ihre Server so konfigurieren, dass sie das authentication token verschlüsseln und entschlüsseln, bevor Sie es verwenden. Die einzige Sache ist, dass Sie den besten Algorithmus für Ihren Fall wählen müssen.
Abgesehen von dieser Lösung können Sie Session-Management-Tools überlegen. Session Migration , Session Replication und Session Sharing sind die Optionen, die ich mir vorstellen kann.
Hier finden Sie Link für eine bereitgestellte Lösung von Oracle für Session-Sharing, was meiner Meinung nach in Ihrem Fall helfen kann.
Security Assertion Markup Language (SAML, ausgesprochen "sam-el" [1]) ist ein XML-basiertes offenes Standard-Datenformat zum Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Parteien, insbesondere zwischen einem Identity Provider und einem Service Provider. SAML ist ein Produkt des OASIS Security Services Technical Committee. SAML stammt aus dem Jahr 2001; Das neueste Update von SAML stammt aus 2005.
Die wichtigste Anforderung, die an SAML-Adressen gestellt wird, ist das Single Sign-On (SSO) für Webbrowser. Single-Sign-On-Lösungen sind auf der Intranet-Ebene üblich (z. B. durch Verwendung von Cookies), die Ausweitung dieser Lösungen über das Intranet war jedoch problematisch und hat zur Verbreitung nicht-kompatibler proprietärer Technologien geführt. (Ein anderer neuerer Ansatz zur Adressierung des Browser-SSO-Problems ist das OpenID-Protokoll.) Die SAML-Spezifikation definiert drei Rollen: den Prinzipal (in der Regel ein Benutzer), den Identitätsanbieter (IdP) und den Serviceanbieter (SP). In dem von SAML adressierten Anwendungsfall fordert der Prinzipal einen Dienst vom Dienstanbieter an. Der Dienstanbieter fordert eine Identitätszusicherung vom Identitätsprovider an und erhält sie. Auf der Grundlage dieser Behauptung kann der Dienstanbieter eine Zugriffskontrollentscheidung treffen - mit anderen Worten kann er entscheiden, ob er einen Dienst für den verbundenen Prinzipal ausführt.
Bevor die Identitätsbestätigung an den SP übermittelt wird, kann der IdP einige Informationen vom Principal anfordern - wie zum Beispiel einen Benutzernamen und ein Passwort -, um den Principal zu authentifizieren. SAML spezifiziert die Behauptungen zwischen den drei Parteien: insbesondere die Nachrichten, die die Identität behaupten, die von dem IdP an den SP übergeben werden. In SAML kann ein Identitätsanbieter SAML-Zusicherungen für viele Dienstanbieter bereitstellen. Umgekehrt kann sich ein SP auf Behauptungen von vielen unabhängigen IdPs verlassen und darauf vertrauen. SAML gibt die Authentifizierungsmethode beim Identity-Provider nicht an. Es kann einen Benutzernamen und ein Passwort oder eine andere Form der Authentifizierung einschließlich der Multi-Faktor-Authentifizierung verwenden. Ein Verzeichnisdienst, der es Benutzern ermöglicht, sich mit einem Benutzernamen und einem Passwort anzumelden, ist eine typische Quelle von Authentifizierungs-Tokens (z. B. Passwörtern) bei einem Identitätsanbieter. Die populären allgemeinen Internet-Sozialnetzwerkdienste stellen auch Identitätsdienste zur Verfügung, die theoretisch benutzt werden könnten, um SAML Austausch zu unterstützen.
Ja, es gibt sicherere Optionen.
Für Single Sign On gibt es einen offenen Standard namens OpenID / connect (aufgebaut auf oAuth2.0) Für die gemeinsame Nutzung von Ressourcen, Autorisierung und Authentifizierung gibt es oAuth.
Dinge zu beachten.
Nutzen Sie die bereits von der Community geleistete Arbeit.
oAuth 1.0a (immer noch weitestgehend als sicherstes Muster akzeptiert) - Ссылка oAuth 2 - Ссылка (mit openID zur Autorisierung auf oAuth2)
oAuth 2 ist kein Ersatz für oAuth 1a - es ist eine völlig neue (weniger sichere) Idee, die stark von SSL abhängig ist - oAuth1a ist immer noch die sicherste - aber immer noch nur so gut wie Ihre Umsetzung und das Verständnis für mögliche Schwächen.
Sie suchen wahrscheinlich nach openID connect Ideen - aber oAuth info ist auch nützlich ...
SO - Ausgangspunkt einiger Unterschiede
Die Verwendung eines Authentifizierungstokens sollte gut funktionieren, berücksichtigen Sie jedoch diese Punkte:
Diese beiden Punkte sind meiner Meinung nach sehr kritisch, um zu verhindern, dass das Authentifizierungs-Token entwendet und wiederverwendet wird. Begrenzen Sie auch die Zeit, die das Token gültig ist (30 Sekunden sollten in Ordnung sein), um den Missbrauch alter / unbenutzter Tokens zu verhindern.
Tags und Links security session authentication