Verständnis von Refresh-Token

Moderne sichere Anwendungen verwenden häufig Zugangstoken, um sicherzustellen, dass ein Benutzer Zugriff auf die entsprechenden Ressourcen hat. Diese Zugangstoken haben normalerweise eine begrenzte Lebensdauer. Dies geschieht aus verschiedenen Sicherheitsgründen: Zum einen wird durch die Begrenzung der Lebensdauer des Zugangstoken die Zeitspanne begrenzt, in der ein Angreifer ein gestohlenes Token verwenden kann. Außerdem könnten die Informationen, die im Zugriffstoken enthalten sind oder auf die er verweist, veraltet sein.

Wenn Zugriffstoken ablaufen oder ungültig werden, die Anwendung aber weiterhin auf eine geschützte Ressource zugreifen muss, steht die Anwendung vor der Problematik, ein neues Zugriffstoken zu erhalten, ohne den Benutzer zu zwingen, die Erlaubnis erneut zu erteilen. Um dieses Problem zu lösen, wurde mit OAuth 2.0 ein Artefakt namens Refresh-Token eingeführt. Ein Refresh-Token ermöglicht es einer Anwendung, ein neues Zugriffstoken zu erhalten, ohne den Benutzer dazu aufzufordern.

Ein Refresh-Token kann von einer Anwendung als Teil des Prozesses zur Erlangung eines Zugriffstoken angefordert werden. Viele Autorisierungsserver implementieren den Anforderungsmechanismus für Refresh-Token, der in der OpenID Connect Spezifikation definiert ist. In diesem Fall muss eine Anwendung den Bereich offline_access einschließen, wenn sie eine Anfrage für einen Autorisierungscode initiiert. Nachdem sich der Benutzer erfolgreich authentifiziert und der Anwendung die Erlaubnis erteilt hat, auf die geschützte Ressource zuzugreifen, erhält die Anwendung einen Autorisierungscode, der am Token-Endpunkt sowohl gegen ein Zugriffs- als auch gegen ein Refresh-Token ausgetauscht werden kann.

Wenn ein neues Zugriffstoken benötigt wird, kann die Anwendung eine POST-Anfrage an den Token-Endpunkt stellen und dabei den Berechtigungstyp refresh_token verwenden (Webanwendungen müssen ein Client-Geheimnis enthalten). Um ein Refresh-Token zu verwenden, um ein neues ID-Token zu erhalten, muss der Autorisierungsserver OpenID Connect unterstützen und der Umfang der ursprünglichen Anfrage muss openid enthalten.

Auch wenn Refresh-Token oft sehr langlebig sind, kann der Autorisierungsserver sie ungültig machen. Einige der Gründe, warum ein Refresh-Token nicht mehr gültig sein kann, sind folgende:

• der Autorisierungsserver hat das Refresh-Token widerrufen
• der Benutzer hat seine Zustimmung zur Autorisierung widerrufen
• das Refresh-Token ist abgelaufen
• die Authentifizierungsrichtlinie für die Ressource hat sich geändert (z. B. hat die Ressource ursprünglich nur Benutzernamen und Passwörter verwendet, aber jetzt erfordert sie MFA)

Da Refresh-Token eine lange Lebensdauer haben können, sollten Entwickler sicherstellen, dass strenge Aufbewahrungsvorschriften gelten, damit sie nicht nach außen dringen können. Bei Webanwendungen sollten Refresh-Token beispielsweise nur dann das Backend verlassen, wenn sie an den Autorisierungsserver gesendet werden, und das Backend sollte sicher sein. Das Client-Geheimnis sollte auf ähnliche Weise geschützt werden. Mobile Anwendungen benötigen kein Client-Geheimnis, sollten aber dennoch sicherstellen, dass die Refresh-Token an einem Ort gespeichert werden, auf den nur die Client-Anwendung zugreifen kann.

Mit Auth0 können Sie ein Refresh-Token erhalten, wenn Sie den Code-Prozess zur Autorisierung (für reguläre Web- oder native/mobile Anwendungen), den Gerätefluss oder die Passworterteilung für Ressourcenbesitzer verwenden. Alle wichtigen SDKs von Auth0 unterstützen den Erwerb, die Verwendung und den Widerruf von Refresh-Token sofort, ohne dass Sie sich um die Formatierung von Nachrichten kümmern müssen. Zu den Sprachen mit SDK-Unterstützung gehören Node.js, .NET, PHP, und viele mehr!

Um mehr über Refresh-Token bei Auth0 zu erfahren, einschließlich wie man diese widerruft, lesen Sie die Dokumentation zu Refresh-Token.