Pourquoi me demande-t-on de confirmer mon identité quand je me connecte avec Git Credential Manager, tea ou la CLI ?

Quand une application comme Git Credential Manager ouvre votre navigateur pour vous connecter à frem.sh, frem.sh peut d’abord afficher une page Confirmez votre identité. Confirmez avec votre clé d’accès ou votre clé de sécurité, avec un code de votre application d’authentification, ou en vous reconnectant auprès du fournisseur d’identité de votre organisation : le navigateur revient aussitôt et termine la connexion. Il n’y a pas de second clic pour autoriser l’application.

Cette question vous est posée environ une fois par mois sur chaque appareil, quand une application se connecte à nouveau. Une application qui renouvelle sa connexion en arrière-plan n’est jamais concernée.

Ce qui se passe

1. Une application sur votre ordinateur ouvre votre navigateur sur frem.sh pour vous connecter, par exemple lors de votre premier git push avec Git Credential Manager, ou quand vous lancez fremforge auth login.
2. Si vous n’avez pas confirmé votre identité au cours des 5 dernières minutes, frem.sh affiche Confirmez votre identité. La page nomme l’application et indique où elle s’exécute (pour une application qui ne s’exécute pas sur votre propre ordinateur, « Elle s’exécute sur » suivi de son hôte). Elle affiche « Ne continuez que si vous avez lancé cette connexion vous-même. » et renvoie vers cette page (« Pourquoi cette question ? »).
3. Vous confirmez (voir Comment confirmer).
4. Le navigateur revient à l’application et la connexion se termine. Vous ne cliquez pas une seconde fois sur Authorize.

Une confirmation vaut au plus 5 minutes et est consommée par cette seule connexion. Si une deuxième application se connecte à nouveau une minute plus tard, vous confirmez une nouvelle fois.

Est-ce bien l’application que j’ai lancée ?

frem.sh n’affiche simplement le nom d’une application que s’il lui fait confiance d’après son identifiant client : Git Credential Manager, git-credential-oauth et tea (intégrés à Forgejo), ainsi que la CLI fremforge et le connecteur MCP de fremforge. Toute autre application est affichée avec son nom entre guillemets et son propriétaire, par exemple :

« Example App », enregistrée par example-owner, veut se connecter à votre compte. Confirmez votre identité pour continuer.

Si le nom est entre guillemets avec « enregistrée par », il s’agit d’une application tierce. Vérifiez que vous avez bien lancé cette connexion vous-même, depuis cette application. Sinon, ne continuez pas : fermez la page. Quelqu’un essaie peut-être d’obtenir un jeton pour votre compte au moyen d’une application qu’il a enregistrée. Prévenez l’administrateur de votre organisation ou security@frem.sh.

Pourquoi frem.sh pose la question

Ces applications se connectent sans secret client. Un programme installé sur des millions d’ordinateurs portables ne peut pas garder un secret : la norme OAuth l’appelle donc un client public. Cela a une conséquence : frem.sh ne peut pas distinguer le vrai Git Credential Manager de n’importe quel autre programme qui, sur un ordinateur, prétend l’être.

Si quelqu’un avait volé votre session de navigateur (un cookie de session, par exemple au moyen d’un logiciel malveillant ou d’un ordinateur partagé), il pourrait donc lancer un petit programme à lui, se faire passer pour Git Credential Manager ou la CLI fremforge, et obtenir un jeton pour votre compte sans jamais connaître votre mot de passe ni votre second facteur.

Confirmer votre identité comble cette faille. Une session volée ne suffit plus à obtenir un jeton : la personne doit être présente avec sa clé d’accès, sa clé de sécurité, son application d’authentification, son mot de passe ou son fournisseur d’identité. C’est la même idée que le « sudo mode » de GitHub, qui vous demande de vous authentifier à nouveau avant une action sensible.

Quelles applications

Toute application qui se connecte à frem.sh sans secret client, notamment :

• Git Credential Manager (GCM), configuré comme dans Connexion sécurisée
• git-credential-oauth
• tea, le client en ligne de commande pour Forgejo et Gitea
• la CLI fremforge : fremforge auth login, aussi bien la connexion dans le navigateur (loopback) que la connexion par code d’appareil. Voir Authentification de la CLI.
• les connecteurs d’assistants IA qui se connectent à frem.sh en votre nom, voir MCP
• toute application OAuth tierce enregistrée comme client public

Les applications dotées d’un secret client ne changent pas. Une application OAuth qui s’exécute sur un serveur et s’authentifie avec un secret client (un client confidentiel) vous connecte comme avant, avec l’écran de consentement habituel.

À quelle fréquence

Environ une fois par mois sur chaque appareil. Vous confirmez quand une application se connecte à nouveau, pas chaque fois que vous utilisez git :

• Une application qui renouvelle sa connexion en arrière-plan n’est jamais concernée. Le jeton d’accès de Git Credential Manager dure 24 heures et son jeton de rafraîchissement 30 jours. Pendant ces 30 jours, GCM renouvelle le jeton sans interaction lors de votre prochain push ou fetch.
• Les jetons d’une heure de la CLI fremforge se renouvellent sans interaction de la même façon.
• Utiliser une connexion qu’une application possède déjà ne déclenche jamais la question. Les push, les fetch et les appels de la CLI et des connecteurs avec une connexion existante passent comme avant.

La question vous est posée quand une application ouvre le navigateur pour se connecter à nouveau, ce qui arrive :

• lors de la première connexion sur un nouvel appareil, par exemple un nouveau portable ou une nouvelle installation WSL
• après une déconnexion, ou après que vous avez retiré l’accès de l’application sous Applications OAuth2 autorisées sur frem.sh/user/settings/applications
• après 30 jours sans utilisation, quand le jeton de rafraîchissement a expiré

Comment confirmer

Authentification unique : un clic, une connexion fraîche. frem.sh demande à votre fournisseur d’identité une connexion fraîche et ne la retient que si le fournisseur vous a réellement connecté à l’instant : une personne qui détient une session frem.sh volée en est incapable. Vous n’avez besoin ni d’une clé d’accès ni d’un second facteur sur frem.sh pour Git Credential Manager, tea ou la CLI. Si votre organisation exige un second facteur chez le fournisseur d’identité, vous le validez là-bas comme d’habitude.

Si vous annulez chez votre fournisseur d’identité, ou s’il ne vous a pas demandé de vous reconnecter (il a réutilisé une connexion antérieure), vous revenez à la page Confirmez votre identité, qui vous le signale et vous permet de réessayer.

Avec un mot de passe mais sans second facteur, la page affiche aussi : « Configurez l’authentification à deux facteurs pour confirmer la prochaine fois avec un code ou une clé de sécurité. » Avec l’authentification unique seule, elle affiche : « Configurer une clé d’accès ou un autre second facteur, pour confirmer ici la prochaine fois. » C’est facultatif : vous reconnecter auprès de votre fournisseur d’identité suffit.

Vous avez 5 tentatives en 15 minutes. Ensuite, la page vous demande de réessayer dans 15 minutes.

Je n’ai pas de second facteur

• Vous avez un mot de passe frem.sh : confirmez avec votre mot de passe. Puis configurez une clé d’accès ou l’authentification à deux facteurs, pour confirmer avec ce facteur la prochaine fois. Tant que vous n’avez pas confirmé une fois avec ce nouveau facteur, la page continue de proposer votre mot de passe à côté de lui.
• Vous vous connectez uniquement par l’authentification unique de votre organisation : cliquez sur Se reconnecter avec … pour votre fournisseur d’identité. C’est tout.
• Vous n’avez rien de tout cela : la page vous invite à contacter l’administrateur de votre organisation ou support@frem.sh. Nous vous aidons à configurer un second facteur.

Dépannage

• La connexion a échoué après ma confirmation. La confirmation est consommée par une seule connexion et dure 5 minutes. Si l’application a expiré entre-temps, relancez la commande (par exemple git fetch) et confirmez une nouvelle fois.
• « … ne vous a pas demandé de vous reconnecter, cela n’a donc pas pu confirmer que c’est vous. » Votre fournisseur d’identité a réutilisé une connexion antérieure au lieu de vous redemander. Réessayez. Si cela se reproduit, prévenez votre administrateur : le fournisseur ignore la demande de connexion fraîche de frem.sh.
• « Votre organisation exige un second facteur chez … et aucun n’a été confirmé. » Le fournisseur d’identité de votre organisation est configuré pour exiger un second facteur et n’en a signalé aucun. Reconnectez-vous et terminez là-bas l’étape du second facteur.
• « Vous avez configuré cette clé d’accès ou ce code dans cette session : ils ne peuvent donc pas confirmer ici la connexion d’une application. » Un facteur que vous venez d’ajouter ne peut confirmer la connexion d’une application qu’après que vous avez confirmé votre identité une fois d’une autre manière : ainsi, une personne disposant d’une session volée ne peut pas ajouter une clé d’accès puis s’en servir. Inutile d’attendre : utilisez une fois un facteur que vous aviez déjà, votre mot de passe, ou Se reconnecter avec … pour votre fournisseur d’identité. Ensuite, la nouvelle clé d’accès fonctionne normalement, sur tous vos appareils.
• On me pose la question tous les jours. Vérifiez que Git Credential Manager peut stocker son jeton : voir le réglage credential.credentialStore à l’étape 4 de Connexion sécurisée. Sans stockage fonctionnel, GCM n’a pas de jeton de rafraîchissement à réutiliser et se reconnecte chaque fois.
• Un script ou une tâche CI ne fonctionne plus. Les tâches sans surveillance ne doivent pas utiliser une connexion interactive. Utilisez un jeton d’accès personnel ou Forgejo Actions OIDC, qui ne sont pas concernés.