Tokens und SAML

Die Karte eines JWT

Die Bilder zeigen das Access-Token der erfundenen App „Acme Orders“. Oben auf der Karte stehen Art, Aussteller, Empfänger und Benutzer, darunter die Token-Anatomie.

1. Vertrauenskette: Aussteller → Siegel mit Algorithmus und Schlüssel-ID → Für wen (Audience und berechtigter Client).
2. Der Ausweis: wer angemeldet ist, mit Scopes und Rollen.
3. Die Leiste zeigt, wie groß Header, Payload und Signatur sind. Die Signatur selbst ist bewusst verborgen – sie macht das Token erst verwendbar.
4. Die Claims in Gruppen – Wer, Aussteller & Empfänger, Zeit, Sicherheit, Zugriff – jeweils mit einer kurzen Erklärung. Zeiten stehen relativ zu jetzt.

Unter der Anatomie folgen die Prüfungen der Karte, die Felder und Dekodiert mit dem Rohinhalt. Werte wie Signaturen und Geheimnisse sind dort maskiert.

Signatur prüfen

Ohne Schlüssel zeigt das Siegel nur Signiert. Mit Schlüssel von … laden holt AuthTailor einmal die öffentlichen Schlüssel des Ausstellers (Discovery → jwks_uri). Nur dieser GET geht hinaus – nichts von deiner Eingabe.

1. Wie viele Schlüssel von welchem Host geladen sind. entfernen vergisst sie wieder.
2. Das Siegel: Signatur gültig, Signatur ungültig oder Schlüssel fehlt im JWKS – das letzte deutet oft auf einen Schlüsselwechsel.
3. Der Aussteller (iss).
4. Der Empfänger (aud) und der berechtigte Client (azp).

Steht das JWKS schon in der Eingabe – etwa in einem HAR –, prüft AuthTailor ohne Laden. Weitere Siegel: Unsigniert (alg none), Gemeinsames Secret (HMAC) und Verschlüsselt.

Gültigkeit

1. Der Countdown: läuft ab in …, abgelaufen vor … oder gültig in …, dazu die Lebensdauer.
2. Die Markierung für jetzt auf der Achse von ausgestellt (iat) über gültig ab (nbf) bis gültig bis (exp).

Die Uhr-Toleranz aus den erwarteten Werten gilt auch hier: Ein Token, das erst in 30 Sekunden gültig wird, ist bei 2 Minuten Toleranz in Ordnung. Bei einem Mitschnitt misst AuthTailor die Zeiten zum Zeitpunkt der Anfrage.

Ein SAML-Ablauf

Bei SAML zeigt der Ablauf den Weg vom AuthnRequest zum Identity Provider bis zur Response an die ACS-URL der App. Das Bild zeigt einen Mitschnitt des erfundenen „Acme Portal“ mit dem IdP idp.acme.example.

1. Das Urteil – hier Alles in Ordnung.
2. Schritt 1: Anmeldung anfordern (SAML AuthnRequest) per Redirect an den IdP.
3. Schritt 2: Assertion an die App (SAML Response) per POST an die ACS-URL.
4. Über den ganzen Ablauf – zum Beispiel Response gehört zum AuthnRequest: InResponseTo passt zur ID des Requests.

Die Karte einer SAML Response

1. Die Bindung, über die die Nachricht kam – hier HTTP-POST.
2. Die Vertrauenskette: Aussteller, Siegel mit Algorithmus und Zertifikat, Empfänger mit Recipient.
3. Der Ausweis mit NameID und Gruppen aus den Attributen.
4. Die Bausteine verschachtelt wie im XML: <Response>, <Status>, <Assertion> mit <Subject>, <Conditions>, <AuthnStatement> und <Attribute>. Ein Haken heißt: geprüft und in Ordnung; signierte Bausteine tragen ein Siegel.

AuthTailor prüft die Signatur kryptografisch mit dem Zertifikat aus der Nachricht, mit eigener XML-Kanonisierung (exklusiv und inklusiv). Es erkennt Angriffsmuster wie Signature Wrapping, doppelte IDs, Kommentare in der NameID, DTDs und Transforms. DTDs werden nie aufgelöst, Transforms nie ausgeführt.

Zertifikate

1. Das Zertifikat mit Name, selbstsigniert, Schlüsseltyp und -länge, Signaturalgorithmus, Inhaber und Ablaufdatum.
2. Der SHA-256-Fingerabdruck. Vergleiche ihn mit dem aus den Metadaten deines IdP – oder trag den in die erwarteten Werte ein, dann vergleicht AuthTailor selbst.

AuthTailor warnt auch vor Zertifikaten, die bald ablaufen.