Refresh Token vs. Access Token: Der Unterschied und warum er in Microsoft Entra ID wichtig ist

Von Mirko Peters · 2026-04-28

Refresh Token vs. Access Token: Der Unterschied und warum er in Microsoft Entra ID wichtig ist

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Sie haben sich schon einmal gefragt, was einen Refresh Token eigentlich von einem Access Token unterscheidet? Dann sind Sie hier richtig. In der Welt von Microsoft Entra ID und modernen Cloud-Sicherheitskonzepten spielen diese beiden Token-Typen die Hauptrolle, jeder mit eigener Aufgabe, eigenen Besonderheiten und eigenen Sicherheitsregeln. Wer diese Unterschiede wirklich versteht, kann beim Entwurf sicherer Anmeldeabläufe für Microsoft 365, Azure oder jede andere Anwendung, die an Entra angebunden ist, viel Ärger vermeiden.

Das ist keine reine Theorie. Zu wissen, welches Token wann zu verwenden ist, wo es gespeichert werden sollte und wie es sicher geschützt wird, gehört zur Grundausstattung für jeden IT-Profi, Entwickler oder Administrator im Microsoft-Umfeld. Die Wahl beeinflusst nicht nur die Sicherheit Ihrer Anwendung, sondern auch die Nutzererfahrung im Alltag, insbesondere wenn es darum geht, dass Anwender angemeldet bleiben oder sich nach einem Sicherheitsvorfall wieder anmelden müssen.

In diesem Beitrag sehen Sie genau, wie Access Tokens und Refresh Tokens in Authentifizierungs- und Autorisierungskonzepte passen, warum ihre Lebensdauer eine Rolle spielt und was sie jeweils auszeichnet, besonders in Umgebungen mit Microsoft Entra ID. Am Ende wissen Sie, wie Sie starke Sicherheitsmaßnahmen mit einer reibungslosen Nutzererfahrung in Einklang bringen und die Token-Verwaltung in der Cloud sicher steuern.

Token in der modernen Authentifizierung verstehen

Moderne Authentifizierung dreht sich darum, zur richtigen Zeit die richtigen Berechtigungen zu vergeben, und digitale Token spielen dabei die zentrale Rolle. Wenn Sie eine Online-Anwendung oder einen Online-Dienst nutzen, verwenden Sie vermutlich bereits Token, auch wenn Ihnen das noch nicht bewusst ist. Sie fungieren als Vermittler, die es Anwendungen ermöglichen, sich gegenüber einem Cloud-Dienst für Sie zu legitimieren, ohne dass Sie jedes Mal Ihr Kennwort preisgeben müssen.

Token bilden das Herzstück des OAuth-2.0-Frameworks, auf dem Anmeldungen und sicherer Zugriff über Plattformen wie Microsoft Entra ID basieren. Anstatt Sitzungs-IDs oder anfällige Cookies zu verwalten, setzen Anwendungen heute auf diese digitalen „Ausweise“, um Benutzer zu identifizieren und Zugriff auf sensible Cloud-Ressourcen zu gewähren. Dieser Wandel hat die Sicherheit verschärft und gleichzeitig den Komfort erhöht, besonders für große Organisationen, die in die Cloud umziehen.

Die Stärke liegt darin, dass es verschiedene Token-Arten für unterschiedliche Aufgaben gibt. Manche sind für temporären Zugriff gedacht: schnell einsetzbar und schnell verworfen. Andere halten Sitzungen im Hintergrund aktiv, sodass Sie Ihren Arbeitstag ohne ständige neue Anmeldungen durchlaufen können. Diese Unterscheidung zwischen Access Tokens und Refresh Tokens ist entscheidend dafür, wie Microsoft-Cloud-Dienste, einschließlich Entra ID, Nutzererfahrung und Organisationssicherheit gleichermaßen im Blick behalten.

Dieser Abschnitt legt die Grundlagen, die Sie benötigen: was ein Token ist, welche Arten es gibt und warum deren Rollen in der heutigen Authentifizierung so wichtig sind. Steigen wir in die Details ein, beginnend mit der grundlegendsten Frage: Was genau ist ein Token?

Was ist ein Token?

Ein Token ist im Bereich der digitalen Sicherheit ein kompaktes Datenpaket, das als digitaler Berechtigungsnachweis dient. Stellen Sie sich einen digitalen Schlüsselanhänger vor: Eine Anwendung legt ihn vor, um Ihre Identität oder Berechtigungen gegenüber einem anderen System nachzuweisen. Token können zur Authentifizierung (Sind Sie die Person, die Sie vorgeben zu sein?) und zur Autorisierung (Dürfen Sie das, was Sie gerade tun?) in Cloud-Anwendungen und APIs eingesetzt werden.

Token folgen in der Regel modernen Standards wie OAuth 2.0 und liegen häufig als Bearer Tokens vor, etwa als JSON Web Tokens (JWT). Gegenüber klassischen Sitzungs-IDs werden sie bevorzugt, weil sie portabler sind, strukturierte Claims enthalten können und sicheren Zugriff auf Cloud-Ressourcen und verteilte Systeme unterstützen.

Was sind Access Tokens?

Access Tokens sind kurzlebige digitale Berechtigungsnachweise, die einer Anwendung nach erfolgreicher Authentifizierung ausgestellt werden. Ihr Hauptzweck: temporären, eng begrenzten Zugriff auf bestimmte Ressourcen gewähren, etwa auf APIs, Benutzerdaten oder Cloud-Speicher, ohne Kennwörter oder andere sensible Details offenzulegen.

Diese Token sind nur für eine begrenzte Zeit gültig, in Microsoft Entra ID in der Regel 30 bis 90 Minuten. Mit jeder API-Anfrage senden Anwendungen sie mit, um nachzuweisen, dass der Benutzer berechtigt ist. Gemäß den OAuth-2.0-Standards funktionieren Access Tokens über Microsoft 365, Azure und jeden Dienst, der an Entra ID angebunden ist, und bieten granulare, zeitlich begrenzte Berechtigungen.

Was sind Refresh Tokens?

Refresh Tokens sind langlebige Berechtigungsnachweise, die vertrauenswürdigen Anwendungen nach der ersten Anmeldung ausgestellt werden. Anders als Access Tokens besteht ihre Kernaufgabe darin, im Hintergrund neue Access Tokens zu besorgen, sobald das aktuelle abläuft, ohne dass sich der Benutzer erneut authentifizieren muss.

Ein Refresh-Token hilft also, lange Sitzungen aufrechtzuerhalten, und reduziert die Notwendigkeit, dass sich Benutzer immer wieder anmelden müssen. In Microsoft-Umgebungen sind Refresh-Token unverzichtbar für ein nahtloses Benutzererlebnis: Sie ermöglichen es Apps, Zugriffe im Hintergrund stillschweigend zu erneuern – über Sitzungen und Geräte hinweg und sogar nach Netzwerkproblemen –, während sensible Anmeldeinformationen geschützt bleiben.

Die wichtigsten Unterschiede zwischen Access-Token und Refresh-Token

Auf den ersten Blick wirken Access-Token und Refresh-Token vielleicht wie zufällige Zeichenketten. Ihre Aufgaben und ihre Lebensdauer unterscheiden sich jedoch grundlegend. Die beiden sind nicht austauschbar, sondern für sehr bestimmte Zwecke im Authentifizierungsablauf von Microsoft Entra ID konzipiert.

Access-Token sind Ihr „Passierschein“ für Aufrufe von APIs und den Abruf von Daten, allerdings nur für kurze Zeit. Sie sind bewusst kurzlebig, um das Sicherheitsrisiko zu minimieren, besonders falls sie jemals abhandenkommen. Refresh-Token hingegen bleiben länger gültig. Ihr Zweck ist es, das Benutzererlebnis aufrechtzuerhalten, indem sie im Hintergrund unbemerkt eine neue Autorisierung ermöglichen.

Diese Unterschiede zu verstehen, ist mehr als eine theoretische Übung. Wählen Sie die falsche Strategie oder speichern Sie das falsche Token am falschen Ort, frustrieren Sie Benutzer entweder mit zu vielen erneuten Anmeldungen oder lassen gravierende Lücken in Ihrer Sicherheitsarchitektur. Die folgenden Abschnitte erläutern, was jedes Token leistet, wie lange es gültig ist und was es in der Praxis sicher oder riskant macht – nicht nur in der Theorie.

Wenn Sie für Microsoft 365, Azure oder einen anderen mit Entra ID verbundenen Dienst entwickeln, sollten Sie die folgenden Unterschiede im Blick behalten. Sie bestimmen, wie Ihre App das Gleichgewicht zwischen hochsicherer Absicherung und einer reibungslosen, unterbrechungsfreien Sitzung für alle Benutzer findet.

Funktionale Rollen: Was sie tun

Access-Token sind Ihr Schlüssel zu APIs und Cloud-Ressourcen, doch ihre Reichweite ist begrenzt. Sobald das Access-Token abläuft, haben Sie ohne Refresh-Token keine Möglichkeit mehr weiterzuarbeiten. Das Refresh-Token ist der Backstage-Pass: Es gibt Ihrer App das Recht, unbemerkt ein neues Access-Token anzufordern, ohne den Benutzer erneut zu behelligen.

In der Cloud-Welt von Microsoft 365 und Azure sorgen Access-Token also für die Aktionen im Moment, während Refresh-Token dafür sorgen, dass diese Aktionen sitzungsübergreifend im Hintergrund weiterlaufen können. Dieses Zusammenspiel ermöglicht sichere Workflows und bewahrt Benutzer vor ständigen Anmeldeproblemen.

Wie lange Token gültig sind und warum das Ablaufdatum zählt

Access-Token haben aus gutem Grund eine kurze Lebensdauer – in Entra ID standardmäßig typischerweise 30 bis 90 Minuten. Sie gewähren genau so viel Zugriff, wie nötig ist, und laufen dann ab. So sinkt das Risiko, falls ein Token in fremde Hände gerät. Refresh-Token hingegen sind die Langstreckenläufer. Sie gelten oft Tage, Wochen oder sogar Monate, je nach den Anforderungen der App und den konfigurierten Sicherheitsrichtlinien.

Dieser Unterschied ist wichtig: Kurzlebige Token bedeuten weniger Angriffsfläche, erfordern aber häufigere Erneuerungen. Länger gültige Refresh-Token ermöglichen unterbrechungsfreie Sitzungen, erhöhen aber das Risiko, wenn sie in falsche Hände gelangen. Entscheidend ist, Sicherheit und Benutzerkomfort in Balance zu halten.

Sicherheitsmerkmale von Access- und Refresh-Token

• 1. Sicherheit von Access-Token: Access-Token sind für die sofortige, vorübergehende Nutzung gedacht. Da sie in der Regel weniger als eine Stunde gültig sind, ist das Zeitfenster für einen Missbrauch im Diebstahlfall klein. Da es sich jedoch um Bearer-Token handelt – wer das Token besitzt, kann es verwenden –, dürfen sie ausschließlich über HTTPS übertragen und nur im Arbeitsspeicher gehalten werden, nicht in dauerhaftem Speicher auf dem Client.
• 2. Sicherheit von Refresh-Token: Refresh-Token sind langlebig und sensibler. Wird ein Refresh-Token kompromittiert, kann ein Angreifer dauerhaft neue Access-Token abrufen, selbst nachdem sich der Benutzer abgemeldet hat. Deshalb ist eine sichere Speicherung entscheidend – vorzugsweise in einer sicheren Enklave (etwa einem hardwaregestützten Speicher auf mobilen Geräten oder HTTP-only-Secure-Cookies in Browsern).
• 3. Angriffsflächen: Access-Token können auf dem Übertragungsweg abgefangen werden, wenn HTTPS nicht erzwungen wird, oder in Speicherabbildern gefunden werden. Refresh-Token sind bei Speicherung im lokalen oder Sitzungsspeicher stark anfällig für Cross-Site-Scripting-Angriffe (XSS). Für zusätzlichen Schutz in Microsoft-Umgebungen sollten Sie Bedingten Zugriff-Richtlinien einsetzen und auf ungewöhnliche Token-Nutzung achten.
• 4. Widerruf und Risiko: Zugriffstoken lassen sich vor Ablauf in der Regel nicht widerrufen, da es sich häufig um zustandslose JWTs handelt. Aktualisierungstoken hingegen können vom Autorisierungsserver aktiv widerrufen oder ungültig gemacht werden, wenn eine Kompromittierung erkannt wird. Reale Risiken und Kontrollmechanismen für dauerhafte Token erläutert dieser Überblick über OAuth-Zustimmungsangriffe in Entra ID, bei denen Angreifer dauerhaften Zugriff über Aktualisierungstoken ausnutzen.
• 5. Schutzmaßnahmen in der Microsoft Cloud: Die Kombination aus kurzlebigen Zugriffstoken, strengen Zustimmungskontrollen, umfassender Protokollierung und der Durchsetzung der Administratorzustimmung kann das Risiko insgesamt senken. Die Security Governance, wie sie in dieser Podcast-Folge zur Security Governance in Entra ID beschrieben wird, sollte umgesetzt werden, um Identitätswildwuchs zu begrenzen und bessere Sicherheitsrichtlinien durchzusetzen.

Kurzlebige Zugriffstoken zur Risikoreduzierung

Die Entscheidung, Zugriffstoken kurzlebig zu gestalten, ist nicht bloß Vorsicht, sondern kluges Risikomanagement. Wird ein kurzlebiges Zugriffstoken gestohlen, ist das Angriffsfenster winzig. Nach einer Stunde oder weniger ist es wertlos. Damit werden die meisten Versuche seitlicher Bewegung und Token-Replay-Vorfälle unterbunden.

In verteilten Systemen wie Microsoft 365 und Azure sorgt dies außerdem dafür, dass Änderungen an Benutzerberechtigungen oder Abmeldeaktionen zügig durchgesetzt werden. Durch das schnelle Ablaufen wird jede unautorisierte Tokenverwendung auf ein enges Zeitfenster begrenzt. So ist eine schnelle Reaktion möglich, ohne für jedes im Umlauf befindliche Token zentrale Sperrlisten zu benötigen.

Dauerhafte Aktualisierungstoken für nahtlose Neuanmeldung

Dauerhafte Aktualisierungstoken sorgen vor allem für einen reibungslosen Ablauf für Benutzer. Anstatt Benutzer jede Stunde mit einem Anmeldebildschirm zu konfrontieren, ermöglicht ein Aktualisierungstoken Apps, abgelaufene Zugriffstoken gegen neue einzutauschen, oft unbemerkt und sofort. Das macht einen großen Unterschied für die Produktivität, besonders bei Microsoft-365-Apps, die den ganzen Tag im Einsatz sind, oder bei mobilen Clients mit schwankender Verbindung.

Der Haken: Länger gültige Aktualisierungstoken bergen bei einer Kompromittierung ein höheres Risiko. Deshalb setzen gut gebaute Apps auf Widerrufsmechanismen und Bedingte Zugriffsrichtlinien. Sie wägen den Nutzen einer nahtlosen Neuanmeldung gegen das Missbrauchspotenzial ab, falls ein Token abfließt.

Den Tokenlebenszyklus in Microsoft Entra ID verwalten

Tokens auszustellen ist nur die halbe Miete. Entscheidend für Sicherheit und Nutzererlebnis ist, wie Sie sie über die Zeit verwalten. In Microsoft Entra ID umfasst der Tokenlebenszyklus alles von der Erstellung eines Zugriffs- oder Aktualisierungstokens bis zu dessen Erneuerung, Rotation oder vollständigem Widerruf.

Dieser Prozess folgt den Best Practices von OAuth 2.0 sowie microsoftspezifischen Mechanismen zur Sitzungssteuerung. Sie müssen Echtzeitbedrohungen berücksichtigen, etwa Replay-Angriffe, zeitliche Probleme wie Taktabweichungen (Clock Skew) und die Details global verteilter Systeme. Dafür sollten Sie mit Tokenrotation, Validierungsschritten und Widerrufspfaden vertraut sein.

Mit dem Microsoft-Ansatz können Organisationen Richtlinienerzwingung, administrative Kontrollen und detaillierte Protokollierung nutzen, um Tokenwildwuchs in den Griff zu bekommen, zumal die Zahl cloudverbundener Geräte stark steigt. Praxisnahe Hinweise zur Skalierung von Identitätssicherheitsrichtlinien in großen Umgebungen finden Sie in dieser Podcast-Folge zu Bedingtem Zugriff in Entra ID und Risikoreduzierung.

Im Folgenden geht es darum, wie Sie Tokens rotieren und erneuern, wie Entra ID Tokens ausstellt und prüft und worauf Sie bei Timing und Implementierungsdetails achten müssen. Wenn Sie diese Schritte richtig umsetzen, danken es Ihnen Ihre Apps und Ihre Benutzer.

Best Practices für Tokenrotation und Erneuerung

• 1. Tokens häufig rotieren: Ersetzen Sie Zugriffstoken bei Ablauf immer durch neue, statt ihre Gültigkeit verlängern zu wollen. Bei Aktualisierungstoken sollten Sie bei jeder Verwendung rotieren: Wird damit ein neues Zugriffstoken angefordert, ersetzen Sie gleichzeitig das Aktualisierungstoken durch ein neues. Das erschwert Angreifern die Nutzung eines zuvor gestohlenen Tokens.
• 2. Bereits verwendete Tokens ungültig machen: Widerrufen Sie ein Aktualisierungstoken („Blacklisting“) standardmäßig, sobald es durch ein neues ersetzt wurde. So bleibt nur das zuletzt ausgestellte Aktualisierungstoken gültig, und das Zeitfenster für Replay-Angriffe wird verkleinert.
• 3. Token nicht an unsichere Clients weitergeben: Senden Sie Refresh-Token niemals an clientseitige öffentliche Clients wie Single-Page-Apps, es sei denn, es ist unbedingt erforderlich. Nutzen Sie in diesem Fall zusätzliche Schutzmaßnahmen wie Proof Key for Code Exchange (PKCE).
• 4. Verdächtige Nutzung überwachen: Nutzen Sie die integrierte Überwachung und die Administrator-Benachrichtigungen von Microsoft Entra ID für ungewöhnliche Token-Nutzung, z. B. Refresh-Token, die von unterschiedlichen Standorten oder Geräten aus wiederverwendet werden. Automatisieren Sie bedingte Zugriffsreaktionen, um kompromittierte Sitzungen zu beenden und die Auswirkungen eines Vorfalls zu begrenzen.
• 5. Compliance für wichtige Apps: Microsoft 365, Azure AD und Entra ID-fähige Anwendungen bieten integrierte Unterstützung für Token-Rotationsmuster. Übernehmen Sie deren Standardrichtlinien als Mindeststandard, z. B. Einmal-Refresh-Token für Exchange Online, und verschärfen Sie diese bei Bedarf für sensible Workloads.

Wie Token in Entra ID ausgestellt und validiert werden

• 1. Token-Ausstellung (Autorisierungsserver): Nach einer erfolgreichen Authentifizierung stellt Microsoft Entra ID (der Autorisierungsserver) ein Zugriffstoken und, sofern angefordert, ein Refresh-Token aus. Dabei handelt es sich in der Regel um JWTs, die mit robusten Signaturalgorithmen (etwa RS256) und von Microsoft verwalteten privaten Schlüsseln digital signiert sind.
• 2. Token-Claims und Inhalte: Das Zugriffstoken enthält Claims, also Angaben zum Benutzer, zu seinen Berechtigungen (Scopes) und zur Gültigkeitsdauer. Refresh-Token sind opak und enthalten die Informationen, die Entra ID benötigt, um Sitzungen sicher zu erneuern.
• 3. Validierung auf Ressourcenservern: Wenn Ihre App oder Ihre API ein Zugriffstoken erhält, prüft sie die digitale Signatur mithilfe des veröffentlichten öffentlichen Signaturschlüssels aus dem JWKS-Endpunkt von Entra ID. Die Validierung stellt sicher, dass das Token echt und unverändert ist und noch gültig ist (nicht abgelaufen oder widerrufen).
• 4. Sicherheitsprüfungen: Entra ID unterstützt Zielgruppenprüfungen (Audience Checks), die Durchsetzung von Scopes und die Signaturvalidierung auf jedem Ressourcenserver bzw. jeder API. Bei kritischen Anwendungen sollten Sie diese Claims stets prüfen und die Signatur verifizieren, bevor Sie den Zugriff gewähren.
• 5. Widerruf und Sperrung: Refresh-Token können im Gegensatz zu zustandslosen Zugriffstoken von Entra ID widerrufen werden. So lässt sich schnell auf einen vermuteten Missbrauch reagieren. Administratoren können Abmeldungen erzwingen oder die Gültigkeitsdauer von Token über Richtlinienänderungen einschränken.

Kulanzzeiten und Implementierungsdetails

Kulanzzeiten (Grace Periods) gleichen die praktischen Zeitabweichungen bei tokenbasierter Authentifizierung aus. Da Server und Clients häufig mit leicht unterschiedlichen Uhren arbeiten, was als Clock Skew bezeichnet wird, räumt Microsoft Entra ID bei der Prüfung des Ablaufs von Token eine kleine Toleranz ein (in der Regel etwa 5 Minuten). So schlagen Anmeldungen nicht wegen Abweichungen im Bereich von Sekundenbruchteilen bei der Systemzeit fehl.

Für optimale Ergebnisse sollten Sie die Uhren aller Server mit NTP synchron halten. Beachten Sie außerdem, dass Hochverfügbarkeits- oder regionenübergreifende Bereitstellungen die Gültigkeitsfenster von Token geringfügig verlängern können. Orientieren Sie sich bei Kulanzzeiten an den Empfehlungen in der Entra ID-Dokumentation und testen Sie das Verhalten stets anhand realer Datenverkehrsabläufe, insbesondere bei Benutzern, die zwischen Regionen oder Zeitzonen wechseln.

Sichere Speicherung und Handhabung von Token in Client-Anwendungen

Selbst das stärkste Token ist nur so sicher wie der Ort, an dem Sie es ablegen. Deshalb sind sichere Speicherung und Handhabung das praktischste Anliegen für jede App, die die Authentifizierung über Microsoft Entra ID nutzt. Wo Sie ein Zugriffs- oder Refresh-Token speichern, hängt vom Client ab: Browser, mobile Anwendung oder Desktop. Jede Umgebung hat ihre Stärken, blinden Flecken und typischen Fallstricke.

Wenn Sie glauben, dass die Speicherung von Token im localStorage des Browsers harmlos ist, sollten Sie umdenken: Ein einziger XSS-Angriff reicht, und das Token ist weg. Mobile Apps wirken sicherer, doch Rooting oder Jailbreaking kann auch scheinbar „sichere“ Token offenlegen. Und in Single-Page-Apps (SPAs) steht Ihnen gar keine sichere Speicheroption zur Verfügung, die für bösartige Skripte unerreichbar ist.

Dieser Abschnitt zeigt Ihnen, wie Sie für verschiedene App-Typen die richtige Entscheidung über die Speicheroptionen treffen. Sie erhalten einen Überblick über praktische Möglichkeiten wie HTTP-only-Secure-Cookies, Sitzungsspeicher im Browser und plattformspezifische sichere Speicher sowie die unverzichtbaren Schritte, um persistente Token zuverlässig zu schützen. Außerdem erfahren Sie, warum öffentliche Clients besondere Aufmerksamkeit benötigen, da sich Client-Geheimnisse dort nicht verbergen lassen. So erhalten Sie einen risikobewussten Speicher- und Rotationsplan für jedes Szenario.

Die Sicherheit Ihrer Anwendung hängt von diesen Entscheidungen ab, deshalb sollten Sie sie nicht dem Zufall überlassen. Lernen Sie die sicheren und unsicheren Muster kennen, die darüber entscheiden, ob Ihre App einem Diebstahl von Token standhält oder beim ersten Anzeichen versagt.

Sichere Speicherung von Refresh-Token über verschiedene Client-Typen hinweg

• 1. Webanwendungen (Browser): Der sicherste Ort zum Speichern von Refresh-Tokens im Browser sind HTTP-only-Cookies mit dem Attribut Secure. Anders als localStorage oder sessionStorage können JavaScript-Code diese Cookies nicht auslesen. Dadurch sind sie gegen XSS-Angriffe geschützt. Speichern Sie Tokens niemals im localStorage. Dieser ist anfällig für skriptbasierte Angriffe und sollte keine sensiblen Daten enthalten.
• 2. Single-Page-Anwendungen (SPAs): SPAs verfügen über keinen sicheren dauerhaften Speicher. Das Beste, was Sie tun können, ist, Tokens für die Dauer der Sitzung im Arbeitsspeicher des Browsers (in JavaScript-Variablen) zu halten. Wird die Seite neu geladen, sind die Tokens verschwunden, was das Risiko minimiert. Speichern Sie Refresh-Tokens niemals in einem Speicher oder in Cookies, die Sie nicht kontrollieren. Setzen Sie stattdessen so weit wie möglich auf kurzlebige Access-Tokens und stille Erneuerungen.
• 3. Mobile Apps: Speichern Sie Refresh-Tokens im sicheren Schlüsselbund des Geräts (iOS Keychain bzw. Android Keystore). Diese plattformgesicherten Speicher sind so konzipiert, dass andere Apps und Systemprozesse keinen Zugriff erhalten. Selbst wenn das Telefon kompromittiert oder gerootet ist, lassen sich die Daten nur schwer extrahieren.
• 4. Desktop-Anwendungen: Verwenden Sie die Anmeldeinformationsverwaltung auf Betriebssystemebene (etwa den Windows Credential Locker), um dauerhafte Tokens zu speichern. Schreiben Sie diese niemals in Klartextdateien oder in Benutzerverzeichnisse, auf die Schadsoftware zugreifen könnte.
• 5. Unternehmensgrenze: Wenden Sie in allen Fällen zusätzliche Kontrollen an, etwa Geräteverschlüsselung, Bildschirmsperren für Benutzer und die Möglichkeit zum Remote-Löschen. Verlangen Sie bei besonders sensiblen Workloads eine erneute Authentifizierung (Step-up-Authentifizierung), bevor ein auf dem Gerät gespeichertes Refresh-Token angezeigt oder verwendet wird.

Besondere Überlegungen zur Token-Rotation bei Public Clients

• 1. Public Clients können keine Geheimnisse speichern: Public Clients, also SPAs und einige mobile Apps, können Refresh-Tokens oder Client Secrets nicht sicher verbergen. Gehen Sie davon aus, dass alles, was dort gespeichert wird, potenziell offengelegt ist.
• 2. Ausschließlich kurzlebige Access-Tokens verwenden: Reduzieren Sie Refresh-Tokens nach Möglichkeit oder verzichten Sie ganz darauf. Setzen Sie auf kurzlebige Access-Tokens und fordern Sie stattdessen eine interaktive erneute Anmeldung an, anstatt die Tokens langfristig zu speichern.
• 3. Tokens bei jeder Verwendung rotieren: Wenn Sie Refresh-Tokens verwenden müssen, implementieren Sie Muster zur Rotation mit einmaliger Verwendung. Stellen Sie bei jeder Gewährung ein neues Refresh-Token aus und widerrufen Sie das vorherige.
• 4. Für mehr Sicherheit mit PKCE kombinieren: Verlangen Sie in OAuth-Ababläufen Proof Key for Code Exchange (PKCE). Damit werden die meisten Abfangangriffe auch in exponierten Umgebungen blockiert.

Best Practices für die Verwaltung von Access- und Refresh-Tokens

Die Regeln der Token-Sicherheit zu kennen ist das eine. Sie im Alltag umzusetzen, ist etwas ganz anderes. Wenn Sie mit sensiblen Microsoft-365-Daten, Workloads in Azure oder Szenarien mit Entra ID arbeiten, steigt der Einsatz: Sie müssen lückenlosen Schutz mit einer Benutzererfahrung verbinden, bei der sich Anwender nicht über zu viele Anmeldungen ärgern.

Dieser Abschnitt fasst die Pflichtaufgaben und die No-Gos für die Verwaltung von Refresh- und Access-Tokens im großen Maßstab zusammen. Seien wir ehrlich: Die Microsoft-Cloud hat ihre Eigenheiten, von komplexen bedingten Zugriffsrichtlinien bis hin zur engen Integration mit Microsoft Defender und Microsoft Purview für Überwachung und Governance. Die Best Practices betreffen jede Phase: die Ausstellung von Tokens, die sichere Speicherung, die Rotation, die Nutzung und, wenn es darauf ankommt, das schnelle Unterbinden des Zugriffs, sollte etwas schiefgehen.

Halten Sie Ausschau nach umsetzbaren Erkenntnissen, die Sie sofort anwenden können, damit Ihre Apps das doppelte Versprechen „schneller und sicherer“ einlösen. Möchten Sie mehr darüber erfahren, wie Sie Ihre Microsoft-365-Sicherheitslage stärken, ohne die Produktivität der Anwender zu beeinträchtigen? Lesen Sie diesen umfassenderen Leitfaden zu der Absicherung von M365 bei gleichzeitig zufriedenen Anwendern. Er behandelt Defender, Purview und bedingten Zugriff in Entra-ID-Umgebungen.

Im Folgenden finden Sie eine Zusammenfassung der Kernregeln für die Auswahl, den Umgang mit und die Absicherung von Access- und Refresh-Tokens in jeder Microsoft-basierten Implementierung.

Das Wichtigste in Kürze zur Auswahl und Handhabung von Tokens

• Verwenden Sie Access-Tokens nur für den sofortigen, kurzfristigen Ressourcenzugriff. Setzen Sie Refresh-Tokens nur dort ein, wo nahtlose, dauerhafte Sitzungen unverzichtbar sind und die Sicherheitskontrollen greifen.
• Speichern Sie Tokens sicher, und zwar in plattformseitig abgesicherten Speichern wie HTTP-only-Cookies für Web, Schlüsselbund für mobile Geräte und Credential Locker für Desktop-Anwendungen. Speichern Sie sensible Tokens niemals im Klartext oder im localStorage des Browsers.
• Token-Rotation und Widerruf implementieren: Stellen Sie sicher, dass Refresh-Tokens bei jedem Erneuerungsvorgang ersetzt und die alten ungültig gemacht werden. So begrenzen Sie die Zeitfenster für Angriffe.
• Sitzungsdauer und Benutzerfreundlichkeit in Einklang bringen: Legen Sie Access-Tokens nicht so kurz fest, dass Benutzer ständig zur Anmeldung aufgefordert werden. Wählen Sie aber auch keine so lange Laufzeit, dass bei einem Token-Leck unnötiges Risiko entsteht.
• Token-Nutzung überwachen, steuern und prüfen: Binden Sie Werkzeuge wie Microsoft Defender und Purview ein, und erzwingen Sie bei riskanten Anmeldeszenarien Bedingter Zugriff. Widerrufen Sie den Zugriff umgehend, wenn eine Kompromittierung vermutet oder erkannt wird.

Fazit und kurzer Wissenscheck

Den Unterschied zwischen Access-Tokens und Refresh-Tokens zu verstehen, ist im OAuth-2-Prozess mehr als ein Pflichtpunkt. Es ist der Schlüssel zu sicheren und reibungslosen Erfahrungen auf der Identitätsplattform von Microsoft, etwa mit Entra ID. Die richtige Balance zu finden zwischen kurzen Token-Laufzeiten für mehr Sicherheit und längeren Erneuerungszyklen für mehr Komfort, ist eine echte Kunst. Das gilt besonders, wenn Sie Benutzersitzungen über mehrere Geräte oder Dienste hinweg verwalten.

Bereit für einen kurzen Wissenscheck? Fragen Sie sich: Wie würden Sie mit abgelaufenen Tokens in einer App umgehen, die nur eine instabile Internetverbindung hat? Sollten Refresh-Tokens jemals Ihre Backend-Microservices erreichen? Wenn Ihnen dieser Überblick geholfen oder etwas Neues vermittelt hat, teilen Sie gern Ihre Gedanken. Die besten Kommentare öffnen Türen und stärken die ganze Community. Hat Ihnen gefallen, was Sie gesehen haben? Bleiben Sie dran und schärfen Sie weiter Ihre Sicherheitskompetenz!