5. Sicherheitsüberlegungen

Da Anfragen an den Client-Registrierungsendpunkt zur Übertragung von Klartext-Anmeldeinformationen führen (in der HTTP-Anfrage und -Antwort), MUSS der Autorisierungsserver die Verwendung eines Transport-Layer-Sicherheitsmechanismus verlangen, wenn Anfragen an den Registrierungsendpunkt gesendet werden. Der Server MUSS TLS 1.2 [RFC5246] unterstützen und KANN zusätzliche Transport-Layer-Sicherheitsmechanismen unterstützen, die seine Sicherheitsanforderungen erfüllen. Bei Verwendung von TLS MUSS der Client eine TLS/SSL-Serverzertifikatsprüfung gemäß RFC 6125 [RFC6125] durchführen. Sicherheitsüberlegungen zur Implementierung finden sich in den Empfehlungen für die sichere Verwendung von TLS und DTLS [BCP195].

Für Clients, die auf Weiterleitung basierende Grant-Typen wie "authorization_code" und "implicit" verwenden, MÜSSEN Autorisierungsserver verlangen, dass Clients ihre Umleitungs-URI-Werte registrieren. Dies kann dazu beitragen, Angriffe abzuschwächen, bei denen schurkische Akteure einen gültig registrierten Client einschleusen und imitieren und dessen Autorisierungscode oder Token über eine ungültige Umleitungs-URI oder einen offenen Redirector abfangen. Darüber hinaus MÜSSEN registrierte Umleitungs-URI-Werte, um das Hijacking der Rückgabewerte der Umleitung zu verhindern, einer der folgenden sein:

Eine durch TLS geschützte Remote-Website (z. B. https://client.example.com/oauth_redirect)
Eine auf dem lokalen Computer unter Verwendung einer HTTP-URI gehostete Website (z. B. http://localhost:8080/oauth_redirect)
Eine nicht-HTTP-anwendungsspezifische URL, die nur der Client-Anwendung zur Verfügung steht (z. B. exampleapp://oauth_redirect)

Öffentliche Clients KÖNNEN sich bei einem Autorisierungsserver unter Verwendung dieses Protokolls registrieren, wenn die Richtlinie des Autorisierungsservers dies zulässt. Öffentliche Clients verwenden einen "none"-Wert für das Metadatenfeld "token_endpoint_auth_method" und werden im Allgemeinen mit dem Grant-Typ "implicit" verwendet. Oft handelt es sich bei diesen Clients um kurzlebige In-Browser-Anwendungen, die Zugriff auf die Ressourcen eines Benutzers anfordern, und der Zugriff ist an eine aktive Sitzung eines Benutzers auf dem Autorisierungsserver gebunden. Da solche Clients oft keine langfristige Speicherung haben, ist es möglich, dass solche Clients sich jedes Mal neu registrieren müssen, wenn die Browseranwendung geladen wird. Um die daraus resultierende Verbreitung von toten Client-Identifikatoren zu vermeiden, KANN ein Autorisierungsserver entscheiden, Registrierungen für bestehende Clients, die bestimmte Kriterien erfüllen, nach Ablauf einer bestimmten Zeitspanne ablaufen zu lassen. Alternativ könnten solche Clients auf dem Server registriert werden, von dem der Code der In-Browser-Anwendung bereitgestellt wird, und die Konfiguration des Clients könnte zusammen mit dem Code an den Browser gepusht werden.

Da verschiedene OAuth 2.0 Grant-Typen unterschiedliche Sicherheits- und Nutzungseigenschaften haben, KANN ein Autorisierungsserver separate Registrierungen für eine Software verlangen, um mehrere Grant-Typen zu unterstützen. Beispielsweise könnte ein Autorisierungsserver verlangen, dass alle Clients, die den Grant-Typ "authorization_code" verwenden, ein Client-Secret für die "token_endpoint_auth_method" verwenden, aber alle Clients, die den Grant-Typ "implicit" verwenden, keine Authentifizierung am Token-Endpunkt verwenden. In einer solchen Situation KANN ein Server Clients verbieten, sich gleichzeitig für die Grant-Typen "authorization_code" und "implicit" zu registrieren. In ähnlicher Weise wird der Grant-Typ "authorization_code" verwendet, um den Zugriff im Namen eines Endbenutzers darzustellen, aber der Grant-Typ "client_credentials" stellt den Zugriff im Namen des Clients selbst dar. Aus Sicherheitsgründen könnte ein Autorisierungsserver verlangen, dass für diese unterschiedlichen Anwendungsfälle unterschiedliche Bereiche verwendet werden, und infolgedessen KANN er verbieten, dass diese beiden Grant-Typen vom selben Client zusammen registriert werden. In all diesen Fällen würde der Autorisierungsserver mit einer "invalid_client_metadata" Fehlerantwort antworten.

Sofern nicht als Claim in einem Software Statement verwendet, MUSS der Autorisierungsserver alle Client-Metadaten als selbst zertifiziert behandeln. Beispielsweise könnte ein schurkischer Client den Namen und das Logo eines legitimen Clients verwenden, den er zu imitieren versucht. Darüber hinaus könnte ein schurkischer Client versuchen, die Softwarekennung oder Softwareversion eines legitimen Clients zu verwenden, um zu versuchen, sich auf dem Autorisierungsserver mit Instanzen des legitimen Clients zu assoziieren. Um dem entgegenzuwirken, MUSS ein Autorisierungsserver geeignete Schritte unternehmen, um dieses Risiko zu mindern, indem er die gesamte Registrierungsanfrage und Client-Konfiguration betrachtet. Beispielsweise könnte ein Autorisierungsserver eine Warnung ausgeben, wenn die Domäne/Website des Logos nicht mit der Domäne/Website der Umleitungs-URIs übereinstimmt. Ein Autorisierungsserver könnte auch Registrierungsanfragen von einer bekannten Softwarekennung ablehnen, die andere Umleitungs-URIs oder eine andere Client-URI anfordert. Ein Autorisierungsserver kann Endbenutzern auch in allen Fällen Warnmeldungen über dynamisch registrierte Clients anzeigen, insbesondere wenn solche Clients kürzlich registriert wurden oder von keinen Benutzern auf dem Autorisierungsserver zuvor vertraut wurden.

In einer Situation, in der der Autorisierungsserver eine offene Client-Registrierung unterstützt, muss er äußerst vorsichtig mit jeder vom Client bereitgestellten URL sein, die dem Benutzer angezeigt wird (z. B. "logo_uri", "tos_uri", "client_uri" und "policy_uri"). Beispielsweise könnte ein schurkischer Client eine Registrierungsanfrage mit einem Verweis auf einen Drive-by-Download in der "policy_uri" angeben, um den Benutzer dazu zu verleiten, während der Autorisierung darauf zu klicken. Der Autorisierungsserver SOLLTE prüfen, ob "logo_uri", "tos_uri", "client_uri" und "policy_uri" den gleichen Host und das gleiche Schema haben, wie die im Array von "redirect_uris" definierten, und dass alle diese URIs auf gültige Webseiten aufgelöst werden. Da diese URI-Werte, die dem Benutzer auf der Autorisierungsseite angezeigt werden sollen, SOLLTE der Autorisierungsserver den Benutzer nach Möglichkeit vor bösartigen Inhalten schützen, die unter den URLs gehostet werden. Bevor die URLs dem Benutzer auf der Autorisierungsseite präsentiert werden, könnte der Autorisierungsserver beispielsweise den unter den URLs gehosteten Inhalt herunterladen, den Inhalt gegen einen Malware-Scanner und Blacklist-Filter prüfen, feststellen, ob unter der URL gemischte sichere und nicht sichere Inhalte vorhanden sind oder nicht, und andere mögliche serverseitige Gegenmaßnahmen ergreifen. Beachten Sie, dass sich der Inhalt unter diesen URLs jederzeit ändern kann und der Autorisierungsserver kein vollständiges Vertrauen in die Sicherheit der URLs bieten kann, aber diese Praktiken könnten helfen. Um diese Art von Bedrohung weiter abzuschwächen, kann der Autorisierungsserver den Benutzer auch warnen, dass die URL-Links von einem Dritten bereitgestellt wurden, mit Vorsicht behandelt werden sollten und nicht vom Autorisierungsserver selbst gehostet werden. Anstatt die Links direkt in einem HTML-Anker bereitzustellen, kann der Autorisierungsserver den Benutzer beispielsweise auf eine zwischengeschaltete Warnseite leiten, bevor er dem Benutzer erlaubt, zur Ziel-URL fortzufahren.

Clients KÖNNEN sowohl das direkte JSON-Objekt als auch das JWT-codierte Software Statement verwenden, um dem Autorisierungsserver Client-Metadaten als Teil der Registrierungsanfrage zu präsentieren. Ein Software Statement ist kryptografisch geschützt und stellt Claims dar, die vom Aussteller des Statements gemacht wurden, während das JSON-Objekt die selbst zertifizierten Claims darstellt, die direkt vom Client oder Entwickler gemacht wurden. Wenn das Software Statement gültig und von einer akzeptablen Autorität (wie dem Software-API-Herausgeber) signiert ist, MÜSSEN die Werte der Client-Metadaten im Software Statement Vorrang vor den Metadatenwerten haben, die im einfachen JSON-Objekt präsentiert werden, die abgefangen und modifiziert worden sein könnten.

Wie alle Metadatenwerte ist das Software Statement ein Element, das vom Client selbst zertifiziert wird, auch wenn sein Inhalt vom Aussteller des Software Statements digital signiert oder mit einem MAC versehen wurde. Daher reicht die Vorlage des Software Statements in den meisten Fällen nicht aus, um eine Client-Software vollständig zu identifizieren. Ein initiales Zugriffstoken enthält im Gegensatz dazu nicht unbedingt Informationen über eine bestimmte Client-Software, sondern stellt stattdessen die Berechtigung zur Verwendung des Registrierungsendpunkts dar. Ein Autorisierungsserver MUSS die vollständige Registrierungsanfrage, einschließlich Software Statement, initialem Zugriffstoken und JSON-Client-Metadatenwerten, berücksichtigen, wenn er entscheidet, ob er einer bestimmten Registrierungsanfrage nachkommt.

Wenn ein Autorisierungsserver eine Registrierungsanfrage für einen Client erhält, der nicht dafür vorgesehen ist, mehrere Instanzen gleichzeitig registriert zu haben, und der Autorisierungsserver auf eine Duplizierung der Registrierung schließen kann (z. B. verwendet er dieselben "software_id"- und "software_version"-Werte wie ein anderer bestehender Client), SOLLTE der Server die neue Registrierung als verdächtig behandeln und die Registrierung ablehnen. Es ist möglich, dass der neue Client versucht, den bestehenden Client zu imitieren, um Benutzer dazu zu bringen, ihn zu autorisieren, oder dass die ursprüngliche Registrierung nicht mehr gültig ist. Die Details zur Verwaltung dieser Situation sind spezifisch für die Bereitstellung des Autorisierungsservers und liegen außerhalb des Geltungsbereichs dieser Spezifikation.

Da ein Client-Identifikator ein öffentlicher Wert ist, der verwendet werden kann, um einen Client am Autorisierungsendpunkt zu imitieren, muss ein Autorisierungsserver, der beschließt, denselben Client-Identifikator an mehrere Instanzen eines registrierten Clients auszugeben, sehr genau auf die Umstände achten, unter denen dies geschieht. Beispielsweise kann der Autorisierungsserver einen bestimmten Client-Identifikator auf Clients beschränken, die denselben auf Weiterleitung basierenden Ablauf und dieselben Umleitungs-URIs verwenden. Ein Autorisierungsserver SOLLTE NICHT dasselbe Client-Secret an mehrere Instanzen eines registrierten Clients ausgeben, selbst wenn ihnen derselbe Client-Identifikator ausgegeben wird, da sonst das Client-Secret durchsickern könnte, was es böswilligen Betrügern ermöglicht, einen vertraulichen Client zu imitieren.