4. Sicherheitsüberlegungen

Da es viele verschiedene und gültige Möglichkeiten gibt, ein OAuth 2.0-System zu implementieren, gibt es folglich viele Möglichkeiten für einen Autorisierungsserver festzustellen, ob ein Token derzeit "active" (aktiv) ist oder nicht. Da sich Ressourcenserver, die Token-Introspektion verwenden, jedoch auf den Autorisierungsserver verlassen, um den Status eines Tokens zu bestimmen, MUSS (MUST) der Autorisierungsserver alle anwendbaren Prüfungen gegen den Status eines Tokens durchführen. Beispielsweise gehören zu diesen Tests die folgenden:

Wenn das Token ablaufen kann, MUSS (MUST) der Autorisierungsserver feststellen, ob das Token abgelaufen ist.
Wenn das Token ausgestellt werden kann, bevor es verwendet werden kann, MUSS (MUST) der Autorisierungsserver feststellen, ob der Gültigkeitszeitraum eines Tokens bereits begonnen hat.
Wenn das Token nach seiner Ausstellung widerrufen werden kann, MUSS (MUST) der Autorisierungsserver feststellen, ob ein solcher Widerruf stattgefunden hat.
Wenn das Token signiert wurde, MUSS (MUST) der Autorisierungsserver die Signatur validieren.
Wenn das Token nur auf bestimmten Ressourcenservern verwendet werden kann, MUSS (MUST) der Autorisierungsserver feststellen, ob das Token auf dem Ressourcenserver verwendet werden kann, der den Introspektionsaufruf durchführt.

Wenn ein Autorisierungsserver eine anwendbare Prüfung nicht durchführt, könnte der Ressourcenserver basierend auf dieser Antwort eine fehlerhafte Sicherheitsentscheidung treffen. Beachten Sie, dass nicht alle dieser Prüfungen auf alle OAuth 2.0-Bereitstellungen anwendbar sind und es dem Autorisierungsserver überlassen bleibt zu bestimmen, welche dieser Prüfungen (und andere Prüfungen) gelten.

Wenn der Introspektionsendpunkt ungeschützt und ungedrosselt bleibt, könnte er einem Angreifer eine Möglichkeit bieten, eine Reihe möglicher Token-Werte abzufragen und nach einem gültigen Token zu fischen. Um dies zu verhindern, MUSS (MUST) der Autorisierungsserver eine Authentifizierung geschützter Ressourcen verlangen, die auf den Introspektionsendpunkt zugreifen müssen, und SOLLTE (SHOULD) verlangen, dass geschützte Ressourcen speziell autorisiert sind, den Introspektionsendpunkt aufzurufen. Die Einzelheiten solcher Authentifizierungsdaten liegen außerhalb des Geltungsbereichs dieser Spezifikation, aber üblicherweise können diese Anmeldeinformationen die Form jedes gültigen Client-Authentifizierungsmechanismus annehmen, der mit dem Token-Endpunkt verwendet wird, eines OAuth 2.0-Zugriffstokens oder eines anderen HTTP-Autorisierungs- oder Authentifizierungsmechanismus. Ein einzelnes Softwarestück, das sowohl als Client als auch als geschützte Ressource fungiert, KANN (MAY) dieselben Anmeldeinformationen zwischen dem Token-Endpunkt und dem Introspektionsendpunkt wiederverwenden, obwohl dies möglicherweise die Aktivitäten der Client- und der geschützten Ressourcenteile der Software vermischt und der Autorisierungsserver separate Anmeldeinformationen für jeden Modus verlangen KANN (MAY).

Da der Introspektionsendpunkt OAuth 2.0-Tokens als Parameter entgegennimmt und mit Informationen antwortet, die für Autorisierungsentscheidungen verwendet werden, MUSS (MUST) der Server Transport Layer Security (TLS) 1.2 [RFC5246] unterstützen und KANN (MAY) zusätzliche Transportschichtmechanismen unterstützen, die seine Sicherheitsanforderungen erfüllen. Bei Verwendung von TLS MUSS (MUST) der Client oder die geschützte Ressource eine TLS/SSL-Serverzertifikatsprüfung durchführen, wie in [RFC6125] spezifiziert. Implementierungssicherheitsüberlegungen finden sich in Recommendations for Secure Use of TLS and DTLS [BCP195].

Um zu verhindern, dass die Werte von Zugriffstokens über Abfrageparameter in serverseitige Protokolle gelangen, KANN (MAY) ein Autorisierungsserver, der Token-Introspektion anbietet, die Verwendung von HTTP GET am Introspektionsendpunkt untersagen und stattdessen verlangen, dass die HTTP POST-Methode am Introspektionsendpunkt verwendet wird.

Um die Offenlegung des internen Zustands des Autorisierungsservers zu vermeiden, SOLLTE (SHOULD) eine Introspektionsantwort für ein inaktives Token KEINE zusätzlichen Ansprüche enthalten, die über den erforderlichen Anspruch "active" (mit dem Wert "false") hinausgehen.

Da eine geschützte Ressource die Antwort des Introspektionsendpunkts zwischenspeichern KANN (MAY), MÜSSEN (MUST) Designer eines OAuth 2.0-Systems, die dieses Protokoll verwenden, die Leistungs- und Sicherheitskompromisse berücksichtigen, die mit dem Zwischenspeichern solcher Sicherheitsinformationen verbunden sind. Ein weniger aggressiver Cache mit einem kurzen Timeout liefert der geschützten Ressource aktuellere Informationen (da sie den Introspektionsendpunkt häufiger abfragen muss) auf Kosten eines erhöhten Netzwerkverkehrs und einer erhöhten Last auf dem Introspektionsendpunkt. Ein aggressiverer Cache mit einer längeren Dauer minimiert den Netzwerkverkehr und die Last auf dem Introspektionsendpunkt, jedoch auf die Gefahr veralteter Informationen über das Token hin. Beispielsweise kann das Token widerrufen werden, während sich die geschützte Ressource auf den Wert der zwischengespeicherten Antwort verlässt, um Autorisierungsentscheidungen zu treffen. Dies schafft ein Zeitfenster, in dem ein widerrufenes Token bei der geschützten Ressource verwendet werden könnte. Folglich muss eine akzeptable Cache-Gültigkeitsdauer unter Berücksichtigung der Bedenken und Empfindlichkeiten der zugegriffenen geschützten Ressource und der Wahrscheinlichkeit, dass ein Token in der Zwischenzeit widerrufen oder ungültig wird, sorgfältig abgewogen werden. Hochsensible Umgebungen können sich dafür entscheiden, das Caching auf der geschützten Ressource vollständig zu deaktivieren, um das Risiko veralteter zwischengespeicherter Informationen vollständig zu eliminieren, wiederum auf Kosten eines erhöhten Netzwerkverkehrs und einer erhöhten Serverlast. Wenn die Antwort den Parameter "exp" (Ablauf) enthält, DARF die Antwort NICHT (MUST NOT) über die darin angegebene Zeit hinaus zwischengespeichert werden.

Ein Autorisierungsserver, der Token-Introspektion anbietet, muss in der Lage sein, die ihm während dieses Aufrufs präsentierten Token-Werte zu verstehen. Die genauen Mittel, mit denen dies geschieht, sind ein Implementierungsdetail und liegen außerhalb des Geltungsbereichs dieser Spezifikation. Bei unstrukturierten Tokens könnte dies in Form einer einfachen serverseitigen Datenbankabfrage gegen einen Datenspeicher erfolgen, der die Kontextinformationen für das Token enthält. Bei strukturierten Tokens könnte dies in Form des Servers erfolgen, der das Token parsiert, seine Signatur oder andere Schutzmechanismen validiert und die im Token enthaltenen Informationen an die geschützte Ressource zurückgibt (wodurch die geschützte Ressource den Inhalt des Tokens nicht kennen muss, ähnlich wie der Client). Beachten Sie, dass bei Tokens, die verschlüsselte Informationen tragen, die während des Introspektionsprozesses benötigt werden, der Autorisierungsserver in der Lage sein muss, das Token zu entschlüsseln und zu validieren, um auf diese Informationen zuzugreifen. Beachten Sie auch, dass in Fällen, in denen der Autorisierungsserver keine Informationen über das Token speichert und keine Möglichkeit hat, durch Parsen des Tokens selbst auf Informationen über das Token zuzugreifen, er wahrscheinlich keinen Introspektionsdienst anbieten kann.