Vérification MFA OIDC
De quoi s’agit-il
Lorsqu’un utilisateur se connecte à fremforge via l’IdP de votre organisation (Entra, Okta, Google Workspace, Authentik, Keycloak, …), l’IdP renvoie un jeton d’identité OIDC. Ce jeton contient une revendication amr (Authentication Methods References, RFC 8176) qui liste les facteurs d’authentification utilisés pour cette connexion, par exemple ["pwd","mfa"], ["fido"] ou ["otp"].
fremforge peut :
- Demander un contexte d’authentification précis à votre IdP au moment de la connexion, en envoyant le paramètre OIDC
acr_valuesdans la requête d’autorisation, et - Vérifier que la revendication
amrdu jeton d’identité renvoyé contient une valeur attestant la MFA avant de laisser la session démarrer.
Ensemble, ces deux mécanismes transforment « nous faisons confiance à votre IdP pour avoir fait la MFA » en « nous avons vérifié cryptographiquement que votre IdP a fait la MFA à chaque connexion, sans exception ».
Pourquoi cela remplace « Trust IdP MFA »
L’ancienne case Trust IdP MFA était une déclaration : l’opérateur confirmait que son IdP imposait la MFA, et fremforge sautait sa propre demande de MFA pour les utilisateurs de cette source. fremforge n’avait aucun moyen de vérifier cette déclaration : si la politique MFA de l’IdP était mal configurée ou temporairement assouplie, les utilisateurs se connectaient sans MFA et fremforge n’en savait jamais rien.
La nouvelle voie de vérification MFA OIDC examine la revendication amr de chaque jeton d’identité et refuse les connexions qui n’attestent pas de MFA. C’est la signature de l’IdP sur le jeton d’identité qui rend cela digne de confiance : une connexion qui arrive sur fremforge avec amr=["mfa"] prouve cryptographiquement que votre IdP a effectué la MFA pour cette session précise, et non que « la politique dit qu’il aurait dû ».
La case Trust IdP MFA a été supprimée. La vérification MFA OIDC est toujours active pour chaque source de connexion OIDC et ne peut pas être désactivée.
Configurer la vérification
- Depuis la page d’administration SSO de votre organisation (
<your-org>/_admin/sso), repérez la carte de la source d’authentification de l’IdP. - Dépliez le panneau Vérification MFA OIDC. La vérification est toujours active : il n’y a rien à cocher.
- Choisissez le Préréglage du fournisseur qui correspond à votre IdP. Le préréglage définit les
acr_valuesque nous enverrons à l’IdP lors de la connexion. - Enregistrez.
Une fois l’enregistrement effectué, l’exécution Forgejo modifiée commence à vérifier amr à chaque retour de cette source. La première connexion après la modification sert de test : vérifiez qu’elle réussit, puis déployez auprès du reste de l’organisation.
Préréglages des fournisseurs
| Fournisseur | Préréglage | acr_values envoyées | Ce que l’IdP doit avoir |
|---|---|---|---|
| Microsoft Entra ID | entra_c2 | c2 | Une politique d’accès conditionnel qui associe un contexte d’authentification à la MFA. Utilisateurs Apple/Mac : installez Microsoft Authenticator si vous n’avez pas encore de facteur enregistré. |
| Microsoft Entra ID | entra_c3 | c3 | Comme c2, avec en plus carte à puce ou certificat client. Pour les organisations réglementées (administration, banque). |
| Okta | okta_phr | phr | Une Authentication Policy imposant un facteur résistant au hameçonnage (FIDO2, WebAuthn). |
| Okta | okta_phrh | phrh | Comme phr, mais lié au matériel : YubiKey ou authentificateur de plateforme. L’ACR Okta le plus fort. |
| Google Workspace | google_mfa | urn:google:multi_factor | La validation en deux étapes imposée dans la console d’administration. |
| OIDC générique | vide | (aucune) | Vérifie seulement que amr contient une valeur de MFA. À utiliser lorsque votre IdP n’expose pas de configuration ACR mais émet bien la MFA dans amr. |
| Personnalisé | votre valeur | (ce que vous saisissez) | Tout ce qui n’est pas dans la liste : Keycloak, PingFederate, ForgeRock, Authelia, … |
Valeurs de MFA acceptées
Conformément à la RFC 8176 et aux extensions courantes des fournisseurs, les valeurs amr suivantes sont acceptées comme attestant la MFA :
mfa, otp, hwk, fido, sms, tel, mca, sc, otpasswd, swk, user, wia, pop, eye, iris, face, fpt, kba
Une connexion est acceptée lorsque le tableau amr contient au moins l’une de ces valeurs. Une connexion avec seulement amr=["pwd"] est refusée (mot de passe sans MFA).
Par ailleurs, lorsque vous avez configuré un préréglage de fournisseur, une connexion est également acceptée lorsque la revendication acr du jeton d’identité est exactement égale à la valeur du préréglage, par exemple acr=c2 sur Entra. C’est la voie qu’empruntent la plupart des configurations Entra et Okta, car ces fournisseurs renvoient généralement un acr plus riche que amr.
Tester la vérification
Un déploiement prudent : activez la vérification sur une seule source d’authentification (une organisation) et faites se connecter un utilisateur de test une fois. Si la connexion aboutit, vous avez vérifié que la chaîne de revendications de l’IdP correspond à ce que nous attendons. Si la connexion est refusée avec un message « MFA was not asserted », l’IdP a renvoyé quelque chose que nous n’avons pas reconnu. Causes fréquentes :
- Entra : la politique d’accès conditionnel n’est pas liée à l’application que représente cette source d’authentification. Vérifiez dans le portail Entra → Conditional Access → Policies que l’application est bien dans le périmètre.
- Okta : l’Authentication Policy de l’application OIDC est réglée sur « Any factor type allowed ». Restreignez-la à un facteur résistant au hameçonnage.
- Google Workspace : la validation en deux étapes est configurée utilisateur par utilisateur et non imposée à toute l’organisation. Réglez l’application de l’unité organisationnelle sur « On ».
L’entrée du journal d’audit d’une connexion refusée (action tenant.auth_policy.oidc_mfa.rejected) contient les valeurs exactes amr et acr renvoyées par l’IdP : copiez-les dans un ticket de support si vous avez besoin d’aide pour le diagnostic.
Piste d’audit
Chaque modification des paramètres de vérification MFA OIDC d’une source d’authentification émet un événement d’audit d’action sso.auth-source.oidc-mfa-config.update, avec les valeurs précédentes et nouvelles de acr_values et de require_oidc_amr_mfa, ainsi que l’auteur et l’horodatage.
Chaque connexion refusée parce que amr n’attestait pas de MFA émet tenant.auth_policy.oidc_mfa.rejected avec le nom de la source, l’adresse e-mail de l’utilisateur et les valeurs amr/acr renvoyées par l’IdP, pour que l’opérateur puisse diagnostiquer les erreurs de configuration avant qu’elles ne s’accumulent.
Voir aussi
- Politique d’authentification : des contrôles de posture plus larges (SSH désactivé, durée de vie maximale des PAT, commits signés, …).
- Configuration du SSO pas à pas : le raccordement initial d’une source d’authentification OIDC. Faites-le d’abord ; la vérification MFA OIDC est l’étape de durcissement une fois le raccordement de base fonctionnel.
- Ce que recouvre la MFA : la posture MFA globale de fremforge et la façon dont la MFA côté IdP interagit avec TOTP/WebAuthn côté Forgejo.