it-swarm.com.de

Warum verfügt OAuth v2 sowohl über Zugriffstoken als auch über Aktualisierungstoken?

Abschnitt 4.2 des Protokollentwurfs OAuth 2.0 gibt an, dass ein Autorisierungsserver sowohl einen access_token (der zur Authentifizierung bei einer Ressource verwendet wird) als auch einen refresh_token zurückgeben kann wird nur verwendet, um einen neuen access_token zu erstellen:

https://tools.ietf.org/html/rfc6749#section-4.2

Warum beides? Warum nicht einfach den access_token so lange wie den refresh_token machen und keinen refresh_token haben?

581
dave mankoff

Die Idee von Aktualisierungstoken ist, dass der Angreifer bei einer Kompromittierung eines Zugriffstokens aufgrund seiner kurzen Lebensdauer nur ein begrenztes Fenster hat, in dem er es missbrauchen kann.

Aktualisierungs-Token sind nutzlos, wenn sie kompromittiert wurden, da der Angreifer zusätzlich zum Aktualisierungs-Token die Client-ID und das Geheimnis benötigt, um ein Zugriffstoken zu erhalten.

Allerdings , da jeder Aufruf sowohl an den Autorisierungsserver als auch an den Ressourcenserver über SSL erfolgt - einschließlich der ursprünglichen Client-ID und des Geheimnisses, wenn sie das anfordern Zugriffstoken/Aktualisierungstoken - Ich bin nicht sicher, wie das Zugriffstoken "kompromittierbarer" ist als die langlebige Kombination aus Aktualisierungstoken und Client-ID/Geheimnis.

Dies unterscheidet sich natürlich von Implementierungen, bei denen Sie nicht sowohl den Autorisierungs- als auch den Ressourcenserver steuern.

Hier ist ein guter Thread über die Verwendung von Aktualisierungstoken: OAuth Archives .

Ein Zitat aus dem Obigen, das die Sicherheitszwecke des Aktualisierungstokens beschreibt:

Token aktualisieren ... verringert das Risiko eines langlebigen Verlusts von access_token (Abfrageparameter in einer Protokolldatei auf einem unsicheren Ressourcenserver, einer Beta-Version oder einer schlecht codierten Ressourcenserver-App, JS SDK-Client auf einer Nicht-https-Site, die das access_token in eine Cookie usw.)

416
catchdave

Der von Catchdave bereitgestellte Link zur Diskussion enthält einen weiteren gültigen Punkt(ursprünglicher, toter Link von Dick Hardt, von dem ich glaube, dass er es wert ist, hier zusätzlich erwähnt zu werden was oben geschrieben wurde:

Meine Erinnerung an Refresh-Token diente der Sicherheit und dem Widerruf. <...>

Widerruf: Wenn das Zugriffstoken in sich geschlossen ist, kann die Autorisierung widerrufen werden, indem keine neuen Zugriffstoken ausgestellt werden. Eine Ressource muss den Autorisierungsserver nicht abfragen, um festzustellen, ob das Zugriffstoken gültig ist. Dies vereinfacht die Validierung des Zugriffstokens und erleichtert die Skalierung und Unterstützung mehrerer Autorisierungsserver. Es gibt ein Zeitfenster, in dem ein Zugriffstoken gültig ist, die Autorisierung jedoch widerrufen wird.

In der Tat ist es in Situationen, in denen Resource Server und Authorization Server dieselbe Entität sind und die Verbindung zwischen dem Benutzer und einem von beiden (normalerweise) gleichermaßen sicher ist, nicht sinnvoll, das Aktualisierungstoken vom Zugriffstoken zu trennen.

Wie im Zitat erwähnt, besteht eine weitere Rolle von Aktualisierungstoken darin, sicherzustellen, dass der Zugriffstoken vom Benutzer jederzeit widerrufen werden kann (z. B. über die Webschnittstelle in seinen Profilen), während das System gleichzeitig skalierbar bleibt .

Im Allgemeinen können Token entweder zufällige Bezeichner sein, die auf den bestimmten Datensatz in der Datenbank des Servers verweisen, oder sie können alle Informationen in sich selbst enthalten (diese Informationen müssen natürlich signiert sein, z. B. mit MAC ).

Wie das System mit langlebigen Zugriffstoken funktionieren soll

Der Server ermöglicht dem Client den Zugriff auf Benutzerdaten in einem vordefinierten Umfang durch Ausgabe eines Tokens. Da wir das Token widerruflich halten möchten, müssen wir das Token zusammen mit dem gesetzten oder nicht gesetzten Flag "widerrufene" in der Datenbank speichern (ansonsten, wie würden Sie das mit dem in sich geschlossenen Token tun?). Die Datenbank kann so viel enthalten wie len(users) x len(registered clients) x len(scopes combination) Datensätze. Jede API-Anfrage muss dann die Datenbank treffen. Obwohl es ziemlich trivial ist, Abfragen an eine solche Datenbank zu richten, die O (1) ausführt, kann der einzelne Fehlerpunkt selbst negative Auswirkungen auf die Skalierbarkeit und Leistung des Systems haben.

Wie das System mit langlebigem Aktualisierungstoken und kurzlebigem Zugriffstoken funktionieren soll

Hier stellen wir zwei Schlüssel aus: ein zufälliges Aktualisierungstoken mit dem entsprechenden Datensatz in der Datenbank und ein signiertes, in sich geschlossenes Zugriffstoken, das unter anderem das Feld für den Ablaufzeitstempel enthält.

Da das Zugriffstoken in sich geschlossen ist, müssen wir die Datenbank überhaupt nicht überprüfen, um ihre Gültigkeit zu überprüfen. Alles, was wir tun müssen, ist das Token zu dekodieren und die Signatur und den Zeitstempel zu validieren.

Trotzdem müssen wir die Datenbank der Aktualisierungstoken behalten, aber die Anzahl der Anforderungen an diese Datenbank wird im Allgemeinen durch die Lebensdauer des Zugriffstokens bestimmt (je länger die Lebensdauer, desto niedriger die Zugriffsrate).

Um den Clientzugriff eines bestimmten Benutzers zu widerrufen, sollten wir das entsprechende Aktualisierungstoken als "widerrufen" markieren (oder es vollständig entfernen) und die Ausgabe neuer Zugriffstoken einstellen. Es ist jedoch offensichtlich, dass es ein Fenster gibt, in dem das Aktualisierungstoken widerrufen wurde, sein Zugriffstoken jedoch möglicherweise noch gültig ist.

Kompromisse

Aktualisierungstoken beseitigen teilweise die SPoF (Single Point of Failure) der Access Token-Datenbank, weisen jedoch einige offensichtliche Nachteile auf.

  1. Das Fenster". Ein Zeitraum zwischen den Ereignissen "Benutzer widerruft den Zugriff" und "Zugriff wird garantiert widerrufen".

  2. Die Komplikation der Client-Logik.

    ohne Aktualisierungstoken

    • aPI-Anfrage mit Zugriffstoken senden
    • wenn das Zugriffstoken ungültig ist, schlagen Sie fehl und bitten Sie den Benutzer, sich erneut zu authentifizieren

    mit Refresh-Token

    • aPI-Anfrage mit Zugriffstoken senden
    • Wenn das Zugriffstoken ungültig ist, versuchen Sie, es mit dem Aktualisierungstoken zu aktualisieren
    • wenn die Aktualisierungsanforderung erfolgreich ist, aktualisieren Sie das Zugriffstoken und senden Sie die ursprüngliche API-Anforderung erneut
    • Wenn die Aktualisierungsanforderung fehlschlägt, bitten Sie den Benutzer, sich erneut zu authentifizieren

Ich hoffe, diese Antwort macht Sinn und hilft jemandem, nachdenklichere Entscheidungen zu treffen. Ich möchte auch erwähnen, dass einige bekannte OAuth2-Anbieter, einschließlich Github und Foursquare, das Protokoll ohne Aktualisierungstoken übernehmen und damit zufrieden zu sein scheinen.

519
Roman Imankulov

Trotz all der großartigen Antworten oben kann ich als Student und Programmierer im Bereich Sicherheit, der zuvor bei eBay gearbeitet hat, als ich mich mit Käuferschutz und Betrug befasst habe, sagen, dass die Trennung von Zugriffstoken und Aktualisierungstoken das beste Gleichgewicht hat = zwischen Belästigung des Benutzers durch häufige Eingabe von Benutzername/Passwort und Beibehaltung der Berechtigung zum Widerruf des Zugriffs auf potenziellen Missbrauch Ihres Dienstes.

Stellen Sie sich ein Szenario wie dieses vor. Sie stellen einen Benutzer mit einem Zugriffstoken von 3600 Sekunden aus und aktualisieren das Token deutlich länger als einen Tag.

  1. Der Benutzer ist ein guter Benutzer, er ist zu Hause und geht auf Ihrer Website einkaufen und auf seinem iPhone suchen. Seine IP-Adresse ändert sich nicht und belastet Ihren Server nur sehr wenig. Wie 3-5 Seitenanfragen pro Minute. Nach Ablauf seiner 3600 Sekunden für das Zugriffstoken benötigt er ein neues mit dem Aktualisierungstoken. Wir überprüfen auf der Serverseite seinen Aktivitätsverlauf und seine IP-Adresse, halten ihn für einen Menschen und verhalten uns wie er. Wir gewähren ihm ein neues Zugriffstoken, um unseren Service weiter nutzen zu können. Der Benutzer muss den Benutzernamen/das Kennwort erst dann erneut eingeben, wenn er selbst die Lebensdauer des Aktualisierungstokens von einem Tag erreicht hat.

  2. Der Benutzer ist ein nvorsichtiger Benutzer. Er lebt in New York, USA und hat sein Virenprogramm heruntergefahren und wurde von einem Hacker in Polen gehackt. Wenn der Hacker das Zugriffstoken und das Aktualisierungstoken erhalten hat, versucht er, sich als Benutzer auszugeben und unseren Service zu nutzen. Aber nach Ablauf des kurzfristigen Zugriffstokens hat der Hacker beim Versuch, das Zugriffstoken zu aktualisieren, auf dem Server eine dramatische Änderung der IP-Adresse im Verlauf des Benutzerverhaltens festgestellt (hey, dieser Typ meldet sich in den USA an und aktualisiert nun den Zugriff in Polen nach nur 3600s ???). Wir beenden den Aktualisierungsprozess, machen das Aktualisierungstoken selbst ungültig und fordern zur erneuten Eingabe von Benutzername/Passwort auf.

  3. Der Benutzer ist ein böswilliger Benutzer. Er soll unseren Service missbrauchen, indem er mit einem Roboter 1000-mal pro Minute unsere API aufruft. Bis 3600 Sekunden später, als er versucht, das Zugriffstoken zu aktualisieren, kann er dies problemlos tun. Wir haben sein Verhalten bemerkt und glauben, dass er möglicherweise kein Mensch ist. Wir lehnen den Aktualisierungsvorgang ab, beenden ihn und bitten ihn, den Benutzernamen/das Passwort erneut einzugeben. Dies könnte möglicherweise den automatischen Fluss seines Roboters stören. Zumindest fühlt er sich unwohl.

Sie können sehen, dass das Aktualisierungstoken einwandfrei funktioniert hat, wenn wir versuchen, Arbeit, Benutzererfahrung und das potenzielle Risiko eines gestohlenen Tokens in Einklang zu bringen. Ihr Watchdog auf der Serverseite kann mehr als IP-Änderungen und die Häufigkeit von API-Aufrufen überprüfen, um festzustellen, ob der Benutzer ein guter Benutzer sein soll oder nicht.

Ein anderes Wort ist, dass Sie auch versuchen können, die Schadensbegrenzung von gestohlenem Token/Dienstmissbrauch einzuschränken, indem Sie auf jeder API den grundlegenden IP-Watchdog oder andere Maßnahmen implementieren. Dies ist jedoch teuer, da Sie Aufzeichnungen über den Benutzer lesen und schreiben müssen. Dadurch wird die Reaktion des Servers verlangsamt.

163
laalaguer

Keine dieser Antworten führt zum eigentlichen Grund, warum Aktualisierungstoken vorhanden sind. Offensichtlich können Sie immer ein neues Access-Token/Refresh-Token-Paar erhalten, indem Sie Ihre Client-Anmeldeinformationen an den Authentifizierungsserver senden. So erhalten Sie sie in erster Linie.

Der einzige Zweck des Aktualisierungstokens besteht darin, die Verwendung der Client-Anmeldeinformationen zu beschränken, die über das Kabel an den Authentifizierungsdienst gesendet werden. Je kürzer die Gültigkeitsdauer des Zugriffstokens ist, desto häufiger müssen die Client-Anmeldeinformationen verwendet werden, um ein neues Zugriffstoken zu erhalten, und desto mehr Möglichkeiten haben Angreifer, die Client-Anmeldeinformationen zu gefährden (obwohl dies ohnehin sehr schwierig sein kann, wenn asymmetrische Verschlüsselung wird verwendet, um sie zu senden). Wenn Sie also ein Einmal-Aktualisierungstoken haben, können Sie die Anzahl der Zugriffstoken beliebig klein machen, ohne die Client-Anmeldeinformationen zu beeinträchtigen.

67
B T

Um einige Unklarheiten zu beseitigen, müssen Sie die Rollen des Client-Geheimnis und des Benutzer-Passwort ​​verstehen, die sehr unterschiedlich sind.

Der Client ​​ist eine App/Website/Programm/..., die von einem Server unterstützt wird und authentifizieren einen Benutzer mithilfe eines dritten Benutzers Authentifizierungsservice. Das Client-Geheimnis ist eine (zufällige) Zeichenfolge, die sowohl diesem Client als auch dem Authentifizierungsserver bekannt ist. Unter Verwendung dieses Geheimnisses kann sich der Client mit dem Authentifizierungsserver identifizieren und erhält authorisation, um Zugriffstoken anzufordern.

Um das erste Zugriffstoken und das Aktualisierungstoken abzurufen, ist Folgendes erforderlich:

  • Die Benutzer-ID
  • Das Benutzerpasswort
  • Die Kundennummer
  • Das Kundengeheimnis

Um jedoch ein aktualisiertes Zugriffstoken zu erhalten, verwendet client ​​die folgenden Informationen:

  • Die Kundennummer
  • Das Kundengeheimnis
  • Das Aktualisierungstoken

Dies macht den Unterschied deutlich: Beim Aktualisieren erhält der Client die Berechtigung zum Aktualisieren von Zugriffstoken unter Verwendung seines Clientgeheimnisses und kann den Benutzer daher mit dem Aktualisierungstoken stattdessen der Benutzer-ID + des Kennworts erneut authentifizieren. Dies verhindert effektiv, dass der Benutzer sein/ihr Passwort erneut eingeben muss.

Dies zeigt auch, dass der Verlust eines Aktualisierungstokens kein Problem darstellt, da die Client-ID und das Geheimnis nicht bekannt sind. Es zeigt auch, dass es wichtig ist, die Kunden-ID und das Kundengeheimnis geheim zu halten vital.

45
Adversus

Diese Antwort stammt von Justin Richer über die Standard-E-Mail-Liste OAuth 2. Dies wird mit seiner Erlaubnis gepostet.


Die Lebensdauer eines Aktualisierungstokens hängt vom Autorisierungsserver (AS) ab - er kann ablaufen, widerrufen werden usw. Der Unterschied zwischen einem Aktualisierungstoken und einem Zugriffstoken besteht in der Zielgruppe: Das Aktualisierungstoken wird nur an den Autorisierungsserver zurückgegeben. Das Zugriffstoken wird an den (RS) -Ressourcenserver gesendet.

Nur ein Zugriffstoken zu erhalten, bedeutet nicht, dass der Benutzer angemeldet ist. Tatsächlich ist der Benutzer möglicherweise nicht mehr dort, was eigentlich der beabsichtigte Anwendungsfall für das Aktualisierungstoken ist. Wenn Sie das Zugriffstoken aktualisieren, erhalten Sie im Namen des Benutzers Zugriff auf eine API. Sie erfahren nicht, ob der Benutzer dort ist.

OpenID Connect gibt Ihnen nicht nur Benutzerinformationen aus einem Zugriffstoken, sondern auch einen ID-Token. Hierbei handelt es sich um ein separates Datenelement, das an den Client selbst gerichtet ist, nicht an das AS oder das RS. In OIDC sollten Sie jemanden, der tatsächlich vom Protokoll "angemeldet" ist, nur dann als "angemeldet" betrachten, wenn Sie ein neues ID-Token erhalten können. Eine Erfrischung ist wahrscheinlich nicht genug.

Weitere Informationen finden Sie unter http://oauth.net/articles/authentication/

35
Manicode

Clients können auf viele Arten kompromittiert werden. Zum Beispiel kann ein Handy geklont werden. Das Ablaufen eines Zugriffstokens bedeutet, dass der Client gezwungen ist, sich erneut beim Autorisierungsserver zu authentifizieren. Während der erneuten Authentifizierung kann der Autorisierungsserver andere Merkmale überprüfen (IOW führt eine adaptive Zugriffsverwaltung durch).

Aktualisierungstoken ermöglichen einem Client nur eine erneute Authentifizierung, wobei die erneute Autorisierung einen Dialog mit dem Benutzer erzwingt, von dem viele angegeben haben, dass sie dies lieber nicht tun würden.

Aktualisierungstoken befinden sich im Wesentlichen an derselben Stelle, an der normale Websites Benutzer nach etwa einer Stunde möglicherweise regelmäßig erneut authentifizieren (z. B. Banking-Site). Es wird derzeit nicht häufig verwendet, da die meisten sozialen Websites die Webbenutzer nicht erneut authentifizieren. Warum sollten sie also einen Client erneut authentifizieren?

18
Phil

Um die Antwort von BT weiter zu vereinfachen: Verwenden Sie Aktualisierungstoken, wenn Sie normalerweise nicht möchten, dass der Benutzer die Anmeldeinformationen erneut eingeben muss, die Berechtigung jedoch widerrufen kann (indem Sie das Aktualisierungstoken widerrufen).

Sie können kein Zugriffstoken, sondern nur ein Aktualisierungstoken widerrufen.

11
bitcoder

Warum nicht einfach das access_token so lange wie das refresh_token halten und kein refresh_token haben?

Neben tollen Antworten, die andere Personen gegeben haben, gibt es noch einen weiteren Grund, warum Refresh-Token verwendet werden und dies mit Ansprüchen zu tun hat.

Jedes Token enthält Ansprüche, die aus dem Benutzernamen, ihren Rollen oder dem Anbieter, der den Anspruch erstellt hat, stammen können. Wenn ein Token aktualisiert wird, werden diese Ansprüche aktualisiert.

Wenn wir die Token öfter aktualisieren, belasten wir offensichtlich unsere Identitätsdienste stärker, aber wir erhalten genauere und aktuellere Angaben.

10
heymega

Angenommen, Sie haben das access_token für eine sehr lange Lebensdauer und kein refresh_token, sodass Hacker an einem Tag dieses access_token erhalten und auf alle geschützten Ressourcen zugreifen können!

Wenn Sie jedoch refresh_token haben, ist die Live-Zeit des access_token kurz, sodass der Hacker Ihr access_token nur schwer hacken kann, da es nach kurzer Zeit ungültig wird. Access_token kann nur mithilfe von refresh_token, client_id und client_secret, die Hacker nicht haben, wiederhergestellt werden.

5
Tạ Anh Tú

Während das Aktualisierungstoken vom Autorisierungsserver aufbewahrt wird. Das Zugriffstoken ist in sich geschlossen, sodass der Ressourcenserver es überprüfen kann, ohne es zu speichern, was den Aufwand für das Abrufen im Falle einer Validierung erspart. Ein weiterer Punkt, der in der Diskussion fehlt, stammt aus rfc6749 # page-55

Beispielsweise könnte der Autorisierungsserver eine Aktualisierungstokenrotation verwenden, bei der bei jeder Antwort auf die Aktualisierung des Zugriffstokens ein neues Aktualisierungstoken ausgegeben wird. Das vorherige Aktualisierungstoken wird ungültig gemacht, aber vom Autorisierungsserver beibehalten. Wenn ein Aktualisierungstoken kompromittiert und anschließend von verwendet wird Sowohl der Angreifer als auch der legitime Client legen ein ungültiges Aktualisierungstoken vor, das den Autorisierungsserver über die Sicherheitsverletzung informiert. "

Ich denke, der springende Punkt bei der Verwendung von Refresh-Token ist, dass es dem Angreifer irgendwie gelingt, Refresh-Token, Client-ID und geheime Kombination zu erhalten. Bei nachfolgenden Aufrufen, um ein neues Zugriffstoken vom Angreifer zu erhalten, kann nachverfolgt werden, ob jede Auffrischungsanforderung ein neues Zugriffstoken und ein neues Aktualisierungstoken zur Folge hat.

2
Kraming

Diese Antwort wurde mithilfe von zwei hochrangigen Entwicklern (John Brayton und David Jennes) zusammengestellt.

Der Hauptgrund für die Verwendung eines Aktualisierungstokens ist die Reduzierung der Angriffsfläche.

Angenommen, es gibt keinen Aktualisierungsschlüssel, und wir gehen das folgende Beispiel durch:

Ein Gebäude hat 80 Türen. Alle Türen werden mit dem gleichen Schlüssel geöffnet. Der Schlüssel wechselt alle 30 Minuten.

Wenn ich der Hacker bin und Ihren Schlüssel bekomme, dann werde ich das nach Ablauf der 30 Minuten dem Schlüsselmacher zusenden und einen neuen Schlüssel besorgen. Ich kann kontinuierlich alle Türen öffnen, unabhängig vom Schlüsselwechsel.

Frage: Wie viele Hacking-Möglichkeiten hatte ich in den 30 Minuten gegen den Schlüssel? Ich hatte jedes Mal 80 Hacking-Möglichkeiten, wenn Sie den Schlüssel verwendeten (stellen Sie sich dies als eine Netzwerkanfrage vor und übergeben Sie das Zugriffstoken, um sich zu identifizieren). Das ist also die 80-fache Angriffsfläche.

Lassen Sie uns nun dasselbe Beispiel durchgehen, aber dieses Mal nehmen wir an, dass es einen Aktualisierungsschlüssel gibt.

Ein Gebäude hat 80 Türen. Alle Türen werden mit dem gleichen Schlüssel geöffnet. Der Schlüssel wechselt alle 30 Minuten. Wenn ich der Hacker bin und Ihren Schlüssel bekomme, kann ich ihn 30 Minuten lang verwenden, aber nach Ablauf der 30 Minuten hat das Senden an den Schlüsselmacher keinen Wert. Wenn ich das tue, würde der Schlüsselmacher einfach sagen, dass dieser Schlüssel abgelaufen ist. Um meinen Hack verlängern zu können, müsste ich den Kurier zum Schlüsselmacher hacken. Der Kurier hat einen eindeutigen Schlüssel (stellen Sie sich dies als Auffrischungstoken vor).

Frage: Wie viele Hacking-Möglichkeiten hatte ich in den 30 Minuten gegen den Kurier? 80? Nein, ich hatte nur eine Gelegenheit zum Hacken. Während der Zeit kommuniziert der Kurier mit dem Schlüsselmacher. Das ist also 1X Angriffsfläche. Ich hatte 80 Hacking-Möglichkeiten gegen den Schlüssel, aber sie sind nach 30 Minuten nicht gut.


Ein Server überprüft ein Zugriffstoken basierend auf Anmeldeinformationen und dem Signieren (normalerweise) eines JWT.

Ein auslaufendes Zugriffstoken ist schlecht, aber wenn es abgelaufen ist, ist es für einen Angreifer nicht mehr nützlich. Das Auslaufen eines Auffrischungs-Tokens ist weitaus schlimmer, aber vermutlich weniger wahrscheinlich. (Ich denke, es gibt Raum, um zu hinterfragen, ob die Wahrscheinlichkeit eines Lecks von Aktualisierungstoken viel geringer ist als die eines Lecks von Zugriffstoken, aber das ist die Idee.)

Der Punkt ist, dass das Zugriffstoken zu jeder von Ihnen gestellten Anforderung hinzugefügt wird, wohingegen ein Aktualisierungstoken nur während des Aktualisierungsflusses verwendet wird. Daher ist die Wahrscheinlichkeit geringer, dass ein MITM das Token sieht

Frequenz hilft einem Angreifer. Heartbleed - Wie potenzielle Sicherheitslücken in SSL, potenzielle Sicherheitslücken im Client und potenzielle Sicherheitslücken im Server machen alle Leckagen möglich.

Wenn der Autorisierungsserver von dem Anwendungsserver, der andere Clientanforderungen verarbeitet, getrennt ist, werden diesem Anwendungsserver keine Aktualisierungstoken angezeigt. Es werden nur Zugriffstoken angezeigt, die nicht mehr lange gültig sind.

Kompartimentierung ist gut für die Sicherheit.


Um welches Aktualisierungstoken handelt es sich NICHT?

Die Möglichkeit zum Aktualisieren/Widerrufen der Zugriffsebene über Aktualisierungstoken ist ein Nebeneffekt der Verwendung von Aktualisierungstoken. Andernfalls kann ein eigenständiges Zugriffstoken widerrufen oder seine Zugriffsebene geändert werden, wenn es abläuft und Benutzer ein neues Token erhalten. “

1
Honey

Zunächst authentifiziert sich der Client beim Autorisierungsserver, indem er die Autorisierungsgewährung erteilt.

Anschließend fordert der Client den Ressourcenserver nach der geschützten Ressource an, indem er das Zugriffstoken erteilt.

Der Ressourcenserver überprüft das Zugriffstoken und stellt die geschützte Ressource bereit.

Der Client sendet die geschützte Ressourcenanforderung an den Ressourcenserver, indem er das Zugriffstoken erteilt, das der Ressourcenserver validiert und die Anforderung, falls gültig, verarbeitet. Dieser Schritt wird so lange wiederholt, bis das Zugriffstoken abläuft.

Wenn das Zugriffstoken abläuft, authentifiziert sich der Client beim Autorisierungsserver und fordert ein neues Zugriffstoken an, indem er ein Aktualisierungstoken bereitstellt. Wenn das Zugriffstoken ungültig ist, sendet der Ressourcenserver die ungültige Tokenfehlerantwort an den Client zurück.

Der Client authentifiziert sich beim Autorisierungsserver, indem er das Aktualisierungstoken erteilt.

Der Autorisierungsserver validiert dann das Aktualisierungstoken durch Authentifizierung des Clients und stellt ein neues Zugriffstoken aus, falls es gültig ist.

0
user8288060

Wir betrachten ein System, in dem jeder Benutzer mit einer oder mehreren Rollen und jede Rolle mit einer oder mehreren Zugriffsberechtigungen verknüpft ist. Diese Informationen können für eine bessere API-Leistung zwischengespeichert werden. Dann können sich jedoch Änderungen in den Benutzer- und Rollenkonfigurationen ergeben (beispielsweise kann ein neuer Zugriff gewährt oder der aktuelle Zugriff widerrufen werden), die sich im Cache widerspiegeln sollten.

Wir können zu diesem Zweck Zugriffs- und Aktualisierungstoken verwenden. Wenn eine API mit Zugriffstoken aufgerufen wird, überprüft der Ressourcenserver den Cache auf Zugriffsrechte. Wenn es neue Zugangsberechtigungen gibt, werden diese nicht sofort berücksichtigt. Sobald das Zugriffstoken abläuft (z. B. in 30 Minuten) und der Client das Aktualisierungstoken verwendet, um ein neues Zugriffstoken zu generieren, kann der Cache mit den aktualisierten Benutzerzugriffsrechtsinformationen aus der Datenbank aktualisiert werden.

Mit anderen Worten, wir können die teuren Vorgänge von jedem API-Aufruf unter Verwendung von Zugriffstoken auf das Ereignis der Generierung von Zugriffstoken unter Verwendung von Aktualisierungstoken verschieben.

0
Saptarshi Basu