Auth-Aufgabe
Das Problem der Autorisierung in Dutzenden von Diensten trat vor einigen Jahren auf - zu Beginn der „ Ära des Sägens des Monolithen “. Dieses Problem wurde mit einem neuen Dienst namens Auth gelöst. Er half bei der Implementierung einer nahtlosen Authentifizierung für verschiedene Dienste und der Migration von Benutzerdaten in separate Datenbanken.
Der Auth-Dienst hat drei Hauptaufgaben:
- Single Point of Authentication (SSO) für alle Systemdienste . Dienste speichern keine Anmeldeinformationen, vertrauen dies jedoch einem dedizierten Dienst an.
- Sicherer und detaillierter Zugriff auf Ressourcen . Sicher, da Passwörter an einem Ort gespeichert und so sicher wie möglich sind. Granular, da Dienstbesitzer den Zugriff auf Ressourcen basierend auf den vom Authentifizierungsdienst stammenden Daten nach Belieben konfigurieren können.
- . , , .
Die erste Version von Auth ist Teil des Monolithen. Es verwendet ein eigenes Protokoll für die Kommunikation mit Diensten. Ein solches "Schema" war zu diesem Zeitpunkt notwendig, aber nach mehreren Jahren Arbeit traten Probleme auf.
Auth ist Teil des Monolithen . Folglich ist der Service an den Release-Zyklus gebunden, was eine unabhängige Entwicklung und Bereitstellung unmöglich macht. Außerdem müssten Sie den gesamten Monolithen bereitstellen, wenn Sie Auth bereitstellen möchten, z. B. beim Skalieren eines Dienstes.
Dodo IS hängt von Auth ab . In der alten Implementierung rufen externe Dienste bei jeder Benutzeraktion Auth auf, um Daten darüber zu überprüfen. Diese enge Bindung kann dazu führen, dass der gesamte Dodo IS nicht mehr funktioniert, wenn Auth aus irgendeinem Grund hängen bleibt.
Auth hängt von Redis ab... Darüber hinaus ist es stark genug - eine Fehlfunktion von Redis wird zum Sturz von Auth führen. Wir verwenden Azure Redis, für das der angegebene SLA 99,9% beträgt. Dies bedeutet, dass der Dienst bis zu 44 Minuten pro Monat nicht verfügbar sein kann. Eine solche Ausfallzeit ist nicht zulässig.
Die aktuelle Implementierung von Auth verwendet ein eigenes Authentifizierungsprotokoll, ohne sich auf Standards zu verlassen . In den meisten unserer Dienste verwenden wir C # (wenn es sich um ein Backend handelt) und wir haben keine Probleme mit der Pflege der Bibliothek für unser Protokoll. Wenn jedoch plötzlich Dienste in Python, Go oder Rust angezeigt werden, nimmt die Entwicklung und Unterstützung von Bibliotheken für diese Sprachen zusätzliche Zeit in Anspruch und bringt zusätzliche Komplexität mit sich.
Current Auth verwendet ein rollenbasiertes Zugriffssteuerungsschema, das auf Rollen basiert... Normalerweise erhält eine Rolle vollen Zugriff auf einen bestimmten Dienst, anstatt an eine bestimmte Funktionalität gebunden zu sein. In Pizzerien gibt es beispielsweise stellvertretende Manager, die bestimmte Projekte leiten können: Zeitpläne erstellen oder Rohstoffe berücksichtigen. Wir haben jedoch keine Rechte an bestimmten Komponenten des Systems. Sie müssen vollen Zugriff auf den Service gewähren, damit Mitarbeiter auf die Zeitplanung oder Einstellungen einer beliebigen Buchhaltungskomponente zugreifen können.
Probleme veranlassten uns, eine neue Version von Auth zu entwerfen und zu schreiben. Zu Beginn des Projekts haben wir drei Wochen lang nur die Autorisierungs- und Authentifizierungsstandards OAuth 2.0 und OpenID Connect 1.0 untersucht.
Hinweis... Übertrieben ist der Artikel eine Nacherzählung des RFC, der mehrmals neu gelesen werden musste, um zu verstehen, was um ihn herum geschah. Hier habe ich versucht, mich von dieser Komplexität zu lösen und alles so einfach, strukturiert, präzise und ohne Beschreibung komplexer Dinge zu erzählen, zum Beispiel, welche Zeichen die Serviceantwort enthalten kann. Im Gegensatz zu RFC können Sie nach einmaligem Lesen alles herausfinden. Ich hoffe, dass der Artikel nützlich ist und Zeit spart, wenn Sie eine Lösung für die Implementierung eines Authentifizierungsdienstes auswählen, oder dass jemand über seine Notwendigkeit nachdenkt.
Was ist OAuth2.0?
Wir haben uns entschlossen, mit der Entwicklung der neuen Auth zu beginnen, indem wir die verfügbaren Protokolle und Technologien untersucht haben. Der am häufigsten verwendete Autorisierungsstandard ist das OAuth2.0-Autorisierungsframework.
Der Standard wurde 2012 verabschiedet und über 8 Jahre wurde das Protokoll geändert und ergänzt. Es gibt so viele RFCs, dass die Autoren des ursprünglichen Protokolls beschlossen haben, OAuth 2.1 zu schreiben, das alle aktuellen Änderungen an OAuth 2.0 in einem Dokument zusammenfasst. Während er sich im Entwurfsstadium befindet .
Die aktuelle Version von OAuth ist in RFC 6749 beschrieben . Wir werden es analysieren.
OAuth 2.0 ist ein Autorisierungsframework.
Es wird beschrieben, wie die Kommunikation zwischen Diensten implementiert werden sollte, um eine sichere Autorisierung zu gewährleisten. Viele der Nuancen werden ausreichend detailliert beschrieben, beispielsweise der Fluss der Interaktion zwischen Knoten, einige sind jedoch einer bestimmten Implementierung überlassen.
Eigenschaften:
- Trennen der Entität des Benutzers und der Anwendung, die den Zugriff anfordert . Dank dieser Trennung können wir Anwendungsrechte getrennt von Benutzerrechten verwalten.
- Anstelle des üblichen Logins und Passworts, die bestimmte Rechte und eine bestimmte Lebensdauer haben, erhalten wir Zugriff auf Ressourcen mithilfe zufällig generierter Zeichenfolgen - Token .
- Sie können Rechte so genau wie möglich ausstellen , basierend auf Ihren eigenen Wünschen und nicht auf einem festgelegten Satz von Rechten.
Schauen wir uns die Funktionen genauer an.
Rollen
OAuth 2.0 definiert vier Rollen:
- Der Ressourceneigentümer ist eine Entität, die über Zugriffsrechte auf eine geschützte Ressource verfügt. Eine Entität kann ein Endbenutzer oder eine Art System sein. Eine geschützte Ressource ist ein HTTP-Endpunkt, der alles sein kann: API-Endpunkt, Datei auf CDN, Webdienst.
- Ressourcenserver - Ein Server, der eine geschützte Ressource speichert, auf die der Ressourcenbesitzer Zugriff hat.
- Client . Dies ist eine Anwendung, die im Namen des Ressourcenbesitzers und mit seiner Erlaubnis - mit Genehmigung - den Zugriff auf eine geschützte Ressource anfordert.
- Autorisierungsserver - Ein Server, der einem Client ein Token ausgibt, um nach erfolgreicher Autorisierung des Ressourcenbesitzers auf eine geschützte Ressource zuzugreifen.
Jeder Teilnehmer an der Interaktion kann mehrere Rollen kombinieren. Beispielsweise kann ein Client gleichzeitig Ressourcenbesitzer sein und Zugriff auf seine eigenen Ressourcen anfordern. Betrachten wir das Interaktionsschema weiter.
Wichtig: Der Kunde muss im Voraus beim Dienst registriert sein. Wie kann man es machen?
Kundenregistrierung
Sie wählen die Methode der Client-Registrierung, z. B. die manuelle oder Service-Erkennung, abhängig von der
Umleitungs-URI - Die Adresse, an die der Ressourcenbesitzer nach erfolgreicher Autorisierung gesendet wird. Zusätzlich zur Autorisierung wird die Adresse verwendet, um zu bestätigen, dass der Dienst, der die Autorisierung beantragt hat, derjenige ist, für den er sich ausgibt.
Client-Typ - Der Client-Typ , der bestimmt, wie Sie mit ihm interagieren. Der Clienttyp wird durch seine Fähigkeit bestimmt, seine Anmeldeinformationen für die Autorisierung sicher zu speichern - ein Token. Daher gibt es nur zwei Arten von Clients:
- Confidential — , . , web-, backend.
- Public — . , , .
Das Token in OAuth 2.0 ist eine Zeichenfolge, die für den Client nicht transparent ist. Normalerweise sieht die Zeichenfolge so aus, als wäre sie zufällig generiert worden - ihr Format spielt für den Client keine Rolle. Ein Token ist ein Schlüssel, um auf etwas zuzugreifen, beispielsweise auf eine geschützte Ressource (Zugriffstoken) oder auf ein neues Token (Aktualisierungstoken).
Jeder Token hat seine eigene Lebensdauer . Aber das Aktualisierungstoken sollte mehr haben, weil Es wird verwendet, um ein Zugriffstoken zu erhalten. Wenn die Lebensdauer eines Zugriffstokens beispielsweise etwa eine Stunde beträgt, kann das Aktualisierungstoken eine ganze Woche lang verwendet werden.
Das Aktualisierungstoken ist optional und nur für vertrauliche Clients verfügbar... Bei Verwendung des optionalen Tokens ist in einigen Implementierungen die Lebensdauer des Zugriffstokens sehr lang, und das Aktualisierungstoken wird überhaupt nicht verwendet, um sich nicht um die Aktualisierung zu kümmern. Das ist aber nicht sicher. Wenn das Zugriffstoken kompromittiert wurde, kann es zurückgesetzt werden und der Dienst erhält mithilfe des Aktualisierungstokens ein neues Zugriffstoken. Wenn kein Aktualisierungstoken vorhanden ist, müssen Sie den Autorisierungsprozess erneut durchführen.
Einem Zugriffstoken werden bestimmte Zugriffsrechte zugewiesen, die dem Client während der Autorisierung erteilt werden. Schauen wir uns an, wie Berechtigungen in OAuth 2.0 aussehen.
Zugangsrechte
Zugriffsrechte werden dem Client als Gültigkeitsbereich erteilt. Scope ist ein Parameter, der aus durch Leerzeichen getrennten Zeichenfolgen besteht - scope-token.
Jedes der Scope-Token repräsentiert bestimmte Rechte, die dem Kunden gewährt wurden. Ein Scope-Token
doc_read kann beispielsweise Lesezugriff auf ein Dokument auf einem Ressourcenserver und employee Zugriff auf Anwendungsfunktionen nur für Mitarbeiter des Unternehmens bereitstellen. Der endgültige Geltungsbereich könnte folgendermaßen aussehen : email doc_read employee.
In OAuth 2.0 erstellen wir Scope-Token selbst und passen sie an unsere Bedürfnisse an. Scope-Token-Namen sind nur durch Fantasy und zwei ASCII-Zeichen begrenzt -
"und \.
In der Phase der Clientregistrierung erhält der Client in den Einstellungen des Autorisierungsdienstes standardmäßig einen Standardbereich. Der Client kann jedoch vom Autorisierungsserver einen anderen als den Standardbereich anfordern. Abhängig von den Richtlinien auf dem Autorisierungsserver und der Auswahl des Ressourcenbesitzers kann der resultierende Bereich sehr unterschiedlich aussehen. In Zukunft kann der Ressourcenbesitzer nach der Autorisierung des Clients einige der Rechte entfernen, ohne den Dienst erneut zu autorisieren. Um jedoch zusätzliche Berechtigungen zu erteilen, ist eine erneute Autorisierung des Clients erforderlich.
Abstract OAuth 2.0. Flow mit Access Token
Wir haben uns Rollen angesehen, die Arten von Token und den Umfang. Schauen wir uns den Ablauf der Bereitstellung des Zugriffs auf den Dienst an.
Unten finden Sie ein abstraktes Diagramm (oder einen Ablauf) der Interaktion zwischen den Teilnehmern. Alle Schritte in diesem Diagramm werden ausschließlich von oben nach unten ausgeführt. Lassen Sie uns genauer analysieren.
- Der Client sendet eine Anforderung zum Zugriff auf den erforderlichen Ressourcenbesitzer.
- Der Ressourcenbesitzer gibt dem Client eine Autorisierungsgewährung zurück, die die Identität des Ressourcenbesitzers und seine Rechte an der Ressource bestätigt, auf die der Client Zugriff anfordert. Je nach Ablauf kann dies ein Token oder Anmeldeinformationen sein.
- Der Client sendet die im vorherigen Schritt erhaltene Autorisierungsgewährung an den Autorisierungsserver und erwartet von diesem ein Zugriffstoken, um auf die geschützte Ressource zuzugreifen.
- Der Autorisierungsserver stellt sicher, dass die Autorisierungsgewährung gültig ist, und sendet dann das Zugriffstoken zurück an den Client.
- Nach Erhalt des Zugriffstokens fordert der Client die geschützte Ressource vom Ressourcenserver an.
- Der Ressourcenserver stellt sicher, dass das Zugriffstoken korrekt ist, und bietet dann Zugriff auf die geschützte Ressource.
Der Client erhält die Genehmigung vom Ressourcenbesitzer, auf deren Grundlage ihm Zugriff auf die Ressource gewährt wird. Es ist einfach. Wird es so einfach sein, wenn wir diesem Schema ein Aktualisierungstoken hinzufügen?
Abstract OAuth 2.0. Flow mit Refresh-Token
Der erste und der zweite Schritt sind in diesem Diagramm weggelassen - sie unterscheiden sich nicht vom obigen abstrakten Flussdiagramm.
Schema im Detail:
- Der Client erhält eine Autorisierungsgewährung für den Autorisierungsserver und fordert ihn auf, ihm ein Zugriffstoken und ein Aktualisierungstoken bereitzustellen.
- Authorization server , authorization grant access token refresh token.
- Client access token , — invalid token error.
- , authorization server refresh token access token .
- access token, refresh token, refresh token.
grant?
Grant sind Daten, die die erfolgreiche Autorisierung des Clients durch den Eigentümer der Ressource darstellen, die vom Client verwendet wird, um ein Zugriffstoken zu erhalten.
Wenn wir uns beispielsweise irgendwo bei Google authentifizieren, wird eine Benachrichtigung vor unseren Augen angezeigt. Es heißt, dass dieser und jener Dienst auf Daten über Sie oder Ihre Ressourcen zugreifen möchte (das angeforderte Scope-Token wird angezeigt). Diese Benachrichtigung wird als "Zustimmungsbildschirm" bezeichnet.
In dem Moment, in dem wir auf "OK" klicken, wird derselbe Zuschuss in die Datenbank aufgenommen: Es werden Daten aufgezeichnet, die der eine oder andere Benutzer diesem und jenem Zugriff auf diesen und jenen Dienst gewährt hat. Der Client erhält eine Art erfolgreiche Authentifizierungskennung, z. B. eine Zeichenfolge, die den Daten in der Datenbank zugeordnet ist.
Es gibt 4 + 1 Möglichkeiten, einen Zuschuss zu erhalten - Zuschusstyp:
- Authorization code — confedencial — web-.
- Client credentials — confedential , , .
- Implicit — public-, redirection URI (, ), authorization code grant PKCE (Proof Key for Code Exchange — , , token , . — RFC 7636).
- Anmeldeinformationen für das Kennwort des Ressourcenbesitzers . In OAuth 2.0 Security RFC 6819 wird dieser Grant-Typ als unzuverlässig angesehen. Wenn es früher nur für die Migration von Diensten zu OAuth 2.0 verwendet werden durfte, darf es derzeit überhaupt nicht verwendet werden.
- Geräteberechtigung (hinzugefügt in RFC 8628) - wird verwendet, um Geräte zu autorisieren, die möglicherweise keinen Webbrowser haben, aber über das Internet arbeiten können. Dies sind beispielsweise Konsolenanwendungen, Smart Devices oder Smart TVs.
Nur Autorisierungscode (mit PKCE), Client-Anmeldeinformationen und Geräteautorisierungsgewährung können als relevant angesehen werden , aber wir werden alles berücksichtigen. Wir werden die Gewährung in Betracht ziehen, um die Komplexität des Verständnisses zu erhöhen.
Client credentials grant flow
Es hat den einfachsten Ablauf und erinnert an die regelmäßige Autorisierung eines Dienstes. Die Ausführung erfolgt anhand der Anmeldeinformationen des Clients, bei denen es sich um die Client-ID und das Client-Geheimnis handelt - ein Analogon zu Anmeldung und Kennwort für den Benutzer. Da für die Authentifizierung ein Clientgeheimnis erforderlich ist, das ordnungsgemäß gespeichert werden muss, kann dieser Ablauf nur von vertraulichen Clients verwendet werden.
Das Schema ist einfach: Der Client wird auf dem Autorisierungsserver durch Übergabe der Client-ID und des Client-Geheimnisses authentifiziert. Als Antwort erhält es ein Zugriffstoken, mit dem es bereits auf den erforderlichen Dienst zugreifen kann.
Dieser Ablauf ist erforderlich, wenn der Client versucht, auf seine eigenen Ressourcen oder Ressourcen zuzugreifen, die zuvor mit dem Autorisierungsserver vereinbart wurden. Beispielsweise muss Dienst A von Zeit zu Zeit zu Dienst B gehen und dort Daten über die Anzahl der Pizzerien im Netzwerk aktualisieren.
Die Anmeldeinformationen für das Kennwort des Ressourcenbesitzers fließen
Gemäß den aktuellen Sicherheitsempfehlungen, die in diesem RFC beschrieben sind , wird empfohlen, diesen Datenfluss aufgrund offensichtlicher Sicherheitsbedenken überhaupt nicht zu verwenden.
In der Abbildung dieses Ablaufs gibt es zwei Clients, und theoretisch sollte es einen Client und einen Autorisierungsserver geben.
Der Ressourcenbesitzer überträgt seinen Benutzernamen und sein Kennwort beispielsweise über Formulare auf dem Client an den Client. Der Client verwendet es wiederum, um ein Zugriffstoken (und optional ein Aktualisierungstoken) zu erhalten.
Hier gibt es ein Problem. Der Ressourcenbesitzer nimmt einfach seinen Benutzernamen und sein Passwort in klarer Form und gibt sie an den Client weiter, was nicht sicher ist. Es wurde ursprünglich nur für Kunden erstellt, denen Sie vertrauen oder die Teil des Betriebssystems sind. Später war es nur für die Migration von der Anmelde- und Kennwortauthentifizierung zu OAuth 2.0 zulässig. Aktuelle Sicherheitsrichtlinien verbieten die Verwendung.
Zugangscode
Der derzeit häufigste Fluss. Meistens für vertrauliche Kunden verwendet, aber mit der Einführung einer zusätzlichen Validierung mit PKCE kann es auch für öffentliche Kunden verwendet werden.
In diesem Ablauf erfolgt die Interaktion zwischen dem Client und dem Ressourcenbesitzer über den Benutzeragenten (Browser). Der Benutzeragent hat eine Anforderung: Er muss mit HTTP-Weiterleitungen arbeiten können. Ohne dies kann der Ressourcenbesitzer nicht zum Autorisierungsserver gelangen und mit Grant zurückkehren.
Dieser Ablauf ist komplizierter als die vorherigen, daher werden wir ihn Schritt für Schritt analysieren. Stellen wir uns zunächst vor, wir sind Ressourcenbesitzer und haben die Seite eines Online-Lerndienstes aufgerufen, der die Lernergebnisse in unserer Cloud speichern möchte. Er muss Zugriff auf unsere Ressource erhalten, beispielsweise auf ein bestimmtes Verzeichnis in der Cloud. Wir klicken auf "Login" und die Reise durch den Autorisierungscode Grant Flow beginnt:
- Im ersten Schritt leitet der Client den Ressourcenbesitzer mithilfe des Benutzeragenten zur Authentifizierungsseite des Autorisierungsservers weiter. In der URI werden die Client-ID und die Umleitungs-URI angegeben. Der Umleitungs-URI wird verwendet, um zu verstehen, wo der Ressourcenbesitzer nach erfolgreicher Autorisierung zurückgegeben werden soll (der Ressourcenbesitzer erteilt dem vom Client angeforderten Bereich die Berechtigung).
- user-agent, resource owner .
- Resource owner , consent screen .
- Resource owner user-agent URI, redirection URI. query- authorization code — , , resource owner .
- authorization code , access token ( refresh token, ).
- authorization code, , access token ( refresh token). .
Wenn wir uns anstelle des Ressourcenbesitzers vorstellen, sehen wir nur eine Umleitung zum Autorisierungsserver, authentifizieren uns, bestätigen den Zugriff auf den Einwilligungsbildschirm und senden uns an einen bereits laufenden Dienst. Zum Beispiel gehen wir dies viele Male durch, wenn wir mit einem Google-, Facebook- oder Apple-Konto zum Dienst gehen.
Der nächste Fluss baut darauf auf.
Implizite Gewährung
Dies ist eine Optimierung des Berechtigungscode-Erteilungsflusses für öffentliche Clients, die mit Umleitungs-URIs arbeiten können. Zum Beispiel für JavaScript-Browseranwendungen oder mobile Anwendungen. Die Anforderung an den Benutzeragenten, über den der Client und der Ressourcenbesitzer interagieren, bleibt bestehen: Er muss in der Lage sein, mit HTTP-Weiterleitungen zu arbeiten.
Es gibt einen Hauptunterschied zwischen Autorisierungscode und implizit: Anstatt Autorisierungscode und Zugriffstoken darauf zu erhalten, erhalten wir sofort Zugriffstoken nach erfolgreicher Autorisierung des Ressourcenbesitzers. Außerdem wird das Client-Geheimnis hier aus Sicherheitsgründen nicht verwendet - die Anwendung kann zerlegt und abgerufen werden. Die Authentizität wird nur durch den Umleitungs-URI überprüft.
Viele Schritte aus diesem Diagramm ähneln den Schritten aus dem Autorisierungscode, aber ich schlage vor, sie auch im Detail zu analysieren. Stellen wir uns vor, eine Browseranwendung möchte ihre Einstellungen in unserem Git-Repository speichern. Wir klicken auf "Anmelden bei GitHub" und in diesem Stadium beginnt der implizite Ablauf:
- Der Client verwendet den Benutzeragenten und eine HTTP-Umleitung, um den Ressourcenbesitzer zum Autorisierungsserver umzuleiten. In den Anforderungsparametern werden die Client-ID- und Umleitungs-URIs übergeben, die zur Authentifizierung des Clients erforderlich sind, und anschließend der Ressourcenbesitzer zurückgegeben.
- Der Ressourcenbesitzer wird authentifiziert, indem er über den Benutzeragenten mit dem Autorisierungsserver kommuniziert. Gleichzeitig wird die Erteilung eines Zuschusses an den Kunden bestätigt, mit dessen Kunden-ID er gekommen ist.
- grant ( «allow» consent screen), user-agent resource owner redirection URI. , URI fragment access token (URI fragment — , URI ‘#’).
- user-agent. User-agent redirection URI web-, access token . , , , CDN.
- Web- web- ( ), redirection URI, , .
- User-agent , , web-hosted client resource, access token.
- Der resultierende Benutzer-Agent für Zugriffstoken wird einfach an den Client übertragen.
Dies ist ein komplexer Ablauf. In realen Szenarien hat es wenig Verwendung. Aber es kann immer noch in Legacy-Projekten gefunden werden.
Geräteberechtigung (RFC 8628)
Von 2012 bis 2019 sind viele intelligente Geräte aufgetreten, deren Anmeldung unpraktisch ist. Beispielsweise ist es unpraktisch, bei jedem Öffnen einer Ressource einen komplexen Benutzernamen und ein Kennwort auf dem Fernsehgerät einzugeben. Dies ist auf einigen Geräten, z. B. Server-Betriebssystemen ohne grafische Oberfläche, nicht möglich. Im August 2019 erschien dieser Fluss nur für solche Szenarien.
Es gibt mindestens 3 Anforderungen für Geräte, um mit dem Device Authoraztion Grant Flow arbeiten zu können:
- Das Gerät muss in der Lage sein, ausgehende HTTPS-Anforderungen zu stellen.
- Das Gerät muss in der Lage sein, dem Benutzer den URI und die ID anzuzeigen.
- Jedes autorisierte Gerät gehört dem Ressourcenbesitzer, der für eine erfolgreiche Autorisierung über ein anderes Gerät mit einem Browser verfügen muss, um zum angegebenen URI zu gelangen und den angegebenen Code einzugeben.
Vielleicht scheint das Schema aufgrund der Fülle an Pfeilen kompliziert zu sein. Lassen Sie es uns Schritt für Schritt analysieren, während wir komplexe Abläufe davor analysierten.
Angenommen, wir versuchen, uns über den Fernseher bei einem Webdienst anzumelden. Wir sehen die Schaltfläche "Als Gerät anmelden" und klicken auf. In diesem Moment beginnt unser Gerätefluss:
- Das Fernsehgerät sendet eine Anfrage an den Autorisierungsserver und gibt ihm seine Client-ID.
- Der Autorisierungsserver überprüft, ob ein solcher Client registriert ist und über den entsprechenden Grant-Typ verfügt.
- , Authorization server device code, user code verification URI. Device code — , .
- user code verification URI — resource owner. Redirection URI , QR- — .
- , user code verification URI, .
- resource owner. verification URI, user code, , scope . resource owner .
- Während dieser ganzen Zeit befragte das Gerät (Punkt 3) den Autorisierungsserver nach seinem Erfolg. Das Gerät geht erneut mit seinem Gerätecode und seiner Client-ID zum Autorisierungsserver, in der Hoffnung, dass die Autorisierung dieses Mal abgelaufen ist.
- Dieses Mal, wenn der Ressourcenbesitzer die Übertragung der erforderlichen Rechte an das Gerät bestätigt hat, gibt der Autorisierungsserver als Antwort auf die Anforderung ein Zugriffstoken zurück (sofern dies durch die Servereinstellungen und das Aktualisierungstoken bereitgestellt wird). Mit Hilfe des Tokens kann das Gerät bereits weiter mit der Ressource arbeiten.
Trotz der offensichtlichen Komplexität mit Pfeilen ist dieser Ablauf auch recht einfach. Wenn Sie mit Geräten interagieren müssen (und wir haben viele davon: Tracker, Registrierkasse, Schaufenster und andere Geräte), sollten Sie diesen Ablauf verwenden.
Anstelle von Ausgabe
In diesem Artikel habe ich viele Details weggelassen, um auf einfachste und zugänglichste Weise über die wichtigsten Dinge zu sprechen. Zum Beispiel die Arten von Anforderungen, wie und in welcher Form Parameter übergeben werden sollen, welche Zeichen als Werte dafür zulässig sind.
Wenn Sie näher auf das Thema eingehen möchten, empfehle ich RFC 6749 (für OAuth 2.0) und RFC 8628 (für Device Flow). Sie können die OAuth-Ressource auch auf aktuelle RFCs überprüfen .
Wenn der Artikel nützlich war und Sie weitere Details wünschen, schreiben Sie in die Kommentare und in den nächsten Artikeln werde ich über PKCE, das OpenID Connect 1.0-Authentifizierungsprotokoll, unsere Implementierung des Authentifizierungsservers und vieles mehr sprechen.
Nützliche Links: