1. Einführung
In OAuth 2.0 [RFC6749] ist der Inhalt von Tokens für Clients undurchsichtig. Dies bedeutet, dass der Client nichts über den Inhalt oder die Struktur des Tokens selbst wissen muss, falls vorhanden. Es gibt jedoch immer noch eine große Menge an Metadaten, die an ein Token angehängt werden können, wie z. B. seine aktuelle Gültigkeit, genehmigte Scopes und Informationen über den Kontext, in dem das Token ausgestellt wurde. Diese Informationen sind oft von entscheidender Bedeutung für geschützte Ressourcen, die Autorisierungsentscheidungen basierend auf den präsentierten Tokens treffen. Da OAuth 2.0 kein Protokoll definiert, mit dem der Ressourcenserver Metainformationen über ein Token erfahren kann, das er von einem Autorisierungsserver erhalten hat, wurden mehrere verschiedene Ansätze entwickelt, um diese Lücke zu schließen. Dazu gehören die Verwendung strukturierter Token-Formate wie JWT [RFC7519] oder proprietäre Service-übergreifende Kommunikationsmechanismen (wie gemeinsame Datenbanken und geschützte Enterprise Service Buses), die Token-Informationen übermitteln.
Diese Spezifikation definiert ein Protokoll, das es autorisierten geschützten Ressourcen ermöglicht, den Autorisierungsserver abzufragen, um den Satz von Metadaten für ein bestimmtes Token zu ermitteln, das ihnen von einem OAuth 2.0-Client präsentiert wurde. Diese Metadaten umfassen, ob das Token derzeit aktiv ist (oder ob es abgelaufen oder auf andere Weise widerrufen wurde), welche Zugriffsrechte das Token trägt (normalerweise über OAuth 2.0-Scopes übermittelt) und den Autorisierungskontext, in dem das Token gewährt wurde (einschließlich wer das Token autorisiert hat und an welchen Client es ausgestellt wurde). Token-Introspektion ermöglicht es einer geschützten Ressource, diese Informationen abzufragen, unabhängig davon, ob sie im Token selbst enthalten sind oder nicht, sodass diese Methode zusammen mit oder unabhängig von strukturierten Token-Werten verwendet werden kann. Darüber hinaus kann eine geschützte Ressource den in dieser Spezifikation beschriebenen Mechanismus verwenden, um das Token in einem bestimmten Autorisierungsentscheidungskontext zu introspektieren und die relevanten Metadaten über das Token zu ermitteln, um diese Autorisierungsentscheidung angemessen zu treffen.
1.1. Notationskonventionen
Die Schlüsselwörter 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY' und 'OPTIONAL' in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.
Sofern nicht anders angegeben, wird bei allen Protokollparameternamen und -werten zwischen Groß- und Kleinschreibung unterschieden.
1.2. Terminologie
Dieser Abschnitt definiert die in dieser Spezifikation verwendete Terminologie. Dieser Abschnitt ist ein normativer Teil dieser Spezifikation und stellt Anforderungen an Implementierungen.
Diese Spezifikation verwendet die Begriffe "access token (Zugriffstoken)", "authorization endpoint (Autorisierungsendpunkt)", "authorization grant (Autorisierungsgenehmigung)", "authorization server (Autorisierungsserver)", "client (Client)", "client identifier (Client-Identifikator)", "protected resource (geschützte Ressource)", "refresh token (Aktualisierungstoken)", "resource owner (Ressourcenbesitzer)", "resource server (Ressourcenserver)" und "token endpoint (Token-Endpunkt)", die von OAuth 2.0 [RFC6749] definiert werden, sowie die Begriffe "claim names (Anspruchsnamen)" und "claim values (Anspruchswerte)", die von JSON Web Token (JWT) [RFC7519] definiert werden.
Diese Spezifikation definiert die folgenden Begriffe:
Token Introspection (Token-Introspektion) : Der Akt der Abfrage des aktuellen Zustands eines OAuth 2.0-Tokens durch Verwendung des in diesem Dokument definierten Netzwerkprotokolls.
Introspection Endpoint (Introspektionsendpunkt) : Der OAuth 2.0-Endpunkt, über den die Token-Introspektionsoperation durchgeführt wird.