1. Introduction (Einführung)
1. Introduction (Einführung)
Die Autorisierungsanfrage in OAuth 2.0 [RFC6749] nutzt die Serialisierung von Abfrageparametern und wird typischerweise über Benutzeragenten wie Webbrowser gesendet.
Beispielsweise werden die Parameter response_type, client_id, state und redirect_uri in der URI der Anfrage kodiert:
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
Zwar ist das einfach zu implementieren, doch die Kodierung in der URI erlaubt keine Anwendungssicherheit auf Protokollebene für Vertraulichkeit und Integrität. TLS schützt zwar die Kommunikation zwischen Client und Benutzeragent sowie zwischen Benutzeragent und Autorisierungsserver, aber TLS-Sitzungen enden im Benutzeragenten. Außerdem können TLS-Sitzungen vorzeitig an einer Zwischenstelle (z. B. einem Load Balancer) beendet werden.
Daher weist die Autorisierungsanfrage von [RFC6749] folgende Mängel auf:
(a) Die Kommunikation über die Benutzeragenten ist nicht integritätsgeschützt; die Parameter können manipuliert werden (Integritätsverlust).
(b) Die Quelle der Kommunikation ist nicht authentifiziert (Quellenauthentifizierungsverlust).
(c) Die Kommunikation über die Benutzeragenten kann überwacht werden (Vertraulichkeits-/Eindämmungsverlust).
Aufgrund dieser inhärenten Schwächen wurden mehrere Angriffe auf das Protokoll identifiziert, etwa das Umschreiben der Redirect-URI.
Der Einsatz von Sicherheit auf Anwendungsebene mildert diese Probleme.
Er erlaubt es, Anfragen von einer vertrauenswürdigen dritten Partei vorzubereiten, sodass eine Client-Anwendung nicht mehr Berechtigungen anfordern kann, als zuvor vereinbart.
Außerdem kann die Übermittlung per Referenz den Übertragungsaufwand verringern.
Die Kodierung als JWT [RFC7519] wurde gewählt wegen:
(1) der engen Beziehung zu JSON, dem Antwortformat von OAuth,
(2) der Entwicklerfreundlichkeit durch den textuellen Charakter,
(3) der relativen Kompaktheit gegenüber XML,
(4) des Status als Proposed Standard samt zugehöriger Signatur- und Verschlüsselungsverfahren [RFC7515] [RFC7516],
(5) der relativen Einfachheit von JWS und JWE gegenüber XML Signature und Encryption.
Die Parameter request und request_uri werden als zusätzliche Autorisierungsanfrageparameter für die OAuth-2.0-[RFC6749]-Flows eingeführt. Der Parameter request ist ein JSON Web Token (JWT) [RFC7519], dessen JWT Claims Set die JSON-kodierten OAuth-2.0-Autorisierungsanfrageparameter enthält. Im Gegensatz zu RFC 7519 sind die Elemente des Claims Set kodierte OAuth-Anfrageparameter [IANA.OAuth.Parameters], ergänzt nur um wenige von der IANA verwaltete JSON-Web-Token-Claims [IANA.JWT.Claims], insbesondere iss und aud. Das JWT im Parameter request ist mit JWS integritätsgeschützt und quellenauthentifiziert.
Das JWT [RFC7519] kann per Referenz an den Autorisierungs-Endpunkt übergeben werden; dann wird statt request der Parameter request_uri verwendet.
JWT [RFC7519] statt Abfrageparameter als Kodierung der Anfrage hat mehrere Vorteile:
(a) Integritätsschutz. Die Anfrage kann signiert werden, sodass die Integrität geprüft werden kann.
(b) Quellenauthentifizierung. Die Anfrage kann signiert werden, sodass der Signierende authentifiziert werden kann.
(c) Vertraulichkeitsschutz. Die Anfrage kann verschlüsselt werden, sodass Ende-zu-Ende-Vertraulichkeit besteht, selbst wenn die TLS-Verbindung an einer Stelle (einschließlich bei oder vor Benutzeragenten) endet.
(d) Datensparsamkeit. Die Anfrage kann von einer vertrauenswürdigen dritten Partei signiert werden, die bestätigt, dass die Autorisierungsanfrage einer bestimmten Richtlinie entspricht. Beispielsweise kann eine Anfrage von einer vertrauenswürdigen dritten Partei vorab geprüft werden, ob alle angeforderten personenbezogenen Daten für den vom Endbenutzer gewünschten Vorgang unbedingt erforderlich sind; die Anfrage wird dann von dieser Partei signiert. Der Autorisierungsserver prüft die Signatur und zeigt den Konformitätsstatus dem Endbenutzer, der bei der Autorisierung eine gewisse Sicherheit über die Legitimität der Anfrage hat. In manchen Fällen kann unter solchen Umständen sogar auf den Autorisierungsdialog verzichtet werden.
Es gibt einige Fälle, in denen die Anfrage per Referenz nützlich ist, etwa:
-
wenn die Größe der übertragenen Anfrage verringert werden soll. Sicherheit auf Anwendungsebene vergrößert die Anfrage, insbesondere bei asymmetrischer Kryptografie.
-
wenn der Client keine Kryptografie auf Anwendungsebene ausführen möchte. Der Autorisierungsserver kann einen Endpunkt bereitstellen, der die Autorisierungsanfrage über direkte Kommunikation mit dem Client annimmt, sodass der Client authentifiziert ist und der Kanal TLS-geschützt ist.
Diese Fähigkeit wird von OpenID Connect [OpenID.Core] genutzt.