10.2. Request Source Authentication (Authentifizierung der Anfragequelle)

10.2. Request Source Authentication (Authentifizierung der Anfragequelle)

Die Quelle der Autorisierungsanfrage MUSS stets verifiziert werden. Dazu gibt es mehrere Wege:

(a) Prüfung der JWS-Signatur des Request Object.

(b) Prüfung, dass der symmetrische Schlüssel für die JWE-Verschlüsselung der richtige ist, wenn JWE symmetrische Verschlüsselung nutzt. Bei asymmetrischer Verschlüsselung mit öffentlichem Schlüssel gewährt die Verschlüsselung jedoch keine Quellenauthentifizierung, da jede Partei mit dem öffentlichen Schlüssel verschlüsseln kann.

(c) Prüfung der TLS-Serveridentität der Request-Object-URI. In diesem Fall MUSS der Autorisierungsserver außerbandwissen, dass der Client die Request-Object-URI verwendet und nur der Client durch das TLS-Zertifikat abgedeckt ist. Im Allgemeinen ist dies keine zuverlässige Methode.

(d) Implementiert der Autorisierungsserver einen Dienst, der eine Request-Object-URI gegen ein Request Object tauscht, MUSS er die Client-Authentifizierung durchführen, um das Request Object anzunehmen, und die Client-Kennung an die bereitgestellte Request-Object-URI binden. Er MUSS die Signatur gemäß (a) validieren. Da die Request-Object-URI wiederverwendet werden kann, MUSS die Lebensdauer der Request-Object-URI kurz und vorzugsweise einmalig sein. Die Entropie der Request-Object-URI MUSS ausreichend groß sein. Angemessene Kurzlebigkeit und Entropie hängen von der Risikobewertung ab dem Wert der geschützten Ressource ab. Als allgemeine Orientierung gilt eine Gültigkeit von weniger als einer Minute und eine kryptografisch zufällige Komponente von mindestens 128 Bit zum Zeitpunkt der Abfassung dieses Dokuments.

(e) Liefert ein vertrauenswürdiger Drittanbieter eine Request-Object-URI gegen ein Request Object, MUSS er die Signatur gemäß (a) validieren. Außerdem MUSS der Autorisierungsserver dem Drittanbieter vertrauen und außerbandwissen, dass der Client diesem ebenfalls vertraut ist.