Zum Hauptinhalt springen

Opaker Token

Während des Authentifizierungsprozesses, wenn keine Ressource angegeben ist, stellt Logto ein opakes Zugangstoken anstelle eines JWT aus. Das opake Token ist eine zufällige Zeichenfolge und viel kürzer als ein JWT:

{
  "access_token": "some-random-string", // opakes 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 bietet einen Introspektions-Endpunkt, 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 auch 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 Anmeldedaten müssen die Client-ID und das Client-Geheimnis 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-Geheimnis der Anwendung, die das Token angefordert hat

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

Der Introspektions-Endpunkt gibt ein JSON-Objekt mit den Ansprüchen 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, wird das active-Feld false sein und das sub-Feld wird weggelassen.

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

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.