ID-Token vs. Access-Token: Der entscheidende Unterschied bei OpenID Connect

Von Mirko Peters · 2026-10-28

Erfahren Sie, worin sich ID-Token und Access-Token in OpenID Connect grundlegend unterscheiden, und warum eine Verwechslung gravierende Sicherheitslücken verursacht.

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

Das Verständnis des Unterschieds zwischen ID-Token und Access-Token ist für Entwickler und IT-Administratoren, die mit moderner Authentifizierung arbeiten, unverzichtbar. OAuth 2.0 regelt Berechtigungen, während OpenID Connect das ID-Token einführt, um die Identität des Benutzers zu bestätigen. Werden diese beiden Token verwechselt, entstehen kritische Sicherheitslücken in Cloud-Anwendungen.

Das Wichtigste in Kürze

• ID-Token bestätigen die Identität eines Benutzers, während Access-Token Autorisierungen und Berechtigungen gewähren.
• Die Verwechslung dieser beiden Token ist einer der häufigsten Fehler bei selbst entwickelter Anwendungssicherheit.
• OpenID Connect setzt die Identitätsbestätigung auf das OAuth-2.0-Framework auf.
• Access-Token können widerrufen werden, was eine sicherere Lösung darstellt als das Speichern von Passwörtern.
• Anwendungen müssen eingehende ID-Token kryptografisch prüfen, statt ihnen blind zu vertrauen.

Das Kerndilemma: Identität versus Autorisierung

In der Entwicklung moderner Webanwendungen kommt es häufig zu Verwirrung darüber, wie sich Benutzer anmelden und wie dieselben Benutzer mit den zugrunde liegenden Daten interagieren. Ein Großteil dieser Verwirrung rührt von sich überschneidender Terminologie im Identitätsbereich her. Als sich Anwendungen im Web schnell verbreiteten, stellte die alleinige Verwendung einfacher Kombinationen aus Benutzername und Passwort einen erheblichen Engpass für die Sicherheit dar. Benutzer waren es leid, Dutzende eindeutiger Zugangsdaten zu verwalten, was zu schwachen und mehrfach verwendeten Passwörtern über verschiedene Plattformen hinweg führte.

Um einen Teil dieses Problems zu lösen, kam OAuth 2.0 auf den Markt. OAuth 2.0 wurde jedoch nie dafür entwickelt, zu beantworten, wer eine Person ist. Sein eigentlicher Zweck besteht darin, Berechtigungsnachweise – sogenannte Access-Token – auszustellen, mit denen eine Anwendung im Auftrag eines Benutzers auf bestimmte Datenendpunkte zugreifen kann. Ein Access-Token legt fest, was eine Anwendung tun darf, schweigt jedoch vollständig über die Identität der Person, die es besitzt. Diese grundlegende Lücke führte dazu, dass Unternehmen, die Single-Sign-on-Erlebnisse entwickeln wollten, eigene Identitätsprüfungen an OAuth anflanschen mussten. Das Ergebnis waren fragmentierte Implementierungen, die selten miteinander übereinstimmten.

OpenID Connect schloss genau diese Lücke, indem es eine standardisierte Schicht speziell für die Authentifizierung einführte. Durch ein zweites Token neben dem klassischen Access-Token trennt OpenID Connect sauber die Frage der Identität von der Frage der Berechtigungen. Diese beiden Konzepte auseinanderzuhalten ist heute der wichtigste Denkansatz für alle, die Cloud-Anwendungen entwickeln oder prüfen.

Aufbau des ID-Tokens: Was darin enthalten ist

Wenn ein Benutzer auf die Schaltfläche „Mit Microsoft anmelden“ klickt, verarbeitet der Identitätsanbieter die Anmeldedaten, erfüllt gegebenenfalls die Anforderungen der Multi-Faktor-Authentifizierung und sendet den Benutzer schließlich mit einem ID-Token zurück zur Anwendung. Dieses Token ist als JSON Web Token verpackt, kurz JWT und ausgesprochen „dschott“. Auf den ersten Blick wirkt ein JWT wie eine undurchdringliche Zeichenfolge, die durch Punkte getrennt ist. Dennoch ist sein innerer Aufbau nach der Dekodierung bemerkenswert einfach.

Ein ID-Token enthält einige Standard-Claims, die jeweils einen klar definierten Zweck erfüllen:

• Issuer: Identifiziert den konkreten Identitätsanbieter (etwa Microsoft Entra ID), der das Token erzeugt und signiert hat.
• Subject (sub): Dient als eindeutiger, unveränderlicher Identifikator für den Benutzer. Entscheidend ist, dass sich dieser Wert nicht ändert, auch wenn der Benutzer seinen Anzeigenamen oder seine E-Mail-Adresse aktualisiert.
• Audience (aud): Legt fest, für welche Anwendung das Token genau ausgestellt wurde. So wird verhindert, dass ein für eine App bestimmtes Token abgefangen und von einer anderen App missbräuchlich verwendet wird.
• Zeitstempel: Geben an, wann das Token ausgestellt wurde, wann es abläuft und zu welchem genauen Zeitpunkt sich der Benutzer authentifiziert hat.
• Nonce: Fungiert wie eine sichere Belegnummer, die das ausgestellte Token der konkreten Anmeldesitzung zuordnet, aus der die Anfrage stammt. Dadurch werden Replay-Angriffe wirksam blockiert.

Entscheidend ist: Das gesamte Paket wird mit dem privaten Schlüssel des Anbieters signiert. Die empfangende Anwendung prüft diese Signatur mit dem passenden öffentlichen Schlüssel, den der Anbieter veröffentlicht. Ohne diese kryptografische Prüfung ist ein ID-Token nichts weiter als eine ungeprüfte Notiz, die zwischen Parteien weitergereicht wird.

Die Gefahr, Identität als Zugriff zu behandeln

Eines der gefährlichsten Anti-Pattern in der Anwendungsentwicklung ist, ein ID-Token als Berechtigungsschlüssel zu behandeln. Da ein ID-Token bestätigt, dass ein Benutzer John Doe aus einer bestimmten Organisation ist, verwechseln unerfahrene Entwickler diese Bestätigung manchmal mit administrativen Rechten oder uneingeschränktem Datenbankzugriff. Damit wird die Architektur grundlegend missverstanden.

Ein ID-Token sagt lediglich, wer vor der Tür steht. Es sagt nichts darüber aus, ob diese Person jeden Raum betreten oder eine bestimmte Verwaltungsfunktion ausführen darf. Die Autorisierungslogik muss die Anwendung separat umsetzen, etwa über rollenbasierte Zugriffssteuerung oder ähnliche Mechanismen. Die verifizierte Identität ist dabei nur der Ausgangspunkt und keine endgültige Autorisierungsentscheidung.

Außerdem machen Anwendungen häufig den Fehler, eingehende ID-Token ohne ordnungsgemäße Validierung anzunehmen. Einem Token blind zu vertrauen, nur weil eine Bibliothek es im Hintergrund verarbeitet hat, setzt Systeme gefälschten Daten aus. Die Signatur zu prüfen, die Ablaufzeitstempel zu kontrollieren und den Audience-Claim zu verifizieren sind unverzichtbare Schritte für eine sichere Architektur.

Fazit

Wer die Grenze zwischen Identität und Autorisierung versteht, entmystifiziert moderne Cloud-Architekturen. Wenn ID-Token ausschließlich dazu dienen, zu belegen, wer am Rechner sitzt, und Zugriffstoken festlegen, welche Aktionen erlaubt sind, können Entwickler robuste, sichere Integrationen mit Plattformen wie Microsoft Entra ID bauen. Um eine umfassende Erklärung dieser Konzepte zu hören und zu sehen, wie moderne Anmeldeabläufe im Microsoft-Ökosystem funktionieren, schauen Sie sich die vollständige Diskussion an. Hören Sie sich die vollständige Folge an und tauchen Sie noch heute tiefer in die Mechanik der Cloud-Identität ein!

Häufige Fragen

Kann ein ID-Token verwendet werden, um APIs aufzurufen oder auf geschützte Ressourcen zuzugreifen?

Nein. Ein ID-Token enthält nur Identitätsansprüche darüber, wer der Benutzer ist. Um APIs aufzurufen oder auf geschützte Ressourcen zuzugreifen, muss eine Anwendung ein über OAuth 2.0 ausgestelltes Zugriffstoken verwenden.

Warum verwenden OpenID Connect und OAuth 2.0 getrennte Token?

Die Trennung von Identität und Autorisierung ermöglicht es Anwendungen, zu prüfen, wer sich anmeldet, ohne dieser Anwendung uneingeschränkte Berechtigungen zu geben, die zugrunde liegenden Daten oder Ressourcen des Benutzers zu verändern.

Was passiert, wenn eine Anwendung ein ID-Token ohne Signaturprüfung akzeptiert?

Ohne Signaturprüfung ist die Anwendung anfällig für gefälschte Token, denn jeder könnte eine eigene Zeichenfolge erzeugen, die behauptet, ein gültiger Benutzer zu sein.

Welche Rolle spielt der Nonce-Wert beim Token-Austausch?

Der Nonce ist eine zufällige Zeichenfolge, die zu Beginn des Anmeldeablaufs erzeugt und in das ID-Token eingebettet wird. So kann die Anwendung Replay-Angriffe verhindern.