OAuth innerhalb eines VPN: Welche Abschnitte noch TLS erfordern

Private Weiterleitung entscheidet, wer den Server erreicht; die Transportregeln von OAuth entscheiden, wie jede Nachricht reist. Ein Browser, ein Autorisierungsserver, ein Token-Endpunkt und ein Ressourcenserver können alle hinter demselben VPN sitzen und trotzdem Nachrichten über verschiedene Abschnitte austauschen. Jeder Abschnitt hat seine eigene Transportanforderung, und das VPN lockert keine davon. Die VPN-Grenze und die Protokollgrenze sind zwei verschiedene Linien.

Die Entscheidung wird leichter, wenn Sie aufhören zu fragen, ob das Netz vertrauenswürdig ist, und anfangen zu fragen, welcher Austausch welche Grenze überquert.

Nach Abschnitt entscheiden, nicht nach Netz

Schreiben Sie die Endpunkte getrennt auf: Autorisierungsendpunkt, Token-Endpunkt, Weiterleitungs-URI, URL des Ressourcenservers, TLS-Endpunkt und VPN-Gateway. Markieren Sie dann, welche Partei jede Anfrage auslöst und wohin die Antwort geht.

Ein VPN, das an einem Gateway endet, verschlüsselt den Abschnitt bis zu diesem Gateway. Die Anfrage kann dahinter als einfaches HTTP weiterlaufen, und dieser verbleibende Abschnitt ist nicht HTTPS geworden, weil ein früherer Abschnitt verschlüsselt wurde. Genau diese Fortsetzung ist der Abschnitt, der das Protokoll interessiert. Den ersten Sprung zu verschlüsseln macht den zweiten Sprung nicht sicher.

Der Transport trägt auch eine Prüfung der Dienstidentität. Der Browser validiert das Zertifikat für die Anwendungs-URL; ein VPN führt diese Validierung nicht im Namen des Browsers durch und macht einen ungeprüften Endpunkt nicht akzeptabel. Das Zertifikat benennt den Endpunkt, den der Client zu rufen glaubt. Ein Tunnel zu einem Gateway benennt diesen Endpunkt nicht um und validiert ihn nicht.

Die Autorisierungsantwort und die Weiterleitungs-URI

Die aktuelle bewährte Sicherheitspraxis von OAuth verbietet die Übertragung von Autorisierungsantworten über unverschlüsselte Verbindungen. Das umfasst die Weiterleitung, die den Autorisierungscode oder Token zum Client zurückbringt, nicht nur die erste Anfrage.

Dieselbe Anleitung verbietet HTTP-Weiterleitungs-URIs, außer im genannten Loopback-Fall für native Clients. Ein interner Hostname schafft keine neue Ausnahme, und ein DNS-Name, der nur innerhalb des VPN aufgelöst wird, ist weiterhin eine HTTP-URL, wenn das Schema es sagt. Prüfen Sie das Schema in der registrierten URI, nicht nur den Hostnamen.

Registrieren Sie die genaue HTTPS-Weiterleitungs-URI beim Autorisierungsserver und lassen Sie die Zertifikatsprüfung im Client aktiviert. Eine Entwicklungshilfe, die die HTTPS-Anforderung unterdrückt, erzeugt einen Ablauf, der sich anders verhält als die Produktionskonfiguration, die er modellieren soll.

Der Token-Endpunkt und Anfragen mit Bearer-Token

Die Token-Anfrage trägt Anmeldedaten oder einen Code, der gegen Zugriff getauscht werden kann. Sie über einen ungeschützten Abschnitt zu senden legt Material offen, dem der Ressourcenserver später vertrauen wird, auch wenn das umgebende Netz privat ist. Ein Proxy, der die Anfrage lesen kann, kann auch die Anmeldedaten lesen, die sie trägt.

Für Ressourcenanfragen mit Bearer-Token behandelt RFC 6750 TLS als verbindlich zu implementieren und zu verwenden. Das Büro-Subnetz als vertrauenswürdig zu bezeichnen ist nicht die allgemeine Protokollausnahme, die eine Klartext-Bereitstellung mit Bearer-Token braucht.

Verwenden Sie die dokumentierten sicheren Endpunkt-URLs für beide Abschnitte. Wenn eine Bibliothek sich weigert, einen HTTP-Token-Endpunkt zu rufen, ist diese Weigerung die Spezifikation, die funktioniert, kein Konfigurationsfehler zum Umgehen. Tragen Sie diese URL in die Clientkonfiguration ein, statt sie zur Laufzeit abzuleiten.

Wo TLS endet und was das übrig lässt

Wenn TLS an einem autorisierten Frontend endet, benennen Sie dieses Frontend und prüfen Sie den Weg von dort zur Anwendung. Das Frontend wird für Weiterleitung, Vertrauen und Vertraulichkeit auf dem verbleibenden Abschnitt verantwortlich, und die unterstützte Architektur des Dienstes sollte diese Anordnung beschreiben.

Ein VPN an anderer Stelle im Pfad klärt diese Verantwortlichkeiten nicht. Es sagt Ihnen auch nicht, ob die Anwendungs-URL, die der Browser sieht, zum Zertifikat passt, das das Frontend vorzeigt.

Für eine interne Bereitstellung halten Sie den Endpunkt und die Identität fest, die er vorzeigt. Ein Frontend, das TLS mit einem Zertifikat für einen anderen Namen beendet, erzeugt eine Browserwarnung, die Betreiber oft unterdrücken, statt sie zu beheben.

Die Ausnahme für natives Loopback ist eng

Die Ausnahme für Loopback-Weiterleitung betrifft einen Rückruf auf dem eigenen Gerät des Nutzers, wo Client und Browser dieses Gerät teilen. Diese Anordnung gehört zu einem Rückruf auf einem Gerät und erlaubt es nicht, einen normalen Autorisierungsserver oder eine API mit Token über HTTP an ein Büro-Subnetz auszuliefern.

Halten Sie die Ausnahme auf den Clienttyp und den Rückruf begrenzt, den sie beschreibt. Sie auf eine Webanwendung, einen gemeinsam genutzten internen Dienst oder eine Weiterleitungs-URI auf einem anderen Host anzuwenden ändert die Bereitstellung, nicht die Ausnahme.

Testen Sie den tatsächlichen Ablauf an jeder Grenze und vergleichen Sie ihn mit dem Clienttyp. Eine funktionierende Weiterleitung sagt nichts darüber, ob jeder Abschnitt, der ein Token trug, den erforderlichen Schutz verwendet hat, und ein grünes VPN-Symbol sagt nichts über das Schema der nächsten Anfrage.