OIDC-MFA-Prüfung

Worum es geht

Wenn sich ein Nutzer über den IdP deiner Organisation (Entra, Okta, Google Workspace, Authentik, Keycloak, …) bei fremforge anmeldet, gibt der IdP ein OIDC-ID-Token zurück. Dieses Token enthält einen amr-Claim (Authentication Methods References, RFC 8176), der die bei dieser Anmeldung verwendeten Faktoren aufführt, z. B. ["pwd","mfa"], ["fido"] oder ["otp"].

fremforge kann:

bei der Anmeldung einen bestimmten Authentifizierungskontext bei deinem IdP anfordern, indem es in der Autorisierungsanfrage den OIDC-Parameter acr_values mitsendet, und
prüfen, ob der amr-Claim des zurückgegebenen ID-Tokens einen MFA-bestätigenden Wert enthält, bevor die Sitzung beginnt.

Zusammen wird aus „wir vertrauen darauf, dass dein IdP MFA gemacht hat“ ein „wir haben kryptografisch geprüft, dass dein IdP bei genau diesem Schritt MFA gemacht hat, bei jedem Schritt“.

Warum das „Trust IdP MFA“ ersetzt

Die alte Checkbox Trust IdP MFA war eine Bestätigung: Der Operator bestätigt, dass sein IdP MFA erzwingt, und fremforge überspringt für Nutzer aus dieser Quelle die eigene MFA-Abfrage. fremforge hatte keine Möglichkeit, diese Bestätigung zu prüfen: War die MFA-Richtlinie des IdP falsch konfiguriert oder vorübergehend gelockert, meldeten sich Nutzer ohne MFA an, und fremforge erfuhr nie davon.

Der neue Weg der OIDC-MFA-Prüfung untersucht den amr-Claim jedes ID-Tokens und weist Anmeldungen ab, die keine MFA bestätigen. Die Signatur des IdP auf dem ID-Token macht das vertrauenswürdig: Eine Anmeldung, die mit amr=["mfa"] bei fremforge ankommt, beweist kryptografisch, dass dein IdP MFA für genau diese Sitzung durchgeführt hat, und nicht nur, dass „die Richtlinie es vorsah“.

Die Checkbox Trust IdP MFA wurde entfernt. Die OIDC-MFA-Prüfung ist für jede OIDC-Anmeldequelle immer eingeschaltet und lässt sich nicht ausschalten.

Die Prüfung einrichten

Suche auf der Admin-Seite SSO deiner Organisation (<your-org>/_admin/sso) die Karte der Auth-Quelle für den IdP.
Klappe das Panel OIDC-MFA-Prüfung auf. Die Prüfung ist immer eingeschaltet, es gibt also nichts anzuhaken.
Wähle ein Anbieter-Preset, das zu deinem IdP passt. Das Preset legt die acr_values fest, die wir dem IdP bei der Anmeldung senden.
Speichere.

Nach dem Speichern prüft die gepatchte Forgejo-Laufzeit bei jedem Callback aus dieser Quelle den amr. Die erste Anmeldung nach der Änderung ist der Kanarienvogel: Prüfe, dass sie gelingt, und rolle es dann auf den Rest der Organisation aus.

Anbieter-Presets

Anbieter	Preset	Gesendete `acr_values`	Was der IdP braucht
Microsoft Entra ID	`entra_c2`	`c2`	Eine Conditional-Access-Richtlinie, die einen Authentifizierungskontext MFA zuordnet. Apple-/Mac-Nutzer: Installiere Microsoft Authenticator, falls du noch keinen registrierten Faktor hast.
Microsoft Entra ID	`entra_c3`	`c3`	Wie `c2`, zusätzlich Smartcard / Client-Zertifikat. Für regulierte Mandanten (Behörden, Banken).
Okta	`okta_phr`	`phr`	Eine Authentication Policy, die einen phishing-resistenten Faktor erzwingt (FIDO2, WebAuthn).
Okta	`okta_phrh`	`phrh`	Wie `phr`, aber hardwaregebunden: YubiKey oder Plattform-Authenticator. Die stärkste ACR von Okta.
Google Workspace	`google_mfa`	`urn:google:multi_factor`	In der Admin-Konsole erzwungene Bestätigung in zwei Schritten.
Generisches OIDC	leer	(keine)	Nur prüfen, ob `amr` einen MFA-Wert enthält. Für IdPs, die keine ACR-Konfiguration bieten, aber MFA in `amr` ausgeben.
Benutzerdefiniert	dein Wert	(was du eingibst)	Alles, was nicht in der Liste steht: Keycloak, PingFederate, ForgeRock, Authelia, …

Welche MFA-Werte wir akzeptieren

Nach RFC 8176 und den gängigen Erweiterungen der Anbieter gelten folgende amr-Werte als MFA-bestätigend:

mfa, otp, hwk, fido, sms, tel, mca, sc, otpasswd, swk, user, wia, pop, eye, iris, face, fpt, kba

Eine Anmeldung wird akzeptiert, wenn das Array amr mindestens einen dieser Werte enthält. Eine Anmeldung nur mit amr=["pwd"] wird abgewiesen (Passwort ohne MFA).

Alternativ wird eine Anmeldung bei konfiguriertem Anbieter-Preset auch akzeptiert, wenn der acr-Claim des ID-Tokens genau dem Wert des Presets entspricht, z. B. acr=c2 bei Entra. Diesen Weg nutzen die meisten Entra-/Okta-Setups, weil die Anbieter meist einen aussagekräftigeren acr als amr zurückgeben.

Die Prüfung testen

Eine sichere Einführung: Schalte die Prüfung für eine Auth-Quelle (einen Mandanten) ein und lass einen Testnutzer sich einmal anmelden. Gelingt die Anmeldung, hast du bestätigt, dass die Claim-Kette des IdP unseren Erwartungen entspricht. Wird die Anmeldung mit dem Hinweis „MFA was not asserted“ abgewiesen, hat der IdP etwas zurückgegeben, das wir nicht erkannt haben. Häufige Ursachen:

Entra: Die Conditional-Access-Richtlinie ist nicht an die Anwendung gebunden, für die diese Auth-Quelle steht. Prüfe im Entra-Portal → Conditional Access → Policies, ob die App im Geltungsbereich ist.
Okta: Die Authentication Policy der OIDC-Anwendung steht auf „Any factor type allowed“. Verschärfe sie auf einen phishing-resistenten Faktor.
Google Workspace: Die Bestätigung in zwei Schritten ist pro Nutzer konfiguriert, aber nicht organisationsweit erzwungen. Setze die Erzwingung der Organisationseinheit auf „On“.

Der Eintrag im Audit-Log für eine abgewiesene Anmeldung (Aktion tenant.auth_policy.oidc_mfa.rejected) enthält die genauen amr- und acr-Werte, die der IdP zurückgegeben hat. Kopiere sie in ein Support-Ticket, wenn du Hilfe bei der Diagnose brauchst.

Audit-Trail

Jede Änderung der Einstellungen zur OIDC-MFA-Prüfung einer Auth-Quelle erzeugt ein Audit-Ereignis mit der Aktion sso.auth-source.oidc-mfa-config.update, mit dem vorherigen und dem neuen Wert von acr_values und require_oidc_amr_mfa sowie dem Akteur und dem Zeitstempel.

Jede Anmeldung, die abgewiesen wird, weil amr keine MFA bestätigte, erzeugt tenant.auth_policy.oidc_mfa.rejected mit dem Namen der Quelle, der E-Mail-Adresse des Akteurs und den vom IdP zurückgegebenen Werten amr/acr, damit der Operator Konfigurationsabweichungen diagnostizieren kann, bevor sie sich häufen.