OIDC Authorization Code Flow einfach erklärt – Warum ist er sicherer als SAML

In diesem Artikel wollen wir den OIDC Authorization Code Flow genauer unter die Lupe nehmen. Was macht ihn so besonders? Wie unterscheidet er sich von SAML? Und warum sollte man ihn bevorzugen? Statt nur den Ablauf zu beschreiben, wollen wir vor allem das „Warum“ dahinter verstehen. Also, los geht’s!

SAML-Authentifizierung: Wo liegt das Problem?

Betrachten wir zunächst die Authentifizierung mit SAML: Eine Anwendung möchte einen Nutzer authentifizieren und leitet ihn dazu an den Identity Provider (IDP) weiter. Der IDP überprüft die Identität des Nutzers, legt fest, wie er sich authentifiziert hat (z. B. per 2FA), und ergänzt Benutzerattribute wie Name, E-Mail oder Rollen. Anschließend sendet der IDP eine Nachricht mit diesen Informationen zurück an die Anwendung.

Das klingt zunächst unproblematisch. Doch hier kommt das Sicherheitsproblem ins Spiel: SAML nutzt den sogenannten Frontend-Channel, das bedeutet, dass die gesamte Kommunikation zwischen der Anwendung und dem IDP über den Browser des Nutzers läuft.

Der Frontend-Channel ist problematisch, weil die Nutzerumgebung schwer zu kontrollieren ist. Sie stellt das unsicherste Glied in der Kommunikationskette dar. Ein Angreifer könnte die SAML-Response auf dem Gerät des Nutzers abfangen und missbrauchen.

Aber wäre es nicht sicherer, wenn die Anwendung den Authentifizierungsnachweis direkt beim IDP über den Backend-Channel abrufen könnte? Diese Verbindung ließe sich viel besser absichern, denn statt mit einer unbekannten Anzahl an Nutzergeräten zu kommunizieren, würde die Anwendung nur noch direkt mit dem IDP sprechen. Genau das ist die Idee hinter dem OIDC Authorization Code Flow.

Die Lösung: OIDC Authorization Code Flow

Beim OIDC Authorization Code Flow ruft die Anwendung den Authentifizierungsnachweis direkt beim IDP über den Backend-Channel ab. Das bedeutet: Statt den Authentifizierungsnachweis über den unsicheren Frontend-Channel zu transportieren, erfolgt die entscheidende Kommunikation zwischen Anwendung und IDP über eine direkte Server-zu-Server-Verbindung.

Aber Moment: Wie soll die Anwendung den Authentifizierungsstatus eines Nutzers abfragen, wenn sie ihn noch gar nicht kennt? Schließlich ist er ja noch nicht authentifiziert.

Die Lösung: Der Nutzer benötigt eine Art Beleg, der bestätigt, dass er sich erfolgreich am IDP angemeldet hat – ohne dabei direkt den Authentifizierungsnachweis über den unsicheren Frontend-Channel zu übertragen. Und genau hier kommt der Code ins Spiel, der diesem Flow seinen Namen gibt.

Der Ablauf sieht folgendermaßen aus:

• Der Nutzer wird von der Anwendung zum IDP weitergeleitet und dort authentifiziert.
• Statt eines Authentifizierungsnachweises gibt der IDP dem Nutzer nur einen Code mit.
• Diesen Code übermittelt der Nutzer an die Anwendung über den Frontend-Channel.
• Die Anwendung tauscht diesen Code beim IDP über den Backend-Channel gegen ein Authentifizierungstoken ein.

Das Entscheidende hierbei: Um den Code gegen das Token einzulösen, muss sich die Anwendung gegenüber dem IDP authentifizieren – und das kann nur sie selbst, da sie eine Vertrauensstellung mit dem IDP hat.

Warum ist das sicherer?

Der große Vorteil dieses Verfahrens: Der Authentifizierungsnachweis wird nicht über den unsicheren Frontend-Channel übertragen, sondern nur über den sicheren Backend-Channel abgerufen.

Selbst wenn ein Angreifer den Code im Frontend-Channel abfängt, kann er damit nichts anfangen, da der eigentliche Authentifizierungsnachweis nur von der autorisierten Anwendung über den Backend-Channel abgerufen werden kann.

So löst der OIDC Authorization Code Flow das Sicherheitsproblem von SAML – und genau das macht ihn zu einer besseren Wahl.