Une rangée de baies de serveurs noirs remplies de matériel informatique dans un centre de données.

Supabase permet à Claude d’émettre l’assertion d’identité pour l’entreprise

Supabase donne désormais la possibilité de mettre en place une authentification gérée par l’entreprise (enterprise-managed auth) pour son serveur MCP, même lorsque le fournisseur d’identité (identity provider, ou IdP) utilisé ne supporte pas l’extension d’autorisation MCP. En d’autres termes, Claude peut désormais générer l’assertion d’identité signée, une tâche qui relevait auparavant exclusivement de l’IdP.

Si l’on reprend le schéma habituel, chaque membre doit se connecter individuellement à Supabase et accorder son consentement à Claude via un écran. Ce processus, qui était nécessaire, notamment pour les entreprises utilisant des systèmes d’authentification spécifiques comme Okta, est en partie simplifié. L’annonce de Supabase indique que l’approbation initiale d’un administrateur suffit désormais pour que les membres utilisant l’authentification SSO de leur organisation puissent accéder à Supabase via Claude, sans avoir à passer par cet écran de consentement pour chaque connexion.

Cette évolution est significative. En effet, Supabase précise qu’au lancement, Okta était le seul IdP à supporter cette extension, et la plupart n’ont pas encore fait de même. En confiant cette fonction d’émetteur à Claude, Supabase élimine un point de blocage technique pour les organisations n’utilisant pas de plateformes compatibles avec cette extension. Cela n’altère en rien la configuration interne du fournisseur d’identité de l’entreprise.

Une rangée de serveurs informatiques bleus dans un centre de données moderne.

Comment fonctionne ce transfert de confiance

Lorsqu’un utilisateur se connecte à Claude, ce dernier doit fournir à Supabase une assertion signée à courte durée de vie, appelée ID-JAG (Identity Assertion JWT Authorization Grant). Lorsque Claude agit comme émetteur, il signe cette assertion lui-même. Avant de le faire, il vérifie deux points : si la personne est bien un membre de l’organisation Claude et quelle adresse e-mail elle utilise sur ce service.

L’assertion signée voyage ensuite vers Supabase. Le système effectue trois vérifications en aval : la signature correspond bien à l’émetteur enregistré, le membre fait partie de l’organisation SSO correspondante, et un administrateur a bien autorisé Claude. Si ces trois étapes sont franchies, Supabase délivre un jeton d’accès temporaire lié au membre. Lorsque ce jeton expire, Claude présente simplement une nouvelle assertion, et l’utilisateur n’a jamais besoin de se reconnecter manuellement.

Des changements dans la gestion du cycle de vie des membres

Le mécanisme de déconnexion des membres change également. Si un administrateur désactive un utilisateur dans l’IdP, cet accès ne sera plus coupé immédiatement, car ni Claude ni Supabase ne sollicitent l’état d’activité auprès de l’IdP. Pour supprimer un membre, il faut maintenant le retirer à la fois de l’organisation Supabase et de l’organisation Claude. Les jetons déjà émis conservent leur validité jusqu’à leur date d’expiration.

En revanche, Supabase ne peut tolérer qu’un seul émetteur par fournisseur SSO. L’URL de l’émetteur Claude remplace alors celle de l’IdP dans les paramètres SSO de Supabase. Une fois ce remplacement effectué, Supabase rejettera toutes les assertions signées par l’ancien IdP, y compris celles émises pour d’autres outils d’IA utilisant cette authentification gérée.

Ce besoin de coordination entre les systèmes soulève une question : comment les équipes de développement vont-elles gérer cette bascule d’émetteur sans impacter les intégrations existantes ? Pour les organisations qui n’utilisent pas encore cette fonctionnalité, le processus demande environ dix minutes de configuration, incluant la connexion de Claude à Supabase et l’enregistrement de l’URL d’émetteur unique dans les paramètres avancés de l’organisation Supabase.

Sources

Crédits photo