OpenID Connect hat eine Spezifikation , es gibt Tutorials, Artikel auf dem Hub und nicht auf dem Hub Es ist ziemlich sinnlos, eine weitere Schritt-für-Schritt-Anleitung zu erstellen, die von tiefer Verwirrung bis zur Bearbeitung von Autorisierung und Authentifizierung führt. Die Aufgabe des folgenden Textes ist anders, die Ideen zu beschreiben, die den Spezifikationen zugrunde liegen (es gibt mehr als eine).
Ich werde nicht sofort auf das Thema des Artikels eingehen, aber ich werde mit einfachen und vielen offensichtlichen Dingen beginnen. Ich werde mit der Art und Weise fortfahren, wie sie sich entwickelt haben und was sie gemäß den Anforderungen der Kunden verpackt haben. Ich werde mich ihm historisch nähern, das heißt genau so, wie er geboren wurde.
1.
Die Mindestaufgabe besteht einfach darin, niemanden auf seine Ressourcen zugreifen zu lassen. Wir schließen es mit Benutzername / Passwort. Wer weiß, dass das richtige Paar von Benutzernamen und Passwörtern an die Ressource gelangt, wer nicht - nein. Diese Funktion wird als Authentifizierung bezeichnet . Sie können nicht nur Anmeldungen mit Kennwörtern (z. B. SMS-Code oder Hardware-USB-Stick) verwenden, sondern diese Details sind für unser Thema nicht unbedingt erforderlich. Ich werde auch den obligatorischen Absatz über die Gefahr der Übertragung von Passwörtern über das Internet in offener Form weglassen, für den wir alle die Standardzugriffsauthentifizierung nicht mögen.
Besser zu beachten: Keiner der Benutzer gibt gerne Anmeldungen mit Passwörtern ein. Codes in SMS sind nicht besser und USB-Sticks werden einfach überhaupt gehasst. Um den Benutzer nicht zu zwingen, für jede Anforderung ein Login mit einem Kennwort einzugeben, sendet der Server als Antwort darauf eine Kauderwelschzeile, die als Sitzungsschlüssel bezeichnet wird . Und dann klammert sich dieser Schlüssel an jede Serveranforderung des Clients (normalerweise mit einem HTTP-Header, aber dies ist nicht unbedingt erforderlich), und der Server prüft, ob er eine solche Sitzung hat.
Sitzung mit einem Schlüssel - Phänomene sind per Definition vorübergehend, der goldene Schnitt für die Lebensdauer einer Sitzung beträgt ungefähr "während die Browser-Registerkarte geöffnet ist, aber nicht länger als einen Tag".
2.
Sie lassen jeden rein - das ist gut. Jetzt müssen Sie genau verstehen, wen wir loslassen. Und nicht nur, um abzuleiten, was er als Namen in der oberen rechten Ecke eingegeben hat, sondern auch um zu entscheiden, was er hereinlassen soll und was nicht.
Und das alles nennt man - Autorisierung . Und ich bin mir nicht sicher, aber ich verwechsle es die ganze Zeit mit der Authentifizierung. Um nicht - eine relativ mnemonische Regel, "Autorisierung" - von den Wörtern "Autor", "Autor" zu verwechseln, schreiben sie auf die Titelseiten von Büchern und schreiben dort niemals "ein gültiges Mitglied der Writers 'Union". Ein Autor ist immer eine ganz bestimmte Person. Die Autorisierung ist also ein Prozess, bei dem wir anhand von Login und Passwort verstehen, wen wir genau gestartet haben.
3.
Ok Wir haben eine Site, es gibt etwas Geheimnisvolles auf der Site, am Eingang zum geheimen Teil benötigen wir ein Passwort, jedem werden nur seine Geheimnisse gezeigt und wir zeigen keine Fremden. Das Leben steht nicht still und wir haben eine andere Seite. Und hier stoßen wir wieder auf das Problem ab Punkt 1, niemand gibt gerne Benutzernamen und Passwörter ein! Sie können die Benutzerbasis kombinieren, damit sie sich nicht zweimal registrieren müssen. Wie können Sie sie jedoch vor der erneuten Eingabe des Logins und des Passworts am Eingang bewahren? Angesichts der Existenz einer Richtlinie für denselben Ursprung (und unsere Websites befinden sich natürlich in verschiedenen Domänen, sind Cookies mit einem Sitzungsschlüssel für einander nicht sichtbar)? Um dem Moment Bedeutung zu verleihen, werde ich hier einen neuen Punkt beginnen.
4.
SSO , Single Sign On - unabhängig von der Implementierung, Microsoft Kerberos, SAML oder etwas OAuth 2.0 , auf dem OpenID Connect basiert, worüber ich Ihnen hier schreibe, gibt es unter der Haube immer das Gleiche: Es gibt einen separaten Server Autorisierung , und jeder, der einen Benutzer autorisieren möchte, leitet den Benutzer dorthin weiter. Wenn der Benutzer bereits autorisiert ist, wird die Sitzung abgeholt und er fliegt sofort vom Autorisierungsserver zurück und gelangt dorthin, wo er wollte. Wenn es nicht autorisiert ist, löst der Autorisierungsserver dieses Problem so gut wie möglich, indem er in der Regel eine Anmeldung mit einem Kennwort anfordert. Wenn die Lösung erfolgreich ist, sendet er den Benutzer zurück.
Darüber hinaus ist SAML im Moment sozusagen die Lösung veraltet. Und Kerberos ist im Allgemeinen eine völlig separate geschlossene Microsoft-Magie, die weit über den Rahmen des HTTP-Protokolls hinausgeht. Nun, wir werden uns darauf konzentrieren. Und dann kommen wir zum nächsten Problem.
Es gibt bereits ein verständliches Arbeitsszenario: Senden Sie den Benutzer in einer unverständlichen Situation an den Autorisierungsserver, lassen Sie ihn entscheiden, was mit ihm geschehen soll, und geben Sie eine fertige Antwort zurück. Aber wie genau teilt der Autorisierungsserver diesem anderen Server mit, dass der Benutzer autorisiert ist? Hier kehren wir noch einmal zu den Ideen des ersten Absatzes zurück, nämlich zum Sitzungsschlüssel. Kehren wir zu den Grundlagen zurück: Das Vorhandensein eines Sitzungsschlüssels ist ein Zeichen der Autorisierung, der Sitzungsschlüssel selbst öffnet die Tür zu Benutzerinformationen und, Sie werden es nicht glauben, zu Sitzungsinformationen. Der Autorisierungsserver autorisiert den Sitzungsschlüssel und gibt ihn an einen anderen Server weiter.
Jetzt wird es jedoch nicht mehr als Sitzungsschlüssel, sondern als Token bezeichnet .
Genauer gesagt (gemäß dem OAuth 2.0- Protokoll, auf das OpenID Connect geschrieben ist) sind dies zwei Token gleichzeitig - Access Token , um es mit allen Anforderungen zu verknüpfen, wenn Großväter Sitzungsschlüssel abgeschnitten haben, und Refresh Token , um Access Token zu aktualisieren, wenn es ausgeht.
Um die Zwischensumme zusammenzufassen. Anstatt den Benutzer nach einem Benutzernamen und einem Kennwort zu fragen, sendet der Server diese an einen anderen Server, einen separaten Autorisierungsserver. Er erledigt die ganze Arbeit und gibt dann die ersten Token. Genau in diesem Szenario sind Anwendungen autorisiert, mobil und manchmal auf dem Desktop. Sie leiten nur nicht weiter, senden einfach den JSON-Autorisierungsserver mit einem Benutzernamen und einem Kennwort und er sendet ihnen als Antwort Token.
Mobile und Desktop-Anwendungen können dies tun. Aus irgendeinem Grund gelten sie als sicherer als das Web, aber das Web hat ein komplizierteres Leben.
6.
Einerseits ist es nicht komplizierter, andererseits einfacher. Sie können eine Weiterleitung vornehmen und müssen sich nicht mit dem Rendern eines Login-Passwort-Formulars beschäftigen. Andererseits möchte ich wirklich, wirklich keine Token im Klartext durch den Browser ziehen. Dies ist fast so ekelhaft wie das unverschlüsselte Kennwort bei der Standardzugriffsauthentifizierung . Aber niemand will diesen alten schrecklichen Fehler wiederholen.
Es gab keine Lösung für das Problem, so dass es sehr elegant ist, aber funktioniert. Zunächst läuft alles wie gewohnt, wechselt zur Autorisierung, Autorisierung selbst. Wenn es dann Zeit ist, mit Token zurückzukehren, erfolgt die umgekehrte Umleitung. Anstelle von Token wird jedoch ein einmaliger Code an die Absenderadresse angehängt. Der einmalige Code wurde gerade nur für diesen bestimmten Moment vom Autorisierungsserver generiert. Er hat eine sehr kurze Lebenszeit. Nachdem ein anderer Server kaum einen einmaligen Code erhalten hat, sollte er die Röcke hochklappen, die Augen ausbeulen und erneut zum Autorisierungsserver eilen, um die gewünschten Token aus dem einmaligen Code zu erhalten.
Auf dem Autorisierungsserver gibt es eine spezielle Ressource für eine Reise mit einem Code für Token. Es akzeptiert laut Spezifikation nicht GET, sondern POST. Das deutet irgendwie darauf hin, dass diese Anfrage nicht vom Browser, sondern von Server zu Server gestellt werden sollte.
Aus dem gleichen Grund sind POST-Anforderungen auf jedem CORS-Autorisierungsserver mit Selbstachtung verboten.
7.
Erinnern Sie sich übrigens noch an Authentifizierung und Autorisierung? Authentifizierung ist, wenn jemand einfach per Login und Passwort eingeben darf oder nicht. Und die Autorisierung ist, wenn sie bereits gestartet sind, beginnen sie zu verstehen, wer genau sie gestartet haben.
Erinnerst du dich an OAuth 2.0 ? Ich habe es oben einige Male erwähnt, als eine Art Grundlage für OpenID Connect.
Erinnerst du dich an OpenID Connect ? Dieser Artikel ist nur er dumm.
OAuth 2.0 ist also Authentifizierung. Bei der gesamten zuvor beschriebenen, etwas verwirrenden Prozedur mit drei Teilnehmern, einem Passwort, einem Code und einem Token geht es um die Authentifizierung, nur darum, jemanden irgendwo laufen zu lassen. OAuth 2.0-Protokoll.
OpenID Connect ist eine Autorisierung. Das heißt, er fügt OAuth jene Teile hinzu, in denen sich herausstellt, wen sie loslassen.
Zu diesem Zweck wird der Liste der Token eine weitere hinzugefügt, die als ID-Token bezeichnet wird . Diejenigen, die dem Link folgen, sind wahrscheinlich überrascht, nichts über eine Token-ID darauf zu sehen. Lassen Sie sich nicht überraschen, ID Token ist das JWT, das als base64-codierte verschachtelte Puppe in demselben JSON wie Access Token und Refresh Token zurückgegeben wird. In jedem Fall ist alles, was Sie über den Benutzer wissen wollten, in ihm.
Außerdem gibt es auf dem Autorisierungsserver eine spezielle Ressource namens userinfo, in der Sie mit Access Token klopfen und als Antwort denselben JSON erhalten können wie in Token ID. Aber warum wird es benötigt, wenn die Token-ID bereits vorhanden ist? Frage an die Autoren der Spezifikation.
OpenID Connect enthält auch eine Beschreibung der verschiedenen Felder mit Benutzerinformationen. Wie kann ich diese Informationen direkt während der Autorisierung oder jederzeit danach erhalten? Und eine Beschreibung, wie und wann der Benutzer Ihnen erlaubt, diese Informationen zu verwenden.
Oder nicht zulassen. Kurz gesagt, OpenID Connect 1.0 wurde entwickelt.
8.
Ein kleines Lametta im Protokoll. Ich hoffe, dass Sie im Moment müde genug sind, den Artikel zu lesen, um diesem Artikel nicht viel Aufmerksamkeit zu schenken, indem Sie ihn einfach durch die Augen laufen lassen. Hier werde ich die Parameter erwähnen, die in der Spezifikation enthalten sind und eine gewisse semantische Last tragen, aber sie stehen nicht in direktem Zusammenhang mit der Umsetzung der Idee selbst. Grundsätzlich erhöhen sie die Sicherheit, oder Sie können bei Bedarf einfach einige Informationen von einem der Teilnehmer des Prozesses auf einen anderen übertragen.
Kunden-ID und Kundengeheimnis . Der Client in der Sprache des OpenID Connect-Protokolls ist überhaupt kein Browser, sondern der ganz andere Server, der den Benutzer autorisieren muss. Angenommen, Sie haben eine Website und möchten dieser über Facebook eine modische Autorisierung hinzufügen. Und durch Googol. Und nicht so modisch über Twitter. Die Implementierung des Protokolls im Code reicht nicht aus. Sie müssen sich auch auf Facebook, Google und Twitter registrieren, jedoch nicht als Benutzer, sondern als Kunde, der als Server seine Berechtigung verwenden kann. Bei der Registrierung erhalten Sie eine Kunden-ID und ein Kundengeheimnis vom bedingten Facebook. Wenn Sie unter anderem um Autorisierung bitten, senden Sie eine Client-ID. Und wenn Sie einen einmaligen Code für ein Token verwenden, werden Sie von Client Secret ebenfalls benötigt.
URI umleiten . Hier ist alles einfach. Wenn Sie einen Benutzer zur Anmeldung an ein bedingtes Facebook senden, müssen Sie Facebook mitteilen, wo er nach der Autorisierung Codes und Token an ihn zurücksenden soll. Natürlich geben Sie ihm immer noch Ihre Kunden-ID. Mit einem separaten Umleitungs-URI können Sie jedoch nach der Autorisierung verschiedene Benutzer auf verschiedene Seiten umleiten, z. B. Administratoren im Admin-Bereich und normale Benutzer auf ihre persönlichen Seiten. Praktisch. Darüber hinaus ist die zulässige Liste möglicher Umleitungs-URIs, die in den Client-Einstellungen auf der bedingten Facebook-Seite angegeben sind, eine zusätzliche Sicherheit.
Geltungsbereich . Dies ist eine Liste dessen, was der Server vom Autorisierungsserver über den Benutzer wissen möchte. Die Werte in der Liste sind durch Leerzeichen getrennt. Openid sollte unter ihnen obligatorisch sein, und dann lesen Sie die Spezifikation.
Staat . Erinnern Sie sich an den einmaligen Code, mit dem Token ausgegeben werden, wie ein Ticket in einer elektronischen Warteschlange? Status ist also Code. Wenn der Autorisierungsserver einen Code an einen anderen Server ausgibt, damit er ihn bald zurückgibt, gibt dieser Status diesem Server einen anderen Autorisierungsserver, der ihn bei der Umleitung zurückgibt. Er wird, wie ich es verstehe, benötigt, wenn es einem anderen Server bereits gelungen ist, eine eigene Sitzung zu erstellen, damit sie bei all diesen Weiterleitungen nicht verloren geht.
Es gibt andere Parameter, wie die Art der Autorisierungsanforderung und die Token-Lebensdauer, aber um zu verstehen, warum Sie sie nicht benötigen.
Abschließend. Ich hoffe wirklich, dass Ihnen das nicht zu nachdenkliche und gezielte Lesen des obigen Textes irgendwo geholfen hat, die Ideen zu verstehen, die einigen modernen Zugriffskontrollprotokollen zugrunde liegen. Beginnen Sie jedoch mit der Implementierung oder konfigurieren Sie eines davon, öffnen Sie die Spezifikationen, finden Sie ein gutes Tutorial und folgen Sie jedem Wort und jedem Buchstaben sorgfältig. Und lassen Sie das Verständnis von Ideen die Intuition in Ihnen wecken. Und Intuition, lassen Sie sich jedes Mal von der Krone beißen, wenn Sie einen Parameter übersehen, der auf den ersten Blick nicht so wichtig ist, oder eine Einstellung, und lassen Sie dies ein Loch für verschwitzte, verspielte kleine Hände.
Denken Sie daran, dass dies alles die gleiche Sicherheit ist und dass die Regeln, egal wie dumm und bedeutungslos sie auch erscheinen mögen, in Blut geschrieben sind. Nun, vielleicht nicht mit Blut, es ist schließlich keine Sicherheitsmaßnahme in der Gießerei, aber Geld und Ansehen sind sicher, und Geld und Ansehen sind auch nicht die Dinge, die man so leicht herumwerfen sollte.
Vielen Dank an JM für die Tatsache, dass der Text, den Sie gelesen haben, viel besser war als der, den ich geschrieben habe.
Viel Glück und vergessen Sie nicht, Ihre Zertifikate rechtzeitig zu erneuern.