In Abschnitt 4.2 des Entwurfs des OAuth 2.0-Protokolls wird angegeben, dass ein Autorisierungsserver sowohl einen access_token(der zur Authentifizierung bei einer Ressource verwendet wird) als auch einen refresh_token(der lediglich zum Erstellen einer neuen Ressource verwendet wird) zurückgeben kann access_token:
https://tools.ietf.org/html/rfc6749#section-4.2
Warum beides? Warum nicht einfach das access_tokenletzte so lange machen wie das refresh_tokenund kein haben refresh_token?
Antworten:
Die Idee von Aktualisierungstoken ist, dass der Angreifer, wenn ein Zugriffstoken kompromittiert wird, weil es nur von kurzer Dauer ist, ein begrenztes Fenster hat, in dem er es missbrauchen kann.
Aktualisierungstoken sind, wenn sie kompromittiert wurden, nutzlos, da der Angreifer zusätzlich zum Aktualisierungstoken die Client-ID und das Geheimnis benötigt, um ein Zugriffstoken zu erhalten.
Da jedoch jeder Aufruf sowohl des Autorisierungsservers als auch des Ressourcenservers über SSL erfolgt - einschließlich der ursprünglichen Client-ID und des Geheimnisses, wenn sie die Zugriffs- / Aktualisierungstoken anfordern - bin ich mir nicht sicher, wie das Zugriffstoken nicht mehr funktioniert. " kompromittierbar "als die langlebige Kombination aus Aktualisierungstoken und Client-ID / Geheimnis.
Dies unterscheidet sich natürlich von Implementierungen, bei denen Sie nicht sowohl die Autorisierungs- als auch die Ressourcenserver steuern.
Hier ist ein guter Thread über die Verwendung von Aktualisierungstoken: OAuth Archives .
Ein Zitat aus dem oben Gesagten über die Sicherheitszwecke des Aktualisierungstokens:
Token aktualisieren ... verringert das Risiko eines langlebigen Verlusts von access_token (Abfrageparameter in einer Protokolldatei auf einem unsicheren Ressourcenserver, einer Beta-App oder einer schlecht codierten Ressourcenserver-App, JS SDK-Client auf einer Nicht-https-Site, die das access_token in a ablegt Keks usw.)
Der von Catchdave bereitgestellte Link zur Diskussion enthält einen weiteren gültigen Punkt (Original, toter Link) von Dick Hardt, der meines Erachtens hier zusätzlich zu den oben genannten Punkten erwähnt werden sollte:
Meine Erinnerung an Aktualisierungstoken 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 der Situation, in der Ressourcenserver und Autorisierungsserver dieselbe Entität sind und die Verbindung zwischen Benutzer und einem von beiden (normalerweise) gleich sicher ist, wenig sinnvoll, das Aktualisierungstoken vom Zugriffstoken getrennt zu halten.
Wie im Zitat erwähnt, besteht eine weitere Rolle von Aktualisierungstoken darin, sicherzustellen, dass das Zugriffstoken vom Benutzer jederzeit widerrufen werden kann (z. B. über die Weboberfläche 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 Serverdatenbank verweisen, oder sie können alle Informationen in sich enthalten (diese Informationen müssen natürlich signiert werden , z. B. mit MAC ).
Wie das System mit langlebigen Zugriffstoken funktionieren sollte
Der Server ermöglicht dem Client den Zugriff auf Benutzerdaten innerhalb eines vordefinierten Bereichs von Bereichen, indem ein Token ausgegeben wird. Da wir das Token widerruflich halten möchten, müssen wir das Token zusammen mit dem gesetzten oder nicht gesetzten Flag "widerrufen" in der Datenbank speichern (andernfalls, wie würden Sie das mit einem in sich geschlossenen Token tun?). Die Datenbank kann so viel wie len(users) x len(registered clients) x len(scopes combination)Datensätze enthalten . Jede API-Anfrage muss dann die Datenbank treffen. Obwohl es ziemlich trivial ist, Abfragen an eine solche Datenbank mit O (1) durchzuführen, kann der einzelne Fehlerpunkt selbst negative Auswirkungen auf die Skalierbarkeit und Leistung des Systems haben.
Wie das System mit dem langlebigen Aktualisierungstoken und dem kurzlebigen Zugriffstoken funktionieren sollte
Hier geben wir zwei Schlüssel aus: zufälliges Aktualisierungstoken mit dem entsprechenden Datensatz in der Datenbank und signiertes eigenständiges Zugriffstoken, das unter anderem das Ablaufzeitstempelfeld enthält.
Da das Zugriffstoken in sich geschlossen ist, müssen wir die Datenbank überhaupt nicht aufrufen, 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 beibehalten, aber die Anzahl der Anforderungen an diese Datenbank wird im Allgemeinen durch die Lebensdauer des Zugriffstokens definiert (je länger die Lebensdauer, desto niedriger die Zugriffsrate).
Um den Zugriff eines bestimmten Benutzers auf den Client zu widerrufen, sollten wir das entsprechende Aktualisierungstoken als "widerrufen" markieren (oder vollständig entfernen) und die Ausgabe neuer Zugriffstoken einstellen. Es ist zwar offensichtlich, dass es ein Fenster gibt, in dem das Aktualisierungstoken widerrufen wurde, aber sein Zugriffstoken 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.
Das Fenster". Ein Zeitraum zwischen den Ereignissen "Benutzer widerruft den Zugriff" und "Zugriff wird garantiert widerrufen".
Die Komplikation der Client-Logik.
ohne Aktualisierungstoken
mit Aktualisierungstoken
Ich hoffe, diese Antwort macht Sinn und hilft jemandem, nachdenklichere Entscheidungen zu treffen. Ich möchte auch darauf hinweisen, dass einige bekannte OAuth2-Anbieter, darunter Github und Foursquare, Protokolle ohne Aktualisierungstoken übernehmen und damit zufrieden zu sein scheinen.
Trotz all der großartigen Antworten oben kann ich als Sicherheits-Masterstudent und Programmierer, der zuvor bei eBay gearbeitet hat, als ich mich mit Käuferschutz und Betrug befasst habe, sagen, dass das Trennen von Zugriffstoken und Aktualisierungstoken das beste Gleichgewicht zwischen der Belästigung von Benutzern mit häufigem Benutzernamen aufweist / Passwort eingeben und die Autorität in der Hand halten, um den Zugriff auf potenziellen Missbrauch Ihres Dienstes zu widerrufen .
Stellen Sie sich ein solches Szenario vor. Sie stellen dem Benutzer ein Zugriffstoken von 3600 Sekunden aus und aktualisieren das Token viel länger als einen Tag.
Der Benutzer ist ein guter Benutzer, er ist zu Hause und kann auf seiner Website einkaufen und auf seinem iPhone suchen. Seine IP-Adresse ändert sich nicht und Ihr Server ist sehr wenig belastet. Wie 3-5 Seitenanfragen pro Minute. Wenn seine 3600 Sekunden auf dem Zugriffstoken abgelaufen sind, benötigt er einen neuen mit dem Aktualisierungstoken. Wir auf der Serverseite überprüfen seinen Aktivitätsverlauf und seine IP-Adresse, halten ihn für einen Menschen und verhalten uns selbst. Wir gewähren ihm ein neues Zugriffstoken, um unseren Service weiterhin nutzen zu können. Der Benutzer muss den Benutzernamen / das Kennwort erst erneut eingeben, wenn er die eintägige Lebensdauer des Aktualisierungstokens selbst erreicht hat.
Der Benutzer ist ein unachtsamer Benutzer. Er lebt in New York, USA, hat sein Virenprogramm beendet 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 nachdem das Short-Live-Zugriffstoken abgelaufen ist und der Hacker versucht, das Zugriffstoken zu aktualisieren, haben wir auf dem Server eine dramatische IP-Änderung im Verlauf des Benutzerverhaltens festgestellt (hey, dieser Typ meldet sich in den USA an und aktualisiert jetzt den Zugriff in Polen nach nur 3600s ???). Wir beenden den Aktualisierungsprozess, machen das Aktualisierungstoken selbst ungültig und fordern Sie auf, den Benutzernamen / das Kennwort erneut einzugeben.
Der Benutzer ist ein böswilliger Benutzer. Er soll unseren Service missbrauchen, indem er 1000-mal pro Minute unsere API mit einem Roboter aufruft. Er kann dies gut tun, bis 3600 Sekunden später, als er versucht, das Zugriffstoken zu aktualisieren, wir sein Verhalten bemerkt haben und denken, 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 unterbrechen. Zumindest macht es ihm unangenehm.
Sie können sehen, dass das Aktualisierungstoken perfekt funktioniert hat, wenn wir versuchen, unsere Arbeit, Benutzererfahrung und das potenzielle Risiko eines gestohlenen Tokens in Einklang zu bringen. Ihr Wachhund auf der Serverseite kann mehr als die IP-Änderung 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 Schadenskontrolle durch gestohlene Token / Dienstmissbrauch zu begrenzen, indem Sie bei jedem API-Aufruf den grundlegenden IP-Wachhund oder andere Maßnahmen implementieren. Dies ist jedoch teuer, da Sie Aufzeichnungen über den Benutzer lesen und schreiben müssen und die Serverantwort verlangsamen.
Keine dieser Antworten kommt zum Hauptgrund, warum Aktualisierungstoken existieren. Natürlich 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 zunächst.
Der einzige Zweck des Aktualisierungstokens besteht darin, die Verwendung der Client-Anmeldeinformationen zu beschränken, die über die Leitung an den Authentifizierungsdienst gesendet werden. Je kürzer die ttl des Zugriffstokens ist, desto häufiger müssen die Clientanmeldeinformationen verwendet werden, um ein neues Zugriffstoken zu erhalten, und desto mehr Möglichkeiten haben Angreifer, die Clientanmeldeinformationen zu gefährden (obwohl dies ohnehin sehr schwierig sein kann, wenn Zum Senden wird eine asymmetrische Verschlüsselung verwendet. Wenn Sie also über ein einmaliges Aktualisierungstoken verfügen, können Sie die Anzahl der Zugriffstoken beliebig klein machen, ohne die Clientanmeldeinformationen zu beeinträchtigen.
Um Verwirrung zu beseitigen, müssen Sie die Rollen des Client-Geheimnisses und des Benutzerkennworts verstehen , die sehr unterschiedlich sind.
Der Client ist eine App / Website / Programm / ..., die von einem Server unterstützt wird und einen Benutzer mithilfe eines Authentifizierungsdienstes eines Drittanbieters authentifizieren möchte . Das Client-Geheimnis ist eine (zufällige) Zeichenfolge, die sowohl diesem Client als auch dem Authentifizierungsserver bekannt ist. Mithilfe dieses Geheimnisses kann sich der Client mit dem Authentifizierungsserver identifizieren und erhält die Berechtigung , Zugriffstoken anzufordern.
Um das Erstzugriffstoken und das Aktualisierungstoken zu erhalten, ist Folgendes erforderlich:
Um ein aktualisiertes Zugriffstoken zu erhalten, verwendet der Client jedoch die folgenden Informationen:
Dies zeigt deutlich den Unterschied: Beim Aktualisieren erhält der Client die Berechtigung zum Aktualisieren von Zugriffstoken unter Verwendung seines Clientgeheimnisses und kann den Benutzer somit mithilfe des Aktualisierungstokens anstelle der Benutzer-ID + des Kennworts erneut authentifizieren . Dies verhindert effektiv, dass der Benutzer sein 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 Client-ID und das Client-Geheimnis geheim zu halten .
Diese Antwort stammt von Justin Richer über die OAuth 2-Standard-E-Mail-Liste. Dies wird mit seiner Erlaubnis veröffentlicht.
Die Lebensdauer eines Aktualisierungstokens hängt vom (AS) Autorisierungsserver ab - sie können ablaufen, widerrufen werden usw. Der Unterschied zwischen einem Aktualisierungstoken und einem Zugriffstoken besteht in der Zielgruppe: Das Aktualisierungstoken geht nur auf den Autorisierungsserver zurück. Das Zugriffstoken geht an den (RS) -Ressourcenserver.
Nur ein Zugriffstoken zu erhalten, bedeutet nicht, dass der Benutzer angemeldet ist. Tatsächlich ist der Benutzer möglicherweise nicht einmal mehr dort, was eigentlich der beabsichtigte Anwendungsfall des Aktualisierungstokens ist. Durch das Aktualisieren des Zugriffstokens 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 von einem Zugriffstoken, sondern auch ein ID-Token. Dies ist ein separates Datenelement, das an den Client selbst gerichtet ist, nicht an den AS oder den RS. In OIDC sollten Sie nur dann berücksichtigen, dass jemand vom Protokoll tatsächlich „angemeldet“ ist, wenn Sie ein neues ID-Token erhalten können. Es ist wahrscheinlich nicht genug, es zu aktualisieren.
Weitere Informationen finden Sie unter http://oauth.net/articles/authentication/.
Kunden können auf viele Arten kompromittiert werden. Zum Beispiel kann ein Handy geklont werden. Wenn ein Zugriffstoken abläuft, muss sich der Client erneut beim Autorisierungsserver authentifizieren. Während der erneuten Authentifizierung kann der Autorisierungsserver andere Merkmale überprüfen (IOW führt eine adaptive Zugriffsverwaltung durch).
Aktualisierungstoken ermöglichen nur die erneute Authentifizierung eines Clients, wobei beim erneuten Autorisieren ein Dialog mit dem Benutzer erzwungen wird, den viele angegeben haben, dass sie dies lieber nicht tun würden.
Aktualisierungstoken passen im Wesentlichen an dieselbe Stelle, an der normale Websites Benutzer nach etwa einer Stunde regelmäßig erneut authentifizieren (z. B. Bank-Website). Es wird derzeit nicht häufig verwendet, da die meisten sozialen Websites Webbenutzer nicht erneut authentifizieren. Warum sollten sie einen Client erneut authentifizieren?
Warum nicht einfach das access_token so lange wie das refresh_token halten und kein refresh_token haben?
Neben den großartigen Antworten, die andere Personen gegeben haben, gibt es noch einen weiteren Grund, warum Aktualisierungstoken verwendet werden sollten, und dies hat mit Ansprüchen zu tun.
Jedes Token enthält Ansprüche, die alles aus dem Benutzernamen, ihren Rollen oder dem Anbieter enthalten können, der den Anspruch erstellt hat. Wenn ein Token aktualisiert wird, werden diese Ansprüche aktualisiert.
Wenn wir die Token häufiger aktualisieren, belasten wir offensichtlich unsere Identitätsdienste stärker, erhalten jedoch genauere und aktuellere Ansprüche.
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 weiterhin die Berechtigungen widerrufen kann (indem Sie das Aktualisierungstoken widerrufen).
Sie können ein Zugriffstoken nicht widerrufen, sondern nur ein Aktualisierungstoken.
Diese Antwort wurde mit Hilfe von zwei erfahrenen Entwicklern (John Brayton und David Jennes) zusammengestellt.
Der Hauptgrund für die Verwendung eines Aktualisierungstokens besteht darin, die Angriffsfläche zu verringern.
Nehmen wir an, es gibt keinen Aktualisierungsschlüssel und gehen wir dieses Beispiel durch:
Ein Gebäude hat 80 Türen. Alle Türen werden mit demselben Schlüssel geöffnet. Der Schlüssel wechselt alle 30 Minuten. Am Ende der 30 Minuten muss ich dem Schlüsselmacher den alten Schlüssel geben und einen neuen Schlüssel bekommen.
Wenn ich der Hacker bin und Ihren Schlüssel bekomme, werde ich ihn am Ende der 30 Minuten an den Schlüsselmacher weiterleiten und einen neuen Schlüssel bekommen. Ich kann alle Türen unabhängig vom Schlüsselwechsel kontinuierlich öffnen.
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 vor, Sie stellen eine Netzwerkanforderung und übergeben das Zugriffstoken, um sich zu identifizieren). Das ist also eine 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 demselben Schlüssel geöffnet. Der Schlüssel wechselt alle 30 Minuten. Um einen neuen Schlüssel zu erhalten, kann ich das alte Zugriffstoken nicht übergeben. Ich muss nur den Aktualisierungsschlüssel übergeben.
Wenn ich der Hacker bin und Ihren Schlüssel bekomme, kann ich ihn 30 Minuten lang verwenden, aber am Ende der 30 Minuten hat das Senden an den Schlüsselmacher keinen Wert. Wenn ich das tue, würde der Schlüsselmacher nur dieses schlechte Aktualisierungstoken sagen. Um meinen Hack verlängern zu können, müsste ich den Kurier zum Keymaker hacken. Der Kurier hat einen eindeutigen Schlüssel (stellen Sie sich dies als Aktualisierungstoken vor).
Frage: Wie viele Hacking-Möglichkeiten hatte ich in den 30 Minuten gegen den Aktualisierungsschlüssel? 80? Nein, ich hatte nur 1 Hacking-Gelegenheit. 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 nach 30 Minuten sind sie nicht mehr gut.
Ein Server würde ein Zugriffstoken basierend auf Anmeldeinformationen und dem Signieren (normalerweise) eines JWT überprüfen.
Ein undichtes Zugriffstoken ist schlecht, aber sobald es abläuft, ist es für einen Angreifer nicht mehr nützlich. Ein Leck des Aktualisierungs-Tokens ist weitaus schlimmer, aber vermutlich weniger wahrscheinlich. (Ich denke, es gibt Raum zu hinterfragen, ob die Wahrscheinlichkeit eines Lecks eines Aktualisierungstokens viel geringer ist als die eines Lecks eines Zugriffstokens, aber das ist die Idee.)
Der Punkt ist, dass das Zugriffstoken zu jeder von Ihnen gestellten Anforderung hinzugefügt wird, während ein Aktualisierungstoken nur während des Aktualisierungsflusses verwendet wird. Daher ist die Wahrscheinlichkeit geringer, dass ein MITM das Token sieht
Frequenz hilft einem Angreifer. Herzblut ähnliche potenzielle Sicherheitslücken in SSL, potenzielle Sicherheitslücken im Client und potenzielle Sicherheitslücken im Server ermöglichen Leckagen.
Wenn der Autorisierungsserver vom Anwendungsserver getrennt ist, der andere Clientanforderungen verarbeitet, werden auf diesem Anwendungsserver keine Aktualisierungstoken angezeigt. Es werden nur Zugriffstoken angezeigt, die nicht mehr lange leben.
Die Unterteilung ist gut für die Sicherheit.
Last but not least sehen Sie diese tolle Antwort
Um welches Aktualisierungstoken geht es NICHT?
Die Möglichkeit, die Zugriffsebene über Aktualisierungstoken zu aktualisieren / zu widerrufen, ist ein Nebenprodukt der Auswahl 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
Angenommen, Sie machen das access_tokenletzte sehr lange und haben es nicht refresh_token, also bekommen Hacker es an einem Tagaccess_token und er kann auf alle geschützten Ressourcen zugreifen!
Wenn dies jedoch der Fall ist refresh_token, ist die access_tokenLive-Zeit des Hackers kurz, sodass der Hacker schwer zu hacken ist, access_tokenda sie nach kurzer Zeit ungültig wird.
Access_tokenkann nur zurückgerufen werden, indem nicht nur, refresh_tokensondern auch von client_idund verwendet wird client_secret, was der Hacker nicht hat.
Während das Aktualisierungstoken vom Autorisierungsserver beibehalten wird. Zugriffstoken sind in sich geschlossen, sodass der Ressourcenserver sie überprüfen kann, ohne sie zu speichern. Dies erspart den Aufwand für den Abruf im Falle einer Validierung. Ein weiterer Punkt, der in der Diskussion fehlt, ist von rfc6749 # Seite-55
"Beispielsweise könnte der Autorisierungsserver eine Rotation des Aktualisierungstokens verwenden, bei der bei jeder Antwort auf die Aktualisierung des Zugriffstokens ein neues Aktualisierungstoken ausgegeben wird. Das vorherige Aktualisierungstoken wird ungültig, aber vom Autorisierungsserver beibehalten. Wenn ein Aktualisierungstoken kompromittiert und anschließend von verwendet wird Sowohl der Angreifer als auch der legitime Client, einer von ihnen, wird ein ungültiges Aktualisierungstoken vorlegen, das den Autorisierungsserver über den Verstoß informiert. "
Ich denke, der springende Punkt bei der Verwendung von Aktualisierungstoken ist, dass selbst wenn es dem Angreifer irgendwie gelingt, Aktualisierungstoken, Client-ID und geheime Kombination zu erhalten. Bei nachfolgenden Aufrufen, um ein neues Zugriffstoken vom Angreifer zu erhalten, kann nachverfolgt werden, falls jede Anforderung zur Aktualisierung zu einem neuen Zugriffstoken und einem Aktualisierungstoken führt.
A Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Betrachten wir 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 kann es jedoch zu Änderungen in der Benutzer- und Rollenkonfiguration kommen (z. B. kann ein neuer Zugriff gewährt oder der aktuelle Zugriff widerrufen werden), die sich im Cache widerspiegeln sollten.
Zu diesem Zweck können wir Zugriffs- und Aktualisierungstoken verwenden. Wenn eine API mit Zugriffstoken aufgerufen wird, überprüft der Ressourcenserver den Cache auf Zugriffsrechte. Wenn neue Zugriffsberechtigungen vorhanden sind, 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 mithilfe von Zugriffstoken auf das Ereignis der Generierung von Zugriffstoken mithilfe eines Aktualisierungstokens verschieben.
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 gewährt, auf dem der Ressourcenserver sie überprüft und die Anforderung gegebenenfalls bearbeitet. 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 Token-Fehlerantwort an den Client zurück.
Der Client authentifiziert sich beim Autorisierungsserver, indem er das Aktualisierungstoken gewährt.
Der Autorisierungsserver überprüft dann das Aktualisierungstoken durch Authentifizierung des Clients und stellt ein neues Zugriffstoken aus, sofern es gültig ist.
access token + refresh token?