GitHub change enfin la plomberie OAuth des apps

GitHub a publié ces nouveautés dans son changelog du 14 août 2026. Le paquet contient trois évolutions : les apps OAuth peuvent demander des jetons d’accès expirants (des clés d’API temporaires) avec jetons de rafraîchissement (des clés servant à en redemander de nouvelles), elles peuvent enregistrer jusqu’à 10 URI de redirection (les URL de retour après connexion), et les GitHub Apps comme les OAuth apps peuvent activer ou désactiver un wildcard (un motif générique qui accepte plusieurs sous-domaines ou chemins) pour chaque URL de redirection. GitHub précise aussi que tout cela sera intégré à GitHub Enterprise Server 3.23. (github.blog)

Ce qui change dans le flux d’authentification

Le point le plus important côté sécurité est la rotation des jetons. Une app OAuth peut maintenant recevoir un access token valable 8 heures et un refresh token valable 6 mois sans usage. Quand le premier expire, l’application échange le second contre une nouvelle paire de jetons. Pour tester ce mode sans basculer toute l’application, GitHub recommande d’ajouter le scope offline_access (une permission spéciale qui active ce comportement) pendant la demande d’autorisation. Les nouvelles applications ont ce mode activé par défaut ; il reste possible de le désactiver temporairement si le kit logiciel d’authentification (SDK, bibliothèque cliente prête à l’emploi) ne sait pas encore gérer le rafraîchissement. Attention à un détail utile en migration : forcer les jetons courts n’expire pas les anciens jetons déjà émis ; pour passer un utilisateur sur le nouveau mode, il faut le faire se reconnecter. (github.blog)

Pourquoi les redirect URI multiples comptent vraiment

Jusqu’ici, multiplier les environnements pouvait pousser à créer plusieurs apps juste pour gérer localhost, la préproduction et la production. GitHub autorise désormais jusqu’à 10 callback URI (nom GitHub pour les URL de retour), avec un bouton dédié dans l’interface d’administration. Concrètement, une même app peut désormais couvrir plusieurs domaines ou configurations de déploiement sans dupliquer les enregistrements, les secrets et la documentation interne. Pour une équipe de développement, cela simplifie les intégrations d’IDE, les portails internes et les outils maison qui existent souvent en plusieurs variantes selon l’environnement. (github.blog)

Le vrai sujet de sécurité : le wildcard visible et contrôlable

La nouveauté la plus piégeuse est peut-être celle qui ressemble le moins à une nouveauté. GitHub indique que les apps avec une seule redirect URI avaient déjà le wildcard matching activé par héritage historique ; ce comportement est maintenant visible et désactivable. Avec ce mode, GitHub peut renvoyer le code d’autorisation vers toute URL qui correspond à un sous-domaine ou à un chemin supplémentaire dérivé de l’URI enregistrée. C’est pratique pour des sous-domaines par client, mais GitHub avertit explicitement que cela peut être abusé si le site cible ne contrôle pas strictement ses routes, par exemple s’il héberge du contenu utilisateur. En clair : si votre produit sert des pages générées par les utilisateurs sur le même sous-domaine que votre callback, il faut auditer ça rapidement. (github.blog)

« Apps with only one redirect URI have wildcard matching enabled. This is a legacy behavior of GitHub that is now visible and controllable. » (github.blog)

Ce que ça change concrètement pour une équipe qui utilise beaucoup l’IA

Si vous maintenez un assistant de code, un agent en ligne de commande (CLI, outil en terminal) ou une intégration qui agit au nom d’un utilisateur GitHub, il faut surtout revoir trois points :

• le stockage des jetons : prévoir access_token, refresh_token, expires_in et refresh_token_expires_in ;
• le renouvellement automatique : ne plus supposer qu’un jeton vit indéfiniment ;
• la liste des callback URI : documenter précisément quelles URL sont autorisées par environnement ;
• le wildcard : ne l’activer que si l’architecture impose vraiment des sous-domaines dynamiques ;
• la vérification d’identité après login : GitHub rappelle qu’il faut revalider l’utilisateur après chaque authentification pour éviter de mélanger des comptes. (docs.github.com)

Un squelette de configuration côté app web ressemble désormais davantage à ceci :

{
  "oauth": {
    "scopes": ["repo", "read:user", "offline_access"],
    "redirectUris": [
      "http://localhost:3000/auth/github/callback",
      "https://staging.example.com/auth/github/callback",
      "https://app.example.com/auth/github/callback"
    ],
    "usePkce": true,
    "rotateTokens": true
  }
}

Dernier point utile pour les développeurs : la documentation GitHub recommande fortement PKCE (Proof Key for Code Exchange, une protection contre l’interception du code OAuth) via code_challenge et code_verifier, ainsi qu’un paramètre state aléatoire contre les attaques de type cross-site request forgery (une requête malveillante déclenchée depuis un autre site). Autrement dit, la bonne pratique 2026 pour une intégration GitHub n’est plus seulement “ajouter OAuth”, mais “ajouter OAuth avec jetons courts, rafraîchissement, PKCE, callbacks bornés et wildcard sous contrôle”. Pour les équipes qui branchent de plus en plus d’agents IA sur GitHub, c’est moins une option qu’une remise à niveau de la base de sécurité. (docs.github.com)