Zum Hauptinhalt springen

Opaker Token (Opaque token)

Während des Authentifizierungsprozesses gibt Logto, wenn keine Ressource angegeben ist, ein opakes Zugangstoken (Opaque token) anstelle eines JWT aus. Das opake Token ist eine zufällige Zeichenkette und deutlich kürzer als ein JWT:

{
  "access_token": "some-random-string", // opaker Token
  "expires_in": 3600,
  "id_token": "eyJhbGc...aBc", // JWT
  "scope": "openid profile email",
  "token_type": "Bearer"
}

Das opake Token kann verwendet werden, um den userinfo endpoint aufzurufen und auf geschützte Ressourcen zuzugreifen, die Authentifizierung erfordern. Da es sich nicht um ein JWT handelt, wie kann der Ressourcenserver es validieren?

Logto stellt einen Introspektions-Endpunkt bereit, der zur Validierung opaker Tokens verwendet werden kann. Standardmäßig ist der Introspektions-Endpunkt /oidc/token/introspection und akzeptiert POST-Anfragen. Der folgende Parameter ist erforderlich:

  • token: das zu validierende opake Token

Der Endpunkt erfordert außerdem eine Client-Authentifizierung. Du kannst eine der folgenden Methoden verwenden:

  • HTTP Basic-Authentifizierung: Verwende den Authorization-Header mit dem Wert Basic <base64-encoded-credentials>. Die Zugangsdaten müssen die Client-ID und das Client-Secret sein, getrennt durch einen Doppelpunkt (:) und base64-codiert.
  • HTTP POST-Authentifizierung: Verwende die Parameter client_id und client_secret:
    • client_id: die Client-ID der Anwendung, die das Token angefordert hat
    • client_secret: das Client-Secret der Anwendung, die das Token angefordert hat

Die Client-ID (App-ID) und das Client-Secret (App-Secret) können die App-Zugangsdaten jeder "traditionellen Web"- oder "Maschine-zu-Maschine"-Anwendung in Logto sein. Der Introspektions-Endpunkt gibt einen Fehler zurück, wenn die Zugangsdaten ungültig sind.

Der Introspektions-Endpunkt gibt ein JSON-Objekt mit den Ansprüchen (Claims) des Tokens zurück:

{
  "active": true, // ob das Token gültig ist oder nicht
  "sub": "1234567890" // das Subjekt des Tokens (die Benutzer-ID)
}

Wenn das Token ungültig ist, ist das Feld active auf false gesetzt und das Feld sub wird weggelassen.

Hier ist ein nicht-normatives Beispiel für die Introspektions-Anfrage:

curl --location \
  --request POST 'https://[tenant-id].logto.app/oidc/token/introspection' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'token=some-random-string' \
  --data-urlencode 'client_id=1234567890' \
  --data-urlencode 'client_secret=1234567890'

Denke daran, [tenant-id] durch deine Tenant-ID zu ersetzen.

Opaker Token und Organisationen​

Opake Tokens können verwendet werden, um Organisationsmitgliedschaftsinformationen über den userinfo endpoint abzurufen. Wenn du den urn:logto:scope:organizations-Scope anforderst, gibt der userinfo endpoint die organisationsbezogenen Ansprüche (Claims) des Benutzers zurück, wie z. B. organizations (Organisations-IDs) und organization_data.

Opake Tokens können jedoch nicht als Organisationstoken verwendet werden. Organisationstokens werden immer im JWT-Format ausgegeben, weil:

  1. Organisationstokens enthalten organisationsspezifische Ansprüche (wie organization_id und bereichsspezifische Berechtigungen), die von Ressourcenservern validiert werden müssen.
  2. Das JWT-Format ermöglicht es Ressourcenservern, das Token zu überprüfen und den Organisationskontext ohne zusätzliche API-Aufrufe zu extrahieren.

Um ein Organisationstoken zu erhalten, musst du den Auffrischungstoken-Flow oder den Client-Credentials-Flow mit Organisationsparametern verwenden.