Was ist ein Zugriffstoken (Access token)?
Ein Zugriffstoken (Access token) ist ein Berechtigungsnachweis, typischerweise eine Zeichenkette, die verwendet wird, um auf geschützte Ressourcen zuzugreifen. Im Kontext von OAuth 2.0 und OpenID Connect (OIDC) können Autorisierungsserver Zugriffstoken (Access tokens) an Clients (Anwendungen) nach erfolgreicher Authentifizierung und Autorisierung ausgeben.
Obwohl die RFCs für OAuth 2.0 und OIDC keine Implementierungsdetails für Zugriffstoken spezifizieren, gibt es zwei gängige Typen von Zugriffstoken, die in der Praxis verwendet werden:
- Opaques Token : Eine zufällige Zeichenkette, die für den Client keine Bedeutung (“opaqu”) hat. Der Client präsentiert das Token dem Ressourcensserver, der das Token mit dem Authorisierungsserver validiert.
- JSON Web Token (JWT) : Ein selbstausgesprochenes Token, das Claims (z. B. Benutzer-ID, Ablaufzeit) mit einer digitalen Signatur enthält. Der Ressourcensserver kann das Token validieren, ohne eine zusätzliche Anfrage an den Authorisierungsserver zu stellen.
Wie funktioniert ein Zugriffstoken (Access token)?
Je nach Typ des Zugriffstokens kann der Ablauf bei der Nutzung eines Zugriffstokens variieren.
Hier ist ein vereinfachtes Beispiel für die Verwendung eines opaken Zugriffstokens:
Hier ist ein vereinfachtes Beispiel für die Verwendung eines JWT:
Der Unterschied zwischen den beiden Arten von Zugriffstoken besteht darin, wie der Ressourcensserver das Token validiert:
- Der Ressourcensserver muss eine zusätzliche Anfrage an den Authorisierungsserver stellen, um ein opaques Token zu validieren, jedes Mal, wenn es ein Token erhält.
- Der Ressourcensserver kann ein JWT validieren, ohne eine zusätzliche Anfrage an den Authorisierungsserver zu stellen, da das Token alle notwendigen Informationen enthält und der Ressourcensserver den öffentlichen Schlüssel aus dem JSON Web Key Set (JWKS) des Authorisierungsservers zwischenspeichern kann.
Zugriffstoken sind typischerweise kurzlebig und haben eine Ablaufzeit (z. B. 1 Stunde). Clients müssen ein neues Zugriffstoken anfordern, wenn das aktuelle Token abläuft.
Welchen Tokentyp sollte ich verwenden?
Die Wahl zwischen einem opaken Token und einem JWT hängt von den Anwendungsfällen und den Sicherheitsanforderungen der Anwendung ab. Hier ist ein Vergleich der beiden Tokentypen:
Opaques Token | JWT | |
---|---|---|
Format | Zufällige Zeichenkette | Selbstausgesprochene JSON-Objekte |
Leistung | Erfordert eine zusätzliche Anfrage | Schnellere Validierung |
Selbstausgesprochen | Nein | Ja |
Token-Größe | Kleiner | Größer |
Widerruf | Sofortig | Erfordert Ablauf des Tokens oder Interaktion mit dem Authorisierungsserver |
Erweiterbarkeit | Begrenzt | Benutzerdefinierte Claims |
Zustandslos | Nein | Ja |
Sicherheit | Erfordert Tokenvalidierung | Erfordert Signaturvalidierung |
Standard | Nein | Ja (RFC 7519) |
Für weitere Informationen zur Wahl zwischen den beiden Tokentypen siehe Opaque token vs JWT .
Die Rollen des Autorisierungsservers und des Ressourcensservers
In den meisten Fällen hat der Autorisierungsserver (Authorization server) die folgenden Verantwortlichkeiten:
- Stellt Zugriffstoken an Clients nach erfolgreicher Authentifizierung und Autorisierung aus. Der Authorisierungsserver kann die Gültigkeitsbereiche (Scopes) reduzieren oder die Tokenanforderung basierend auf den Zugriffssteuerungsrichtlinien ablehnen (z. B. Benutzerzustimmung, Rollenbasierte Zugriffskontrolle (RBAC) , Attributbasierte Zugriffskontrolle (Attribute-based access control, ABAC) ).
- Prüft, ob das Zugriffstoken vom Authorisierungsserver ausgestellt wurde und nicht abgelaufen oder widerrufen ist ( Tokenintrospektion (Token introspection) ).
- Stellt Informationen über das Token (z. B. Gültigkeitsbereiche, Ablaufzeit) über Tokenintrospektion oder Userinfo-Endpoint bereit.
Du wirst feststellen, dass der Authorisierungsserver die Bedeutung des Zugriffstokens nicht interpretiert. Zum Beispiel kann das Zugriffstoken einen Scope read:orders
enthalten, aber der Authorisierungsserver weiß nicht, was der Scope bedeutet. Der Ressourcensserver ist verantwortlich für die Interpretation des Zugriffstokens und die Durchsetzung der Zugriffskontrolle (Access control) basierend auf den Scopes des Tokens. Das heißt, der Ressourcenserver (Resource server) hat normalerweise die folgenden Verantwortlichkeiten:
- Validiert die Claims im Zugriffstoken (z. B. Ablaufzeit, Ressourcenindikator, Gültigkeitsbereiche).
- Erzwingt die Zugriffssteuerung basierend auf den Claims des Tokens (normalerweise Scopes).
- Stellt die geschützten Ressourcen bereit, wenn das Zugriffstoken gültig ist.
Lebenszyklus eines Zugriffstokens (Access token)
Der Lebenszyklus eines Zugriffstokens umfasst typischerweise die folgenden Phasen: