OAuth 2.0 Token-Inspektion

Die OAuth 2.0 Token-Inspektion definiert eine Methode, die es einer autorisierten geschützten Ressource ermöglicht, den Autorisierungsserver abzufragen, um die Metadaten eines bestimmten Tokens (entweder eines Zugriffstokens oder eines Auffrischungstokens), das von einem OAuth-Client bereitgestellt wird, zu bestimmen. Auf Grundlage der Metadaten des spezifischen Tokens ermöglicht es dem Ressourceninhaber, auf die geschützte Ressource zuzugreifen.

Diese Metadaten umfassen:

• Ob das Token derzeit aktiv ist (oder ob es abgelaufen oder widerrufen wurde)
• Die Berechtigungen, die das Zugriffstoken gewährt (normalerweise durch OAuth 2.0-Bereiche vermittelt)
• Den Autorisierungskontext, in dem das Token gewährt wurde (einschließlich wer das Token autorisiert hat und welchem Client es ausgestellt wurde)

Die Token-Inspektion ermöglicht es der geschützten Ressource, diese Informationen abzufragen, unabhängig davon, ob sie im Token selbst enthalten sind.

Es gibt zwei Arten von Zugriffstoken, je nachdem wie sie codiert sind:

• Identifikator-basiert: Das Token repräsentiert einen zufälligen, schwer zu erratenden Identifikator, der mit der Autorisierung in der Datenbank des Autorisierungsservers verbunden ist.
• Selbstenthaltend: Die Autorisierung ist im Token selbst codiert und wird durch Kryptographie geschützt, um Manipulationen zu verhindern. JSON Web Token (JWT) ist der gängige Standard für diese Methode.

Bei selbstenthaltenden Tokens können die autorisierungsbezogenen Metadaten direkt aus dem Zugriffstoken geparst werden. Bei identifikator-basierten Tokens muss jedoch die Token-Inspektionsfunktion des Autorisierungsservers verwendet werden, um die Metadaten zu validieren/abrufen.

Token-Inspektionsanfrage#

Die Verwendung von identifikator-basierten Zugriffstokens erfordert eine Überprüfung beim Autorisierungsserver über eine Netzwerkanfrage. Dafür gibt es ein standardisiertes Protokoll namens OAuth 2.0 Token Introspection (RFC 7662).

Die geschützte Ressource wird das Token zum Inspektionsendpunkt des Autorisierungsservers POSTen, und im Gegenzug erhält sie ein JSON-Objekt, das die Parameter des Tokens enthält.

Bitte beachten Sie, dass Inspektionsanfragen nicht willkürlich initiiert werden können; sie müssen eine der folgenden Bedingungen erfüllen:

• Authentifizierung mit Anmeldedaten (die beim Autorisierungsserver vorregistriert sein müssen) oder
• Autorisierung mittels eines Zugriffstokens.

Infolgedessen wird in dieser spezifischen Interaktion die geschützte Ressource zum OAuth-Client und der Autorisierungsserver zur geschützten Ressource.

Nachfolgend ein Beispiel für eine Inspektionsanfrage, bei der die geschützte Ressource sich mit einer Client-ID und einem Client-Geheimnis authentifiziert, die nach der Registrierung als OAuth-Client beim Autorisierungsserver erhalten wurden.

Nachfolgend ein Beispiel für eine Inspektionsanfrage, die direkt ein Zugriffstoken verwendet. Das Zugriffstoken kann direkt vom /token Endpunkt durch die Verwendung der Anmeldeinformationen einer registrierten Maschine-zu-Maschine-App und des client_credentials Grant-Typs erhalten werden.

Token-Inspektionsantwort#

Der wichtigste Parameter ist active, ein Boolescher Wert. Wenn true, zeigt dies an, dass das Token gültig ist, und das JSON-Objekt wird andere Token-Details, wie die Bereichswerte, enthalten. Wenn false, ist das Token entweder ungültig oder abgelaufen, und die geschützte Ressource muss eine 401 Unauthorized-Antwort mit dem invalid_token Fehlercode zurückgeben.

Hier ist ein Beispiel für eine Antwort auf ein gültiges Token:

Abgesehen von active, das erforderlich ist, sind alle anderen Parameter optional.

Die geschützte Ressource kann diese zusätzlichen Felder nutzen, um die Zugriffsberechtigungen zu bestimmen, ähnlich wie sie ein JWT-Zugriffstoken parsen und validieren würde.