Deutsch

oidc
oauth
jwt
opakes Token

Opakes Token vs JWT

Verstehe die Unterschiede zwischen opaken Tokens und JWTs, ihre Anwendungsfälle und wie sie in OIDC-basierten Systemen validiert werden.

Simeng

Developer

8/30/2024

Verschwenden Sie keine Wochen mit Benutzerauthentifizierung

Bringen Sie sichere Apps schneller mit Logto auf den Markt. Integrieren Sie Benutzerauthentifizierung in Minuten und konzentrieren Sie sich auf Ihr Kernprodukt.

Jetzt starten

In Logto, einer auf OIDC basierenden umfassenden CIAM-Plattform, spielen Autorisierungstokens eine entscheidende Rolle bei der Sicherung von Benutzerinteraktionen und der Verwaltung des Zugriffs auf Ressourcen. Unter den verschiedenen Token-Typen, die für die Autorisierung verwendet werden, sind opake Tokens und JWTs (JSON Web Tokens) die wichtigsten.

Wir haben mehrere Fragen aus unserer Community erhalten, wie zum Beispiel: Was ist der Unterschied zwischen einem opaken Token und einem JWT? Warum kann ich das erhaltene Zugriffstoken nicht dekodieren, und warum scheint die Tokenlänge kurz zu sein? Dieser Blogpost zielt darauf ab, diese Konzepte zu klären und dir zu helfen, die Unterscheidungen zwischen opaken Tokens und JWTs, ihre Anwendungsfälle und warum du möglicherweise mit unterschiedlichem Verhalten beim Arbeiten mit ihnen konfrontiert wirst, zu verstehen.

Was ist ein opakes Token?

Ein opakes Token ist eine Art von Zugriffstoken, das, wie der Name schon sagt, für den Client oder eine externe Partei undurchsichtig oder nicht transparent ist. Das bedeutet, dass das Token selbst keine lesbaren Informationen über den Benutzer oder die erteilte Autorisierung enthält.

Wenn du ein opakes Token erhältst, erscheint es oft als scheinbar zufällige Zeichenfolge, und der Versuch, es zu dekodieren, ergibt keine sinnvollen Daten.

Hier ist ein Beispiel für ein opakes Token:

Da der eigentliche Inhalt des Tokens nur dem Autorisierungsserver bekannt ist, der es ausgegeben hat, muss der Client, um ein opakes Token zu validieren, es zurück an den Server senden, der dann seine Authentizität überprüft und die zugehörigen Berechtigungen ermittelt. Dieser Ansatz stellt sicher, dass sensible Informationen verborgen bleiben und bietet eine zusätzliche Sicherheitsebene, erfordert jedoch auch zusätzliche Serverkommunikation, um das Token zu validieren.

Vorteile:

sicher: Opake Tokens geben keine sensiblen Informationen an den Client preis. Der Inhalt des Tokens ist nur dem Autorisierungsserver bekannt.
widerrufbar: Da das Token auf dem Server gespeichert ist und die einzige Möglichkeit, es zu validieren, über den introspektiven Endpunkt auf dem Autorisierungsserver besteht, kann der Server das Token bei Bedarf leicht widerrufen und unbefugten Zugriff verhindern.
kleine Größe: Opake Tokens sind in der Regel kürzer als JWTs, was für Leistung und Speicherplatzüberlegungen von Vorteil sein kann.

Nachteile:

zustandsbehaftet: Opake Tokens erfordern, dass der Autorisierungsserver einen Zustand beibehält, um das Token zu validieren, was zusätzliche Komplexität und Overhead einführen kann.
Leistung: Die Notwendigkeit zusätzlicher Serverkommunikation zur Validierung des Tokens kann die Leistung beeinträchtigen, insbesondere in Hochlastszenarien.

Was ist ein JWT?

Im Gegensatz zu opaken Tokens ist ein JWT (JSON Web Token) ein eigenständiges, zustandsloses Token, das Informationen in einem strukturierten und lesbaren Format enthält.

Ein JWT besteht aus drei Teilen: einem Header, einem Payload und einer Signatur, die jeweils in Base64URL kodiert sind.

Hier ist ein Beispiel für ein JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Der Header enthält Informationen über den Tokentyp und den für die Signierung verwendeten Algorithmus. Zum Beispiel, {"alg": "HS256", "typ": "JWT"}.
Der Payload-Abschnitt enthält Ansprüche – Informationsstücke über den Benutzer oder die Autorisierung – wie Benutzer-ID, Ablaufzeit und Bereiche. Da diese Daten kodiert, aber nicht verschlüsselt sind, kann jeder, der das Token hat, es dekodieren und die Ansprüche sehen, obwohl er sie nicht ändern kann, ohne die Signatur ungültig zu machen. Basierend auf der Spezifikation und der Konfiguration des Autorisierungsservers können verschiedene Ansprüche im Payload enthalten sein. Dies verleiht dem Token seine eigenständige Natur. Zum Beispiel, {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
Die Signatur wird durch die Kombination von Header, Payload und einem geheimen Schlüssel unter Verwendung des angegebenen Algorithmus generiert. Diese Signatur wird verwendet, um die Integrität des Tokens zu überprüfen und sicherzustellen, dass es nicht manipuliert wurde.

JWTs werden häufig verwendet, da sie lokal vom Client oder einem beliebigen Dienst verifiziert werden können, ohne mit dem Autorisierungsserver interagieren zu müssen. Dies macht JWTs besonders effizient für verteilte Systeme, in denen mehrere Dienste die Authentizität des Tokens unabhängig überprüfen müssen.

Allerdings kommt diese Bequemlichkeit auch mit der Verantwortung, sicherzustellen, dass die Ansprüche des Tokens nicht übermäßig exponiert sind, da sie für jeden sichtbar sind, der Zugriff auf das Token hat. Zudem haben JWTs in der Regel eine kurze Lebensdauer, und die Ablaufzeit ist in den Ansprüchen des Tokens enthalten, um sicherzustellen, dass das Token nicht unbegrenzt gültig ist.

Vorteile:

zustandslos: JWTs sind eigenständig und erfordern keinen serverseitigen Zustand zur Validierung.
Kompatibilität zwischen Diensten: JWTs können leicht zwischen verschiedenen Diensten geteilt und verifiziert werden, was sie ideal für verteilte Systeme macht.
erweiterbar: Der Payload eines JWT kann benutzerdefinierte Ansprüche enthalten, die flexible Autorisierung und Informationsaustausch ermöglichen.
standardisiert: JWT-Tokens folgen einem gut definierten Standard (RFC 7519), was sie weit unterstützt und interoperabel macht.

Nachteile:

Exposition: Die Ansprüche in einem JWT sind für jeden sichtbar, der Zugriff auf das Token hat, daher sollten sensible Informationen nicht im Payload enthalten sein.
große Größe: JWTs können aufgrund der zusätzlichen Informationen, die sie tragen, größer als opake Tokens sein, was die Leistung und Speicherplatzüberlegungen beeinträchtigen kann. Die Ansprüche in einem JWT-Token sollten auf ein Minimum reduziert werden, um die Token-Größe zu verringern.
Komplexität des Widerrufs: Da JWTs zustandslos sind, sind sie in der Regel für eine kurze Zeit gültig, und es gibt keinen eingebauten Mechanismus, um Tokens vor ihrem Ablauf zu widerrufen, was bedeutet, dass ein kompromittiertes Token bis zu seinem Ablauf gültig bleiben kann.

Validierung eines opaken Zugriffstokens

Ein opakes Zugriffstoken wird validiert, indem es zur Überprüfung an den Autorisierungsserver zurückgesendet wird. Der Autorisierungsserver verwaltet den Zustand der ausgegebenen Tokens und kann die Gültigkeit des Tokens basierend auf seinem internen Speicher bestimmen.

Der Client fordert ein Zugriffstoken vom Autorisierungsserver an.
Der Autorisierungsserver gibt ein opakes Token aus.
Der Client sendet die Ressourcenanforderung mit dem opaken Token im Header.
Der Ressourcenanbieter sendet eine Token-Introspektionsanfrage an den Autorisierungsserver, um das Token zu validieren.
Der Autorisierungsserver antwortet mit den Token-Informationen.

Validierung eines JWT-Zugriffstokens (offline)

Ein JWT-Zugriffstoken kann offline vom Client oder einem beliebigen Dienst, der Zugriff auf den öffentlichen Schlüssel des Tokens hat, validiert werden.

Der Ressourcenanbieter holt im Voraus den öffentlichen Schlüssel des Autorisierungsservers vom OIDC-Discovery-Endpunkt. Der öffentliche Schlüssel wird verwendet, um die Signatur des Tokens zu überprüfen und seine Integrität sicherzustellen.
Der Client fordert ein Zugriffstoken vom Autorisierungsserver an.
Der Autorisierungsserver gibt ein JWT-Token aus.
Der Client sendet die Ressourcenanforderung mit dem JWT-Token im Header.
Der Ressourcenanbieter dekodiert und validiert das JWT-Token mithilfe des vom Autorisierungsserver erhaltenen öffentlichen Schlüssels.
Der Ressourcenanbieter gewährt den Zugriff basierend auf der Gültigkeit des Tokens.

Anwendungsfälle in OIDC

Im Kontext von OIDC (OpenID Connect) haben opake Tokens und JWTs unterschiedliche Zwecke und werden in verschiedenen Szenarien verwendet.

Opake Tokens

Benutzerprofilabruf:

Standardmäßig gibt der Autorisierungsserver ein opakes Zugriffstoken aus, wenn ein Client ein Zugriffstoken anfordert, ohne eine Ressource anzugeben und den openid-Bereich einzuschließen. Dieses Token wird hauptsächlich verwendet, um Benutzerprofilinformationen vom OIDC /oidc/userinfo-Endpunkt abzurufen. Nach Erhalt einer Anfrage mit dem opaken Zugriffstoken überprüft der Autorisierungsserver seinen internen Speicher, um die damit verbundenen Autorisierungsinformationen abzurufen und die Gültigkeit des Tokens zu überprüfen, bevor er mit den Benutzerprofildaten antwortet.

Austausch von Refresh Tokens:

Refresh Tokens sind speziell dafür ausgelegt, nur zwischen dem Client und dem Autorisierungsserver ausgetauscht zu werden, ohne mit Ressourcenanbietern geteilt zu werden. Daher werden Refresh Tokens in der Regel als opake Tokens ausgegeben. Wenn das aktuelle Zugriffstoken abläuft, kann der Client das opake Refresh Token verwenden, um ein neues Zugriffstoken zu erhalten und somit kontinuierlichen Zugriff ohne erneute Authentifizierung des Benutzers sicherzustellen.

JWTs

ID-Token:

In OIDC ist das ID-Token ein JWT, das Benutzerinformationen enthält und zur Authentifizierung des Benutzers verwendet wird. Typischerweise wird das ID-Token zusammen mit dem Zugriffstoken ausgegeben und ermöglicht es dem Client, die Identität des Benutzers zu überprüfen. Zum Beispiel:

Der Client kann das ID-Token validieren, um die Identität des Benutzers sicherzustellen und Benutzerinformationen für Personalisierungs- oder Autorisierungszwecke extrahieren. Das ID-Token ist nur für die einmalige Verwendung gedacht und sollte nicht zur Autorisierung von API-Ressourcen verwendet werden.

API-Ressourcenzugriff:

Wenn ein Client ein Zugriffstoken mit einem bestimmten Ressourcenindikator anfordert, gibt der Autorisierungsserver ein JWT-Zugriffstoken aus, das für den Zugriff auf diese Ressource bestimmt ist. Das JWT enthält Ansprüche, die der Ressourcenanbieter verwenden kann, um den Zugriff des Clients zu autorisieren. Zum Beispiel:

Der Ressourcenanbieter kann die Anfrage validieren, indem er die Ansprüche überprüft:

iss: Bestätigt, dass das Token von einem vertrauenswürdigen Autorisierungsserver ausgestellt wurde.
sub: Identifiziert den Benutzer, mit dem das Token verknüpft ist.
aud: Stellt sicher, dass das Token für die spezifische Ressource bestimmt ist.
scope: Überprüft die dem Benutzer gewährten Berechtigungen.

Fazit

Zusammenfassend dienen opake Tokens und JWTs unterschiedlichen Zwecken in OIDC-basierten Systemen, wobei opake Tokens einen sicheren und zustandsbehafteten Ansatz für die Autorisierung bieten und JWTs eine eigenständige und zustandslose Alternative darstellen. Das Verständnis der Unterscheidungen zwischen diesen Token-Typen und ihren Anwendungsfällen ist entscheidend für die Gestaltung sicherer und effizienter Authentifizierungs- und Autorisierungsmechanismen in deinen Anwendungen.

Entdecke mehr Funktionen von Zugriffstokens in Logto:

Jetzt Logto ausprobieren

Was ist ein opakes Token?#

Was ist ein JWT?#

Validierung eines opaken Zugriffstokens#

Validierung eines JWT-Zugriffstokens (offline)#

Anwendungsfälle in OIDC#

Opake Tokens#

JWTs#

Fazit#

Was ist ein opakes Token?#

Was ist ein JWT?#

Validierung eines opaken Zugriffstokens#

Validierung eines JWT-Zugriffstokens (offline)#

Anwendungsfälle in OIDC#

Opake Tokens#

JWTs#

Fazit#

Was ist ein opakes Token?

Was ist ein JWT?

Validierung eines opaken Zugriffstokens

Validierung eines JWT-Zugriffstokens (offline)

Anwendungsfälle in OIDC

Opake Tokens

JWTs

Fazit

Was ist ein opakes Token?

Was ist ein JWT?

Validierung eines opaken Zugriffstokens

Validierung eines JWT-Zugriffstokens (offline)

Anwendungsfälle in OIDC

Opake Tokens

JWTs

Fazit