1. Introduction (Einführung)
1. Introduction (Einführung)
Die OAuth 2.0-Kernspezifikation [RFC6749] definiert mehrere Möglichkeiten für einen Client, refresh tokens (Aktualisierungstoken) und access tokens (Zugriffstoken) zu erhalten. Diese Spezifikation ergänzt die Kernspezifikation um einen Mechanismus zum Widerrufen beider Arten von Token. Ein Token ist eine Zeichenfolge, die eine von dem resource owner (Ressourcenbesitzer) an den Client ausgegebene authorization grant (Autorisierungszuteilung) darstellt. Eine Widerrufsanforderung macht das eigentliche Token und gegebenenfalls andere Token auf der Grundlage derselben Autorisierungszuteilung und die Autorisierungszuteilung selbst ungültig.
Aus der Perspektive eines end-user (Endbenutzers) wird OAuth häufig verwendet, um sich bei einer bestimmten Site oder Anwendung anzumelden. Dieser Widerrufsmechanismus ermöglicht es einem Client, seine Token ungültig zu machen, wenn sich der Endbenutzer abmeldet, die Identität ändert oder die jeweilige Anwendung deinstalliert. Die Benachrichtigung des Autorisierungsservers, dass das Token nicht mehr benötigt wird, ermöglicht es dem Autorisierungsserver, die mit diesem Token verbundenen Daten (z. B. Sitzungsdaten) und die zugrunde liegende Autorisierungszuteilung zu bereinigen. Dieses Verhalten verhindert eine Situation, in der für einen bestimmten Client noch eine gültige Autorisierungszuteilung besteht, von der der Endbenutzer nichts weiß. Auf diese Weise verhindert der Token-Widerruf den Missbrauch verlassener Token und ermöglicht ein besseres Endbenutzererlebnis, da ungültige Autorisierungszuteilungen nicht mehr in einer Liste von Autorisierungszuteilungen auftauchen, die der Autorisierungsserver dem Endbenutzer präsentieren könnte.
1.1. Requirements Language (Anforderungssprache)
Die Schlüsselwörter "MUST" (MUSS), "MUST NOT" (DARF NICHT), "REQUIRED" (ERFORDERLICH), "SHALL" (SOLL), "SHALL NOT" (SOLL NICHT), "SHOULD" (SOLLTE), "SHOULD NOT" (SOLLTE NICHT), "RECOMMENDED" (EMPFOHLEN), "MAY" (KANN) und "OPTIONAL" (OPTIONAL) in diesem Dokument sind so zu interpretieren, wie in RFC 2119 [RFC2119] beschrieben.