Warum hat OAuth v2 sowohl Zugriffs- als auch Aktualisierungstoken?
Abschnitt 4.2 des Entwurfs der OAuth-2.0-Protokoll zeigt, dass ein authorization server zurückgeben kann sowohl eine access_token (die für die Authentifizierung verwendet wird, sich mit einer Ressource) ebenso wie eine refresh_tokendie verwendet wird, rein zum erstellen eines neuen access_token:
https://tools.ietf.org/html/rfc6749#section-4.2
Warum haben die beiden? Warum nicht nur machen Sie die access_token letzten so lange, wie die refresh_token und nicht eine refresh_token?
InformationsquelleAutor der Frage dave mankoff | 2010-08-15
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Die Idee des refresh-Token ist, dass, wenn ein access-token kompromittiert ist, denn es ist von kurzer Dauer, der Angreifer hat eine begrenzte Fenster, in dem zu missbrauchen.
Refresh-Token, wenn Sie gefährdet sind, sind nutzlos, weil der Angreifer benötigt die client-id und geheimen neben der refresh-token, um einen access token.
Gesagt haben, dassweil jeder Aufruf sowohl der authorization server und die Ressource server erfolgt über SSL - einschließlich der original-client-id und geheimen, wenn Sie darum bitten, die access/refresh-Token - ich bin nicht sicher, wie sich das access-token ist nicht mehr "compromisable" als das langlebige refresh-token und clientid/geheime Kombination.
Dies ist natürlich anders zu Implementierungen, in denen Sie keine Kontrolle über die Berechtigung und Ressource-Servern.
Hier ist ein guter thread reden über die Verwendung der refresh-Token: OAuth Archive.
Ein Zitat aus der oben genannten, sprechen über die Sicherheit Zwecke der refresh-token:
InformationsquelleAutor der Antwort catchdave
Den link zur Diskussion, zur Verfügung gestellt von Catchdave, hat ein gültig Punkt gemacht von Dick Hardt, die ich glaube, ist Wert hier erwähnt zu werden, zusätzlich zu, was oben geschrieben wurde:
In der Tat in der situation, in der Ressource Server-und Autorisierungs-Server ist die gleiche Einheit, und wo die Verbindung zwischen dem Benutzer und einer von Ihnen (in der Regel) gleichermaßen sicher, es gibt nicht viel Sinn zu halten refresh-token getrennt von der access-token.
Obwohl, wie im Zitat erwähnt, eine andere Rolle der refresh-Token zu sichern, ist das access-token kann jederzeit widerrufen werden, indem der Benutzer (über das web-interface in Ihre profile, zum Beispiel), während das system skalierbar zur gleichen Zeit.
Allgemein, Token können entweder zufällige IDS verweisen auf den betreffenden Datensatz in der Server-Datenbank, oder Sie können alle Informationen enthalten, die in sich (sicherlich, diese Informationen zu unterzeichnen, mit MACzum Beispiel).
Wie das system mit langlebigen access tokens funktionieren sollte
Den server kann der Client erhalten Sie Zugriff auf die Daten des Benutzers innerhalb eines festgelegten Bereiche durch die Ausgabe einer token. Wir wollen, dass das token widerruflich, müssen wir speichern in der Datenbank zu der token zusammen mit dem flag "gesperrt") gesetzt oder nicht gesetzt (andernfalls würde, wie Sie das tun, mit selbst-enthaltenen token?) Datenbank kann enthalten so viel wie
len(users) x len(registered clients) x len(scopes combination)records. Jeder API-Anfrage dann müssen schlagen die Datenbank. Obwohl es ziemlich trivial, um Abfragen an eine solche Datenbank durchführen O(1), der single point of failure selbst kann negative Auswirkungen auf die Skalierbarkeit und performance des Systems.Wie das system mit langlebigen refresh-token und kurzlebige access token funktionieren sollte
Hier geben wir zwei Schlüssel: random refresh-token mit dem entsprechenden Datensatz in der Datenbank, und unterzeichnet eigenständige access-token enthält unter anderem den Ablauf timestamp-Feld.
Als das Zugriffstoken ist ein in sich geschlossenes, haben wir nicht zu schlagen, die Datenbank überhaupt um Ihre Gültigkeit zu überprüfen. Alles, was wir tun müssen, ist zum entschlüsseln des Tokens und zum überprüfen der Signatur und dem Zeitstempel.
Trotzdem haben wir immer noch halten die Datenbank des refresh-Token, aber die Anzahl der Anfragen an diese Datenbank ist allgemein definiert durch die Lebensdauer der access-token (je länger die Lebensdauer, desto geringer ist die access rate).
In Auftrag zu widerrufen, der Zugriff der Client von einem bestimmten Benutzer, wir sollten, markieren Sie die entsprechende refresh-token als "widerrufen" (oder entfernen Sie Sie vollständig) und stoppen die Ausgabe von neuen access-Token. Es ist offensichtlich, obwohl, es gibt ein Fenster, bei denen die refresh-token widerrufen worden ist, aber seine access-token kann immer noch gültig sein.
Kompromisse
Refresh Token teilweise Beseitigung der SPoF (Single Point of Failure) des Access-Token-Datenbank, aber Sie haben einige offensichtliche Nachteile.
Dem "Fenster". Einer Zeitspanne zwischen den Ereignissen "Benutzer wird der Zugang" und "Zugang garantiert wird, zu widerrufen".
Die Komplikation der Client-Logik.
ohne refresh token
mit refresh token
Ich hoffe, diese Antwort macht Sinn und hilft jemandem, um mehr durchdachte Entscheidung. Ich möchte beachten Sie auch, dass einige bekannte OAuth2 Provider, darunter auch github und foursquare erlassen Protokoll ohne refresh Token, und scheinen glücklich damit.
InformationsquelleAutor der Antwort Roman Imankulov
Trotz all der tollen Antworten, die ich als Sicherheits-master-student und Programmierer, der früher bei eBay, wenn ich mir einen Blick in die Käufer-Schutz-und-Betrug, kann man sagen, separaten access-token und refresh token hat seine beste balance zwischen belästigend Benutzer häufige Benutzername/Passwort-Eingabe und halten Sie die Behörde in der hand zu annullieren, den Zugang zu potenziellen Missbrauch von Ihrem service.
Denken Sie an ein Szenario wie dieses. Geben Sie Benutzer ein access-token von 3600 Sekunden-und refresh-Tokens viel länger als einen Tag.
Den Benutzer ist ein gute Benutzer, er ist zu Hause und bekommt auf/aus Ihrer website Einkaufen und die Suche nach seinem iPhone. Seine IP-Adresse ändert sich nicht und haben eine sehr geringe Last auf dem server. Wie 3-5 Seiten Anfrage jede minute. Wenn seine 3600 Sekunden auf die access-token vorbei ist, verlangt er eine neue mit der refresh-token. Wir, auf der server-Seite, überprüfen Sie seine Aktivität, Geschichte und IP-Adresse, denke er ist ein Mensch und verhält sich selbst. Wir erteilen ihm eine neue access-token weiterhin mit unserem service. Der Benutzer nicht brauchen, um wieder geben Sie den Benutzernamen/Kennwort, bis er erreicht hat, einen Tag der Lebensdauer der refresh-token selbst.
Den Benutzer ist ein sorglos Benutzer. Er lebt in New York, USA und hat seine virus-Programm, Herunterfahren und gehackt wurde von einem hacker in Polen. Wenn der hacker bekam die access token und refresh token, versucht er, die Identität der Benutzer und nutzen Sie unseren service. Aber nach der kurzen live-Zugriffstoken abläuft, wenn die hacker versucht, aktualisieren der access-token, die wir, auf dem server, hat bemerkt, eine dramatische IP-änderung im Nutzerverhalten Geschichte (hey, dieser Kerl Anmeldungen in den USA und jetzt refresh-Zugriff in Polen nach nur 3600s ???). Wir beenden die Aktualisierung, erlischt die refresh-token selbst und die Aufforderung zur Eingabe von Benutzername/Passwort wieder.
Den Benutzer ist ein bösartige Benutzer. Er ist vorgesehen, um den Missbrauch unseres service durch den Aufruf 1000 mal unsere API jede minute mit einem Roboter. Er kann gut dabei, bis 3600 Sekunden später, als er versucht, aktualisieren der access-token, bemerkten wir, dass sein Verhalten und denke, dass er sich nicht wie ein Mensch. Wir verwerfen und beenden der Aktualisierung und bitten Sie ihn, geben Sie Benutzername/Kennwort erneut ein. Dies könnte potenziell brechen seine Roboter-automatische flow. Zumindest macht ihn unbequem.
Sehen Sie die refresh-token gehandelt hat, perfekt, wenn wir versuchen, das Gleichgewicht unserer Arbeit die Erfahrungen der Nutzer und die potenzielle Gefahr eines gestohlenen token. Ihre watch dog auf der server-Seite überprüfen kann, mehr als die IP zu ändern, die Frequenz der api-Aufrufe, um zu bestimmen, ob der Nutzer eine gute user sind, oder nicht.
Einem anderen Wort kann man auch versuchen, den Schaden zu begrenzen, Kontrolle der gestohlenen token/Missbrauch des service durch die Implementierung auf jedem api-Aufruf die grundlegende IP-watch-dog-oder andere Maßnahmen. Aber das ist teuer, wie haben zu Lesen und zu schreiben, die Aufzeichnung über die user und wird sich verlangsamen Ihre server-Antwort.
InformationsquelleAutor der Antwort laalaguer
Keine dieser Antworten erhalten, um den Kern Grund-refresh-Token vorhanden ist. Natürlich, Sie können immer einen neuen access-token - /refresh-token-pair-Mädchen, indem Sie Ihre client-Anmeldeinformationen an den auth-server - das ist, wie man Sie in den ersten Platz.
Also der einzige Zweck der refresh-token zu begrenzen, die Verwendung der Anmeldeinformationen des Clients wird über die Leitung gesendet, um die auth-service. Je kürzer die Gültigkeitsdauer der access-token, die mehr oft die client-Anmeldeinformationen werden verwendet, um eine neue access-token, und somit mehr Möglichkeiten die Angreifer haben den Kompromiss der client-Anmeldeinformationen (dies ist zwar super schwer, jedenfalls, wenn eine asymmetrische Verschlüsselung verwendet wird, um Sie zu senden). Also, wenn Sie einen single-use-refresh-token, können Sie die ttl des access-tokens beliebig kleine, ohne die client-Anmeldeinformationen.
InformationsquelleAutor der Antwort B T
Diese Antwort ist von Justin Reicher über die OAuth-2 standard-body-E-Mail-Liste. Dies ist gepostet, mit seiner Erlaubnis.
Die Lebensdauer eines refresh-token ist bis zum (ALS) authorization server — Sie können erlöschen, widerrufen werden, etc. Der Unterschied zwischen einem refresh token und ein access token ist das Publikum: die refresh-token nur geht zurück auf den authorization server, der access-token geht an den (RS) Ressourcen-server.
Auch, nur immer ein access-token bedeutet nicht, der Benutzer ist angemeldet. In der Tat, der Benutzer vielleicht gar nicht mehr da, die eigentlich die vorgesehene Verwendung bei der refresh-token. Aktualisieren der access-token erhalten Sie Zugriff auf eine API, die auf den Namen des Benutzers, wird es Ihnen nicht sagen, wenn die user da ist.
OpenID Connect nicht nur geben Sie die Benutzer-Informationen aus einer access-token, es gibt auch ein ID-token. Dies ist ein separates Stück von Daten, die direkt auf dem client selbst, nicht das WIE oder die RS. In OIDC, sollten Sie nur eine Person tatsächlich "angemeldet", die durch das Protokoll, wenn man eine frische ID-token. Erfrischend ist es wahrscheinlich nicht genug sein.
Für weitere Informationen Lesen Sie bitte http://oauth.net/articles/authentication/
InformationsquelleAutor der Antwort Manicode
Zu klären einige der Verwirrung, die Sie haben zu verstehen, welche Rollen der client secret und die Benutzer Passwortdie sehr unterschiedlich sind.
Den client ist eine app/website/Programm/...), unterstützt von einem server, das will authentifizieren eine Benutzer durch die Verwendung einer DRITTHERSTELLER-Authentifizierung service. Das client-Geheimnis ist eine (zufällige) der string bekannt ist, dass sowohl das client und dem authentication server. Mit diesem Geheimnis kann der client identifiziert sich mit dem Authentifizierungs-server, der den Empfang Genehmigung auf Anfrage access-Token.
Bekommen die ersten access-token und refresh token, was benötigt wird, ist:
Erhalten eine aktualisierte access-token jedoch die client nutzt die folgenden Informationen:
Dies zeigt deutlich den Unterschied: beim aktualisieren der client erhält die Berechtigung zum aktualisieren Zugriffstokens mithilfe Ihrer client-Geheimnis, und so können re-authentifizieren des Benutzers mit der refresh-token statt der Benutzer-ID + Passwort. Dies effektiv verhindert, dass den Benutzer zur erneuten Eingabe seines Passwortes.
Dies zeigt auch, dass verlieren ein refresh token ist kein problem, da die client-ID und secret sind nicht bekannt. Es zeigt auch, dass die client-ID und client secret Geheimnis ist vital.
InformationsquelleAutor der Antwort Adversus
Kunden beeinträchtigt werden können, in vielerlei Hinsicht. Zum Beispiel ein Handy geklont werden kann. Nachdem ein access-token abläuft, bedeutet, dass der client gezwungen ist, zu re-authentifiziert der authorization server. Während der re-Authentifizierung, die Autorisierung server überprüfen können andere Merkmale (IOW eine adaptive access management).
Refresh-Token ermöglichen für einen Kunden nur re-Authentifizierung, wo Sie als re-Autorisierung erzwingt einen dialog mit dem Benutzer, die viele haben angegeben, Sie würden lieber nicht tun.
Refresh Token Sitz in im wesentlichen der gleichen Stelle, wo normale Websites können wählen, um in regelmäßigen Abständen re-Authentifizierung der Benutzer nach einer Stunde oder so (z.B. banking-Website). Es ist nicht hoch derzeit, da die meisten social-web-sites nicht re-Authentifizierung web-Benutzer, also warum sollten Sie re-authentifizieren eines Clients?
InformationsquelleAutor der Antwort Phil
Zur weiteren Vereinfachung B T ' s Antwort: Verwenden Sie refresh-Token, wenn Sie in der Regel nicht möchten, dass der Benutzer geben Sie die Anmeldeinformationen erneut, wollen aber trotzdem die Kraft, um in der Lage sein, zum Widerruf der Berechtigungen (durch Widerruf der refresh-token)
Können Sie nicht widerrufen, ein Zugriffstoken, nur ein refresh token.
InformationsquelleAutor der Antwort bitcoder
Neben der großen Antworten, die andere Leute haben, vorausgesetzt, es ist ein weiterer Grund, warum benutzen würde, refresh-Token und dessen zu tun mit Ansprüchen.
Jeder token enthält Forderungen, die können alles beinhalten, von dem der Benutzer name, Ihre Rollen oder die Anbieter, die das behaupten. Als Zeichen, aktualisiert diese Ansprüche sind aktualisiert.
Wenn wir aktualisieren die Token öfter sind wir natürlich mehr Belastung auf unsere Identität, Dienstleistungen, aber wir werden immer mehr, genaue und up-to-date-Ansprüche.
InformationsquelleAutor der Antwort heymega
InformationsquelleAutor der Antwort
Betrachten wir ein system, in dem jeder Benutzer ist mit einer oder mehreren Rollen, und jede Rolle ist mit einem oder mehr Zugriffsrechte. Diese Informationen zwischengespeichert werden kann, für eine bessere API performance. Aber dann kann es zu änderungen in der Benutzer-und Rollen-Konfigurationen (für z.B. neue Zugang gewährt werden kann oder aktuelle Zugang widerrufen werden kann) und diese soll auch in den cache.
Können wir verwenden access-und refresh-tokens für diesen Zweck. Wenn eine API aufgerufen wird, mit access-token, den Ressourcen-server überprüft den cache für die Zugriffsrechte. WENN es einen neuen Zugang gewährt, es ist nicht sofort wiedergegeben. Sobald der access-token abläuft (sagen wir in 30 Minuten), und der client verwendet die refresh-token generieren Sie eine neue access-token kann der cache aktualisiert werden mit der aktualisierten Benutzer-Zugang direkt Daten aus der DB.
In anderen Worten, können wir die teuren Operationen von jedem API-Aufruf die Verwendung von access tokens, um das Ereignis der access-token-Generierung über die refresh-token.
InformationsquelleAutor der Antwort Saptarshi Basu
Während der refresh-token wird beibehalten, durch den Authorization server. Zugriffstoken sind eigenständig, so dass Ressourcen-server überprüfen können, ohne es zu speichern-das spart den Aufwand des Abrufens bei der Validierung.
Ein weiterer Punkt fehlt in der Diskussion ist von rfc6749#Seite-55
Ich denke, der springende Punkt bei der Verwendung der refresh-token ist, dass selbst wenn ein Angreifer es irgendwie schafft zu bekommen refresh-Tokens, client-ID und geheime Kombination. Mit anschließender aufruft, um neuen access-token vom Angreifer verfolgt werden können, im Falle dass, wenn jede Anfrage für die Aktualisierung Ergebnis in new access token und refresh token.
InformationsquelleAutor der Antwort Kraming