1. Introduction (Einführung)

Das OAuth-2.0-Authorization-Framework [RFC6749] ermöglicht es Client-Anwendungen Dritter, delegierten Zugriff auf geschützte Ressourcen zu erhalten. Im typischen abstrakten OAuth-Ablauf (Abbildung 1) erhält der Client ein Access Token von einer als Authorization Server bezeichneten Entität und verwendet dieses Token beim Zugriff auf geschützte Ressourcen, etwa HTTPS-APIs.

  +--------+                                 +---------------+
  |        |                                 |               |
  |        |<--(A)-- Access-Token anfordern->| Authorization |
  |        |                                 |     Server    |
  |        |                                 |               |
  |        |                                 +---------------+
  |        |                                         ^
  |        |                                         |
  |        |
  |        |                               (C)       |
  | Client |                         Access-Token
  |        |                         validieren      |
  |        |
  |        |                                         |
  |        |                                         v
  |        |                                 +---------------+
  |        |                                 |      (C)      |
  |        |                                 |               |
  |        |<--(B)-- Access-Token verwenden ->|   Geschützte  |
  |        |                                 |   Ressource   |
  |        |                                 |               |
  +--------+                                 +---------------+

        Abbildung 1: Abstrakter OAuth-2.0-Protokollablauf

Der in Abbildung 1 dargestellte Ablauf umfasst folgende Schritte:

(A) Der Client sendet eine HTTPS-POST-Anfrage an den Authorization Server und legt ein die Authorization Grant repräsentierendes Credential vor. Für bestimmte Client-Typen (solche mit ausgegebenen oder anderweitig etablierten Client-Credentials) muss die Anfrage authentifiziert sein. In der Antwort stellt der Authorization Server dem Client ein Access Token aus.

(B) Der Client fügt das Access Token bei Anfragen zum Zugriff auf eine geschützte Ressource bei.

(C) Die geschützte Ressource validiert das Access Token, um die Anfrage zu autorisieren. In manchen Fällen, etwa wenn das Token selbstbeschreibend und kryptografisch geschützt ist, kann die Validierung lokal durch die geschützte Ressource erfolgen. In anderen Fällen muss die geschützte Ressource den Authorization Server aufrufen, um den Token-Status und Metainformationen zu ermitteln.

Aufbauend auf dem obigen abstrakten Ablauf standardisiert dieses Dokument erweiterte Sicherheitsoptionen für OAuth 2.0 unter Nutzung von clientzertifikatsbasierter Mutual TLS. Abschnitt 2 beschreibt Optionen zur Authentifizierung der Anfrage in Schritt (A). Schritt (C) wird durch Semantik zur Darstellung der Bindung des Tokens an das Clientzertifikat für lokale und entfernte Verarbeitung in den Abschnitten 3.1 bzw. 3.2 unterstützt. Damit ist – wie in Abschnitt 3 beschrieben – der Zugriff auf geschützte Ressourcen in Schritt (B) nur für den legitimen Client mit zertifikatsgebundenem Token und Besitz des zum Zertifikat gehörigen privaten Schlüssels möglich.

OAuth 2.0 definiert eine Shared-Secret-Methode der Client-Authentifizierung, erlaubt aber auch zusätzliche Mechanismen bei direkter Interaktion mit dem Authorization Server. Dieses Dokument beschreibt einen weiteren Mechanismus mittels Mutual-TLS-Zertifikatsauthentifizierung mit besseren Sicherheitseigenschaften als Shared Secrets. Während [RFC6749] die Client-Authentifizierung für Anfragen an den Token Endpoint dokumentiert, definieren Erweiterungen wie Introspection [RFC7662], Revocation [RFC7009] und der Backchannel-Authentication-Endpoint in [OpenID.CIBA] Endpunkte, die ebenfalls Client-Authentifizierung nutzen; die hier definierten Mutual-TLS-Methoden gelten auch dafür.

Mutual-TLS-zertifikatsgebundene Access Tokens stellen sicher, dass nur die Partei, die den zum Zertifikat gehörigen privaten Schlüssel besitzt, das Token zur Nutzung der zugehörigen Ressourcen einsetzen kann. Eine solche Einschränkung wird auch als Key Confirmation, Proof-of-Possession oder Holder-of-Key bezeichnet und unterscheidet sich vom Bearer Token in [RFC6750], bei dem jede Partei mit dem Access Token die Ressourcen nutzen kann. Die Bindung eines Access Tokens an das Clientzertifikat verhindert die Nutzung gestohlener Tokens oder unbefugtes erneutes Abspielen von Tokens.

Mutual-TLS-zertifikatsgebundene Access Tokens und Mutual-TLS-Client-Authentifizierung sind unterschiedliche, einander ergänzende Mechanismen und müssen nicht gemeinsam eingesetzt werden.

Dieses Dokument führt zusätzliche Client-Metadatenparameter für zertifikatsgebundene Access Tokens und Mutual-TLS-Client-Authentifizierung ein. Der Authorization Server kann Client-Metadaten über das Dynamic Client Registration Protocol [RFC7591] beziehen. Die von [RFC7591] definierten Metadaten und registrierten Erweiterungen implizieren zudem ein allgemeines Client-Datenmodell, das für Implementierungen nützlich ist, auch ohne dynamische Registrierung; solche Implementierungen verfügen typischerweise über eine Benutzeroberfläche zur Client-Konfiguration.

1. Introduction (Einführung)​

1. Introduction (Einführung)