Appendix B. Relationship to Token Binding (Verhältnis zu Token Binding)

Appendix B. Relationship to Token Binding (Verhältnis zu Token Binding)

OAuth-2.0-Token-Binding [TOKEN] erlaubt die Anwendung von Token Binding auf die verschiedenen in OAuth verwendeten Artefakte und Tokens. Dazu gehört die Bindung eines Zugriffstokens an einen Token-Binding-Key, der hinsichtlich Motivation und Entwurf gewisse Ähnlichkeit mit den in diesem Dokument definierten mutual-TLS-zertifikatsgebundenen Zugriffstoken aufweist. Beide Dokumente definieren einen oft als Besitznachweis (Proof-of-Possession) bezeichneten Sicherheitsmechanismus für Zugriffstoken, bei dem ein Client beim Zugriff auf eine geschützte Ressource den Besitz kryptografischen Schlüsselmaterials nachweisen muss. Die Details unterscheiden sich etwas; in beiden Fällen bindet der Autorisierungsserver das ausgegebene Zugriffstoken an ein asymmetrisches Schlüsselpaar des Clients. Der Client weist anschließend den Besitz des privaten Schlüssels dieses Paares gegenüber der TLS-Verbindung nach, über die auf die geschützte Ressource zugegriffen wird.

Token Binding nutzt auf dem Client erzeugte Rohschlüssel ohne Zertifikatsumhüllung und vermeidet viele der Schwierigkeiten bei Erstellung, Verteilung und Verwaltung der in dieser Spezifikation verwendeten Zertifikate. Zum Zeitpunkt der Abfassung ist Token Binding jedoch vergleichsweise neu, und die Unterstützung in verfügbaren Anwendungsentwicklungsplattformen und Werkzeugen ist gering. Solange die zugrunde liegenden Kernspezifikationen von Token Binding nicht besser unterstützt werden, sind praktische Implementierungen von OAuth-2.0-Token-Binding kaum realisierbar. Mutual TLS hingegen ist schon länger verbreitet und in Webservern sowie Entwicklungsplattformen weithin unterstützt. Folglich lassen sich OAuth-2.0-Mutual-TLS-Client-Authentifizierung und zertifikatsgebundene Zugriffstoken mit vorhandenen Plattformen und Werkzeugen bereits jetzt umsetzen und ausrollen. Zukünftig werden beide Spezifikationen vermutlich parallel eingesetzt, um ähnliche Probleme in unterschiedlichen Umgebungen zu lösen. Autorisierungsserver können sogar beide Spezifikationen gleichzeitig unterstützen und dabei für an verschiedene Clients ausgegebene Tokens unterschiedliche Besitznachweismechanismen (Proof-of-Possession) verwenden.