Was ist Opaques Token?

Was ist ein Token?

Bevor wir opaques Token vorstellen, ist es wichtig zu verstehen, was ein Token ist:

Tokens werden verwendet, um sichere Informationen zwischen Parteien zu repräsentieren und zu übertragen. Sie unterstützen die überwiegende Mehrheit der Authentifizierung (Authentication) - und Autorisierung (Authorization) -Prozesse, die im Internet im Hintergrund ablaufen. Die beiden beliebtesten Arten von Tokens in Webdiensten sind JSON Web Token (JWT) und opaques Token.

Was ist ein opaques Token?

Opaques Token sind Tokens in einem proprietären Format, auf das man nicht zugreifen kann und das typischerweise einen Identifikator für Informationen im persistenten Speicher eines Servers enthält.

Ein opaques Token ist eine Form, die ein Token annehmen kann, und Access Tokens und Refresh Tokens können als opaques Tokens existieren. Das Format eines opaques Tokens wird von seinem Issuer (Issuer) bestimmt und ist typischerweise eine Zeichen- und/oder Zahlenfolge, die dem Issuer (Issuer) hilft, bestimmte Informationen in einer Datenbank abzurufen und zu identifizieren. Hier ist ein Beispiel für ein opaques Token:

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

Auf der anderen Seite ist JWT ein weiteres gängiges Token-Format. Es ist ein JSON-String, der alle Claims und Informationen sowie eine Signatur vom Issuer (Issuer) enthält. Standardmäßig ist es nicht verschlüsselt, kann jedoch mit dem JSON Web Encryption (JWE) -Standard verschlüsselt werden. Obwohl JWT typischerweise unverschlüsselt ist, beeinträchtigt dies nicht seine Sicherheit — das Vorhandensein der Signatur gewährleistet die Integrität des Token-Inhalts und ermöglicht volles Vertrauen in die Daten innerhalb des JWT.

Im Gegensatz zu JWT, das alle Informationen enthält, die für eine direkte Validierung an der geschützten Ressource erforderlich sind, können opaques Tokens nicht direkt von der Ressource validiert werden. Stattdessen erfordern sie eine Validierung durch den Issuer (Issuer) des opaques Tokens (normalerweise der Autorisierungsserver (Authorization server) ). Dieser Validierungsprozess wird typischerweise als Tokenintrospektion (Token introspection) bezeichnet.

Was ist JWT?

Im Gegensatz zu opaques Tokens ist ein JWT ein eigenständiges, zustandsloses Token, das Informationen in einem strukturierten und lesbaren Format trägt.

Ein JWT besteht aus drei Teilen: einem header, einem payload und einer signature, 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 Typ des Tokens und den Algorithmus, der für die Signierung verwendet wird. Zum Beispiel {"alg": "HS256", "typ": "JWT"}.
• Der payload-Abschnitt enthält Claims — Informationen über den Benutzer oder die Autorisierung — wie Benutzer-ID, Ablaufzeit und Scopes. Da diese Daten kodiert, aber nicht verschlüsselt sind, kann jeder, der das Token hat, es dekodieren, um die Claims zu sehen, obwohl er es nicht ändern kann, ohne die Signatur ungültig zu machen. Basierend auf der Spezifikation und der Konfiguration des Authorization Servers können verschiedene Claims im Payload enthalten sein. Dies verleiht dem Token seine eigenständige Natur. Zum Beispiel {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• Die signature wird durch die Kombination von Header, Payload und einem geheimen Schlüssel unter Verwendung des angegebenen Algorithmus erzeugt. 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, weil sie lokal vom Client oder einem beliebigen Dienst verifiziert werden können, ohne mit dem Authorization Server 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.

Diese Bequemlichkeit geht jedoch auch mit der Verantwortung einher, sicherzustellen, dass die Claims des Tokens nicht übermäßig exponiert werden, da sie für jeden sichtbar sind, der Zugriff auf das Token hat. Außerdem sind JWTs typischerweise kurzlebig, und die Ablaufzeit ist in den Claims des Tokens enthalten, um sicherzustellen, dass das Token nicht unbegrenzt gültig ist.

Validierung von opaques Access Tokens

Ein opaques Access Token wird validiert, indem es zur Überprüfung an den Authorization Server zurückgesendet wird. Der Authorization Server verwaltet den Status der ausgegebenen Tokens und kann die Gültigkeit des Tokens basierend auf seinem internen Speicher bestimmen.

1. Der Client fordert ein Access Token vom Authorization Server an.
2. Der Authorization Server gibt ein opaques Token aus.
3. Der Client sendet die Ressourcenanforderung mit dem opaques Token im Header.
4. Der Resource Provider sendet eine Token-Introspektionsanfrage an den Authorization Server, um das Token zu validieren.
5. Der Authorization Server antwortet mit den Token-Informationen.

Validierung von JWT Access Tokens (offline)

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

1. Der Resource Provider ruft vorab den öffentlichen Schlüssel des Authorization Servers von der OpenID Connect (OIDC) Discovery ab. Der öffentliche Schlüssel wird verwendet, um die Signatur des Tokens zu überprüfen und seine Integrität sicherzustellen.
2. Der Client fordert ein Access Token vom Authorization Server an.
3. Der Authorization Server gibt ein JWT Token aus.
4. Der Client sendet die Ressourcenanforderung mit dem JWT Token im Header.
5. Der Resource Provider dekodiert und validiert das JWT Token mit dem vom Authorization Server erhaltenen öffentlichen Schlüssel.
6. Der Resource Provider gewährt Zugriff basierend auf der Gültigkeit des Tokens.

Anwendungsfälle in OIDC

Im Kontext von OIDC ( OpenID Connect (OIDC) ) dienen opaques Tokens und JWTs unterschiedlichen Zwecken und werden in verschiedenen Szenarien verwendet.

Opaques Tokens

1. Abruf von Benutzerprofilen:

Standardmäßig, wenn ein Client ein Access Token ohne Angabe einer Ressource anfordert und den openid Scope einschließt, gibt der Authorization Server ein opaques Access Token aus. Dieses Token wird hauptsächlich verwendet, um Benutzerprofilinformationen vom OIDC /oidc/userinfo-Endpunkt abzurufen. Bei Erhalt einer Anfrage mit dem opaques Access Token überprüft der Authorization Server seinen internen Speicher, um die zugehörigen Autorisierungsinformationen abzurufen und die Gültigkeit des Tokens zu überprüfen, bevor er mit den Benutzerdetails antwortet.

2. Austausch von Refresh Tokens:

Refresh Tokens sind so konzipiert, dass sie nur zwischen dem Client und dem Authorization Server ausgetauscht werden, ohne dass sie mit Resource Providern geteilt werden müssen. Daher werden Refresh Tokens typischerweise als opaques Tokens ausgegeben. Wenn das aktuelle Access Token abläuft, kann der Client das opaques Refresh Token verwenden, um ein neues Access Token zu erhalten und so kontinuierlichen Zugriff ohne erneute Authentifizierung des Benutzers sicherzustellen.

JWTs

1. ID Token:

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

// Dekodierter Payload eines ID Tokens
{
  "iss": "<https://auth.wiki>",
  "sub": "1234567890",
  "aud": "client_id",
  "exp": 1630368000,
  "name": "John Doe",
  "email": "[email protected]",
  "picture": "<https://example.com/johndoe.jpg>"
}

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

2. Zugriff auf API-Ressourcen (mit Access Token):

Wenn ein Client ein Access Token mit einem spezifischen Ressourcenindikator (Resource indicator) anfordert, gibt der Authorization Server ein JWT Access Token aus, das für den Zugriff auf diese Ressource bestimmt ist. Das JWT enthält Claims, die der Resource Provider verwenden kann, um den Zugriff des Clients zu autorisieren. Zum Beispiel:

// Dekodierter Payload eines JWT Access Tokens
{
  "iss": "<https://auth.wiki>",
  "sub": "1234567890",
  "aud": "<https://api.example.com>",
  "scope": "read write",
  "exp": 1630368000
}

Der Resource Provider kann die Anfrage validieren, indem er die Claims überprüft:

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

Siehe auch

• JSON Web Token (JWT)