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", // 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 stellt einen Introspektions-Endpunkt zur Verfügung, 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 WertBasic <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_idundclient_secret:client_id: die Client-ID der Anwendung, die das Token angefordert hatclient_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)
"acr": "urn:logto:acr:1fa", // Authentifizierungsniveau, wenn erreicht
"amr": ["pwd"], // verwendete Authentifizierungsmethoden in der Interaktion
"auth_time": 1787745600 // Zeitpunkt der Authentifizierung des Benutzers (Epoch-Sekunden)
}
Wenn das Token ungültig ist, ist das Feld active auf false gesetzt und die anderen Ansprüche werden weggelassen. Siehe Step-up-Authentifizierung, um zu erfahren, wie acr, amr und auth_time validiert werden. Beachte, dass strukturierte JWT-Zugangstokens nicht am Endpunkt /oidc/token/introspection introspektiert werden können—validiere JWT-Zugangstokens immer lokal gegen den JWKS deines Tenants.
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.
Opaker Token und Organisationen
Opake Tokens können verwendet werden, um Organisationsmitgliedschaftsinformationen über den userinfo endpoint abzurufen. Wenn du die Berechtigung urn:logto:scope:organizations anforderst, gibt der userinfo endpoint die organisationsbezogenen Ansprüche des Benutzers zurück, wie organizations (Organisations-IDs) und organization_data.
Opake Tokens können jedoch nicht als Organisationstoken verwendet werden. Organisationstokens werden immer im JWT-Format ausgegeben, weil:
- Organisationstokens organisationsspezifische Ansprüche enthalten (wie
organization_idund bereichsspezifische Berechtigungen), die von Ressourcenservern validiert werden müssen. - 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.