M365

Zugriffstoken (Access Token)

Overview

Ein Zugriffstoken ist das Ergebnis einer erfolgreichen Anmeldung nach OAuth 2.0. Microsoft Entra ID stellt es einer Anwendung aus, damit diese eine bestimmte API, etwa Microsoft Graph oder eine eigene Web-API, aufrufen kann. Das Token enthält Ansprüche (Claims) wie Aussteller, Zielgruppe (aud), Benutzer oder Anwendung, Berechtigungen (scp bzw. roles) und Ablaufzeit.

Für registrierte APIs sind Zugriffstoken in der Regel JSON Web Tokens (JWT) in Version 1.0 oder 2.0. Clients sollen sie laut Microsoft als undurchsichtige Zeichenkette behandeln und nicht selbst auswerten, nur die empfangende API prüft Signatur und Ansprüche. Token für Microsoft-eigene APIs müssen nicht einmal dekodierbar sein.

Abgrenzung: Das ID-Token beschreibt den angemeldeten Benutzer für die Anwendung selbst, das Aktualisierungstoken (Refresh Token) dient zum Abholen neuer Zugriffstoken, das Primary Refresh Token (PRT) ist an ein registriertes Gerät gebunden. Token im Sinne von Sprachmodellen haben einen eigenen Eintrag.

How it works

Der Ablauf nach OAuth 2.0 und OpenID Connect:

  1. Die Anwendung fordert ein Token für eine Ressource mit bestimmten Bereichen (Scopes) an, entweder für einen Benutzer (z. B. Autorisierungscode-Flow) oder für sich selbst (Client-Credentials-Flow mit Zertifikat).
  2. Entra ID prüft Identität, Zustimmung und Conditional Access und stellt das Token aus.
  3. Die Standardlebensdauer liegt zufällig zwischen 60 und 90 Minuten (im Schnitt 75 Minuten). In Sitzungen mit Continuous Access Evaluation (CAE) sind langlebige Token bis 28 Stunden möglich, weil kritische Ereignisse wie Kontosperrung oder Kennwortänderung die Sitzung nahezu in Echtzeit beenden.
  4. Läuft das Token ab, holt der Client mit dem Aktualisierungstoken still ein neues.
  5. Token Protection (Conditional-Access-Sitzungssteuerung) akzeptiert nur gerätegebundene Anmeldetoken und erschwert so das Wiederverwenden gestohlener Token auf anderen Geräten.

Benefits

  • Anwendungen erhalten Zugriff, ohne Kennwörter zu kennen oder zu speichern
  • Begrenzte Lebensdauer und eng gefasste Scopes reduzieren den Schaden bei Verlust eines Tokens
  • Standardisiertes Verfahren, das alle gängigen Bibliotheken wie MSAL unterstützen
  • CAE beendet Zugriffe nach Kontosperrung oder Standortwechsel deutlich schneller als der reine Ablauf

Practical example

Ein Energieversorger mit 600 Mitarbeitenden ersetzt ein Reporting-Skript, das sich bisher mit einem Benutzerkonto und Kennwort an Microsoft Graph anmeldete. Das neue Skript nutzt eine App-Registrierung mit Zertifikat im Client-Credentials-Flow und erhält ein Zugriffstoken mit der Anwendungsberechtigung User.Read.All. Damit entfällt das Dienstkonto, das seit der MFA-Pflicht für Admin-Portale ohnehin Probleme verursacht hätte.

Things to keep in mind

  • Token wie Kennwörter behandeln: nicht in Protokolle, Tickets oder Chats kopieren und nur über TLS übertragen
  • Gegen Token-Diebstahl per Adversary-in-the-Middle phishingresistente MFA (Passkeys, Windows Hello for Business) und Token Protection einsetzen
  • Scopes und Anwendungsberechtigungen minimal halten, ein Token kann nie mehr als seine Berechtigungen
  • Den ROPC-Flow (Benutzername und Kennwort direkt an den Token-Endpunkt) nicht mehr verwenden, er ist mit MFA nicht kompatibel
  • Fehler mit der Zielgruppe (aud) prüfen, wenn eine API Token ablehnt, und Token nur zu Testzwecken dekodieren

Conclusion

Zugriffstoken sind der Schlüssel des modernen API-Zugriffs. Halte Berechtigungen schlank, nutze Zertifikate statt Kennwörter und schütze Token mit phishingresistenter MFA und Token Protection.

Further reading

Related articles