OAuth zero-touch pour MCP

 (blog.modelcontextprotocol.io)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • L’extension Enterprise-Managed Authorization (EMA) est désormais stabilisée, permettant aux entreprises de gérer de façon centralisée les autorisations des serveurs MCP et aux utilisateurs d’accéder aux serveurs autorisés après une seule connexion
  • L’approche précédente reposait sur des approbations OAuth individuelles par utilisateur et par serveur, ce qui compliquait l’onboarding, l’application des politiques de sécurité, la traçabilité d’audit et la séparation entre comptes professionnels et personnels
  • EMA place l’IdP de l’organisation comme autorité de décision pour les autorisations, et dès qu’un administrateur définit une politique une fois, les utilisateurs héritent des connexions MCP nécessaires via leur compte d’entreprise existant
  • Le ID-JAG émis pendant le SSO est échangé contre un jeton d’accès par le serveur d’autorisation du serveur MCP, ce qui évite toute redirection des utilisateurs vers un écran de consentement propre à chaque serveur
  • Okta, Anthropic, Visual Studio Code ainsi qu’Asana, Atlassian, Canva, Figma, Granola, Linear et Supabase font partie des premiers acteurs compatibles, et Slack est aussi en train d’ajouter la prise en charge

Stabilisation d’EMA et objectif de déploiement en entreprise

  • L’extension Enterprise-Managed Authorization (EMA) est désormais au statut stable
  • Dans les environnements d’entreprise, les validations répétées et les invites de consentement étaient considérées comme une forte contrainte lors de la gestion des connexions aux serveurs MCP, et EMA est une extension conçue pour réduire ce problème
  • Les organisations peuvent contrôler de façon centralisée l’accès aux serveurs MCP via leur fournisseur d’identité (IdP) de confiance
  • Les utilisateurs finaux se connectent avec leur compte d’entreprise existant puis se relient aux serveurs MCP autorisés, avec moins de consentements OAuth par serveur et moins de configuration ponctuelle

Les limites du modèle d’authentification par utilisateur

  • Le modèle d’autorisation standard de MCP est conçu autour d’un périmètre user-scoped et des conventions traditionnelles d’authentification interactive
  • Il peut convenir à des scénarios grand public où chacun décide directement à quelles données il donne accès, mais il passe mal à l’échelle dans les déploiements en entreprise
  • En environnement d’entreprise, trois problèmes prennent particulièrement de l’ampleur
    • Chaque employé doit approuver les serveurs séparément, ce qui impose des connexions manuelles service par service lors de l’onboarding
    • Les équipes sécurité dépendent d’accès approuvés individuellement par chaque utilisateur, sans contrôle central ni traçabilité d’audit
    • Il est difficile d’imposer l’usage des comptes d’entreprise, ce qui permet aux utilisateurs de connecter des comptes personnels à des outils de travail
  • Ces frictions ralentissent l’adoption de MCP et augmentent le risque de contournements fragiles
  • En l’absence d’un standard générique pour préserver un état d’authentification partagé, chaque implémenteur finit par créer sa propre solution, et même lorsque les données et outils existent, ils peuvent rester majoritairement désactivés à cause du coût d’autorisation par utilisateur

Une seule approbation, héritée partout

  • Enterprise-Managed Authorization fait de l’IdP de l’organisation l’autorité décisionnelle pour l’accès aux serveurs MCP
  • L’administrateur définit la politique une fois, et les utilisateurs s’authentifient auprès de l’hôte MCP avec leur identité d’entreprise existante
  • L’IdP peut autoriser ou refuser l’accès selon l’appartenance à des groupes, les rôles et les règles d’accès conditionnel
  • Le flux interne fonctionne ainsi
    • Le client obtient auprès de l’IdP un Identity Assertion JWT Authorization Grant (ID-JAG) pendant le SSO
    • Le client l’envoie ensuite au serveur d’autorisation du serveur MCP pour l’échanger contre un jeton d’accès
    • L’utilisateur ne passe par aucun écran de consentement propre au serveur
  • Cette architecture apporte trois effets majeurs
    • Une fois qu’un administrateur active un serveur pour l’organisation, les utilisateurs y accèdent automatiquement dans les limites de leurs groupes et rôles existants
    • Les décisions d’accès sont consignées dans la console d’administration de l’IdP, fournissant une trace d’audit unique pour l’ensemble des connecteurs
    • La suppression de l’étape interactive de sélection de compte facilite la réduction des confusions de flux de données entre comptes personnels et comptes d’entreprise
  • Pour l’usage de MCP en entreprise, l’objectif est que, lorsqu’un utilisateur se connecte, le client puisse se relier aux outils et données autorisés sans étape supplémentaire

Produits pris en charge au lancement et écosystème

  • Cette sortie réunit des implémentations dans trois catégories : fournisseurs d’identité, clients et serveurs

  • Fournisseurs d’identité

    • Okta est le premier fournisseur d’identité compatible
    • Les organisations utilisant Okta peuvent provisionner l’accès MCP vers des clients et serveurs compatibles via Okta’s Cross App Access (XAA)

  • Clients

    • Anthropic implémente EMA dans la couche MCP partagée de Claude
    • Les administrateurs peuvent approuver des serveurs MCP pour les utilisateurs dans Claude, Claude Code et Cowork
    • Visual Studio Code ajoute également la prise en charge d’EMA dans l’IDE

  • Serveurs

    • Asana, Atlassian, Canva, Figma, Granola, Linear et Supabase prennent en charge EMA
    • Slack et d’autres serveurs sont également en train d’ajouter cette prise en charge
    • Aaron Parecki d’Okta explique que l’intégration du protocole Cross App Access dans l’extension EMA de MCP transforme l’identity en plan de gouvernance central, apportant aux équipes sécurité des contrôles de conformité et aux utilisateurs une expérience fluide
    • Devdatta Akhawe de Figma affirme qu’avec l’augmentation de l’adoption de MCP, XAA facilite la montée en charge sécurisée des déploiements MCP en entreprise
    • Tom Moor de Linear évoque une expérience où une seule connexion configure automatiquement tous les connecteurs MCP

Documentation et canaux de participation

  • Les clients, serveurs et plateformes d’identity peuvent examiner la spécification de l’extension et ajouter à leurs produits la prise en charge du nouveau standard
  • La page Enterprise-Managed Authorization documente les exigences de flux pour les clients, les serveurs et les serveurs d’autorisation
  • Le dépôt ext-auth et la spécification brouillon permettent de suivre les derniers changements d’EMA et les ressources associées
  • L’EMA Interest Group sert aux discussions sur l’extension, aux rapports de compatibilité et aux améliorations itératives
  • EMA est un travail de la communauté MCP, auquel contribuent les auteurs de SEP-990, les mainteneurs du dépôt ext-auth, ainsi que des fournisseurs d’identity et de MCP ayant testé les premières implémentations et fait progresser la spécification

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Hacker News

  • Avant de repartir dans l’éternel débat « MCP est mort et Skills est l’avenir », le vrai intérêt de MCP par rapport aux skills/CLI, c’est qu’il sort le flux d’authentification de la fenêtre de contexte de l’agent, et parfois même en dehors du harnais d’exécution
    C’est évidemment important du point de vue de la sécurité, et cela rend aussi l’expérience bien plus simple pour les utilisateurs ordinaires ou les grandes entreprises qui adoptent des outils d’IA
    Je comprends les plaintes sur le gonflement du contexte ou la redondance des appels d’outils, mais cette façon de gérer l’authentification a une valeur évidente
    Un MCP idéal pourrait déjà être très utile rien qu’en servant de passerelle d’authentification devant une API

    • Cette extension montre aussi bien un autre avantage de MCP par rapport aux skills : le contrôle centralisé, la facilité d’usage pour les employés, l’audit/la conformité, et le modèle de déploiement
      Aujourd’hui, le mieux qu’on ait pour déployer des skills ressemble à « copiez ce fichier et mettez-le ici », « clonez ce dépôt et ajoutez un lien symbolique », ou « installez via une commande slash »
      C’est simple, certes, mais pas aussi facile que cette méthode d’extension pour déployer un nouveau serveur MCP auprès des employés
    • MCP permet aussi une excellente piste d’audit
      Par exemple, on peut authentifier 6 comptes Linear appartenant à 6 clients différents, puis sélectionner quel compte utiliser d’une manière déterministe et auditable, ce qui permet aussi une séparation des responsabilités
    • La vraie leçon, c’est que MCP contre skills n’est pas une opposition binaire
      Ce sont simplement des outils différents, et selon les besoins, l’un peut être meilleur — ou non — que l’autre
      C’est un peu comme demander ce qui est préférable entre un couteau et une scie
    • Par ailleurs, MCP permet de connecter des plateformes externes sans environnement d’exécution
      Chaque fois que ce sujet revient, les ingénieurs parlent comme si Claude Code était la seule application d’agent IA au monde, alors qu’il existe de très nombreux cas d’usage dans d’autres secteurs que le développement
      Le harnais peut tourner non pas sur une machine locale, mais dans un conteneur isolé et restreint dans le cloud, où l’exécution de code arbitraire est totalement interdite
      Même dans ce cas, si les clients veulent relier leurs outils existants à un agent, MCP est parfaitement adapté car il fournit des connecteurs avec authentification intégrée, alors que les skills ne couvrent pas ce besoin
    • Je construis une plateforme de critiques de restaurants avec des amis et, après plusieurs tâtonnements, MCP semble être la bonne direction
      Un utilisateur lambda n’ira pas chercher le répertoire Claude pour y coller un fichier de skill
      « Connections » est plus facile à comprendre, et coller un MCP ou le trouver sur une marketplace est plus simple
      On ne sait pas encore si le fait de donner à un agent l’accès aux lieux et aux avis sera réellement utile

  • Grandes félicitations aux personnes chez Okta, Anthropic, Microsoft, Figma, Linear et ailleurs qui ont réalisé ce travail
    Même les sceptiques de MCP peuvent y trouver quelque chose d’utile
    Cela fonctionne avec un nouveau format de jeton appelé ID-JAG, décrit ici : https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...
    Ce n’est absolument pas réservé à MCP, et ID-JAG peut être utilisé partout où des applications utilisant le même fournisseur SSO doivent partager des données de manière sécurisée

    • Vu que ce genre d’entreprises a plutôt dégradé les logiciels et la qualité de vie, difficile de ne pas y voir une pointe de sarcasme dans ces félicitations

  • J’essaie d’ajouter une authentification Microsoft Entra ID au serveur MCP que je suis en train d’implémenter, et franchement j’ai l’impression d’être devenu idiot
    Avec l’en-tête WWW-Authenticate, on peut indiquer au client l’URL des métadonnées de ressource, et via cela aussi préciser Microsoft Entra comme serveur d’authentification ainsi que le périmètre d’enregistrement de l’application
    Mais on ne peut pas spécifier de client_id, et l’idée semble être que chaque client, c’est-à-dire l’agent, le crée de son côté
    Or, pour démarrer la connexion via l’URL .../authorize d’Entra, il faut un client_id connu qui corresponde à un enregistrement d’application Entra, et une valeur créée arbitrairement par le client n’a aucune raison de correspondre à Entra
    En théorie, on pourrait prendre en charge l’enregistrement dynamique de client, mais Microsoft Entra ne le prend évidemment pas en charge
    Au final, la seule solution que je vois est de créer devant Microsoft Entra mon propre shim d’enregistrement dynamique de client qui renvoie à tout le monde le même client_id statique
    Je me demande si ce protocole est vraiment censé fonctionner en entreprise sans contournement, ou si je passe à côté de quelque chose d’évident

    • Tu ne sembles pas passer à côté de quelque chose d’évident
      Entra ID ne prend pas en charge l’enregistrement dynamique de client, et l’état de cet écosystème n’est pas encore fameux
      En général, l’OAuth MCP est géré avec des clients traditionnels préenregistrés, mais dans les faits beaucoup de clients MCP partent du principe que l’enregistrement dynamique de client fonctionne et n’offrent pas d’option pour définir le client_id
      Certains clients le prennent quand même en charge, et quitte à faire un peu de pub, notre outil Erato le prend aussi en charge : https://erato.chat/docs
      Les solutions classiques déployées en entreprise prennent aussi cela en charge, car elles centralisent en général l’accès MCP via une interface web
      Une autre option consiste à utiliser une passerelle MCP : entre la passerelle et le service, on utilise un OAuth préenregistré, et entre la passerelle et le client, on peut autoriser l’enregistrement dynamique de client
    • Nous avons eu le même problème avec le client_id, et pour des raisons de sécurité nous ne voulions pas activer l’enregistrement dynamique de client
      Nous avons donc fini par faire en sorte que l’application joue le rôle de proxy pour le flux OAuth en injectant un client_id codé en dur
      On fait croire au client MCP qu’on prend en charge l’enregistrement dynamique de client, mais en interne on utilise comme d’habitude un client_id distinct pour MCP
      Voici un exemple : https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...
    • Je l’ai justement implémenté hier, et l’idée est que cette bibliothèque exécute le serveur MCP : https://csharp.sdk.modelcontextprotocol.io/concepts/identity...
      Ensuite, j’ai créé une application de courtage d’authentification qui gère l’enregistrement des clients via OpenID et génère des JWT
      Au final, cela permet de décider si un outil peut être utilisé et avec quels droits selon le service de l’employé ou d’autres critères
      En fin de compte, l’enregistrement dynamique de client est nécessaire
    • FusionAuth a récemment documenté une manière d’utiliser des clients préenregistrés : https://fusionauth.io/docs/extend/examples/controlling-acces...
      Nous examinons aussi CIMD, le frère plus récent et meilleur de la DCR, et le sujet est activement discuté, mais ce n’est pas encore disponible : https://github.com/FusionAuth/fusionauth-issues/issues/3230
      Comme alternative au proxy proposé, il est possible de créer pour chaque client MCP un nouveau client_id Entra avec PKCE activé via un portail développeur ou équivalent, puis de demander à l’utilisateur de configurer cette valeur dans son client
      J’ai trouvé la commande CLI correspondante ici, et il doit probablement aussi y avoir une API : https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...
      La configuration de Claude Code se trouve ici : https://code.claude.com/docs/en/mcp, celle de ChatGPT ici : https://developers.openai.com/api/docs/guides/developer-mode
      Le préenregistrement des clients n’est peut-être pas idéal pour les développeurs, mais cela reste acceptable et la spécification le traite comme une approche de premier plan : https://modelcontextprotocol.io/specification/2025-11-25/bas...
      Si les principaux utilisateurs sont des employés internes capables de suivre des consignes de configuration pour accéder au serveur MCP, cette approche fonctionne aussi
      En revanche, si la cible est une intégration publique large destinée à des non-développeurs, ce n’est clairement pas acceptable, et c’est précisément là que résident une grande partie de la force et de l’opportunité de MCP

  • Je fais partie des personnes qui ont construit cela chez Anthropic avec Okta et plusieurs partenaires MCP.
    Je suis très enthousiaste de voir cette approche prendre forme dans Claude, et maintenant que l’EMA est une extension stable dans la spécification MCP, j’aimerais aussi élargir son adoption à d’autres fournisseurs d’identité et clients.
    Si vous avez des retours, n’hésitez pas à les laisser ici ; j’aimerais toujours entendre des expériences réelles d’utilisation et des idées d’amélioration.

    • Ça faisait longtemps.
      Je n’avais pas regardé MCP depuis un moment, mais cela semble assez bien correspondre au besoin de rendre MCP plus sûr dans les organisations et de corriger les faiblesses de l’enregistrement dynamique des clients.
      Désormais, les clients et les URI de redirection approuvées peuvent être configurés directement par le fournisseur d’identité et l’organisation, ce qui permet d’atténuer plus largement les attaques fondées sur le DCR, comme les attaques de délégation confuse ou le phishing.
      Autre gros avantage : cela réduit aussi la logique d’autorisation que les serveurs MCP devaient implémenter quand le fournisseur d’identité ou l’organisation ne prenait pas en charge le DCR.
      L’inconvénient, c’est que pour les usages grand public, il semble toujours nécessaire d’avoir du DCR.
      Cela pourrait peut-être se résoudre si des fournisseurs OAuth grand public comme GitHub, GitLab ou Google prenaient en charge l’enregistrement statique de clients/serveurs MCP, si le client intégrait en dur un client_id statique, et si l’utilisateur se connectait via ce fournisseur d’identité pour gérer lui-même la connexion.
      Globalement, XAA/EMA semble très nettement supérieur au DCR sur les plans de la sécurité et de l’ergonomie.
      Les points d’inquiétude paraissent aussi bien plus faciles à résoudre qu’avec le DCR et ont un impact sécurité moindre, parce qu’un attaquant ne peut pas enregistrer son propre client et qu’il y a moins de pièges dans lesquels les développeurs de serveurs MCP peuvent tomber.
    • C’est excellent pour une “app” classique, mais de notre côté nous avons un besoin urgent d’un moyen plus fluide, de type agentique, d’interagir sans que l’utilisateur ait à configurer MCP.
      Une sorte de session temporaire ou de magasin de tokens hors bande serait utile.
      Le cas d’usage, c’est que dans le cadre du processus commercial, acheteurs et vendeurs doivent échanger et analyser beaucoup d’informations, et cette analyse devient de plus en plus agentique.
      Le problème avec MCP, c’est que la friction de configuration initiale est bien plus importante que le fait de demander simplement à l’utilisateur de se connecter lui-même pour récupérer les informations nécessaires.
      MCP est bien adapté aux interactions régulières et fréquentes, mais pose beaucoup de problèmes pour des sessions rapides et ponctuelles.
      Si, dans Claude, on dit “récupère les documents depuis X, Y et Z”, il serait bien que Claude puisse accéder à ces sites et que le site renvoie des informations de base sur l’utilisateur ainsi qu’un lien de connexion que l’utilisateur peut ouvrir dans son navigateur.
      L’utilisateur s’authentifierait alors dans le navigateur, puis le callback renverrait un token unique à courte durée de vie, qui serait ensuite échangé dans les requêtes vers le site.
      Cela permettrait d’authentifier rapidement l’utilisateur tout en conservant l’état de session pendant le travail.
    • Je me demande si vous êtes en contact avec l’équipe Microsoft Entra, c’est-à-dire Azure AD.
      J’aimerais savoir si c’est quelque chose qu’on peut espérer bientôt, ou si cela risque de prendre encore pas mal de temps.
    • Félicitations pour le lancement.
      Le principal cas d’usage semble concerner les employés d’entreprise, mais je me demande s’il y a une valeur comparable aussi pour des utilisateurs non centralisés, comme des clients ou des utilisateurs gratuits premiumisés.
      Je n’arrive pas vraiment à le voir, donc je voulais savoir ce qui m’échappe ; il me semble avoir vu une réponse pertinente ici : https://news.ycombinator.com/item?id=48594381
    • Je veux juste confirmer que ce n’est pas encore réellement utilisable en pratique et qu’on est encore au stade SEP.

  • C’est vraiment excellent.
    Ces derniers mois, j’ai eu la chance de pouvoir manipuler avec les gens de l’écosystème MCP plusieurs SEP ainsi qu’un SDK expérimental en Go.
    Avant, j’étais parmi les sceptiques qui disaient “ce n’est qu’une API”, “on a encore créé une couche d’abstraction”.
    Ce que les gens ratent, c’est que le “P” de MCP induit en erreur.
    Quand on construit une application traditionnelle, il faut créer des formulaires, une UI, la gestion requête/réponse, des canaux bidirectionnels, des tâches longues, l’authentification, etc.
    Avec MCP, 80 % de cette couche commune est prise en charge ; donc MCP est certes un protocole, mais en pratique c’est presque davantage un framework applicatif.
    L’authentification intégrée est un énorme progrès, et j’ai hâte de voir la suite.

  • C’est assez étrange de voir à l’extérieur un travail que j’ai réalisé.
    Chez Atlassian, j’étais chargé de l’implémentation côté RAS de ce flux.
    Il y aura clairement des itérations sur ce flux, notamment autour de CIMD, d’un meilleur support de la multi-tenance, etc.
    Toutes les personnes d’Anthropic, d’Okta et d’Atlassian qui ont livré cela ont été excellentes.

  • J’aimerais qu’il y ait un support du web qui permette simplement d’émettre des cookies longue durée.
    J’ai bricolé la spécification pour faire passer des cookies via le handshake OAuth afin de faire cela sans serveur OAuth.
    C’est vraiment frustrant de vouloir empêcher ce genre de chose.
    S’il n’y a pas de cookie, on ouvre une page web ; une fois le cookie défini, on ferme et on enregistre.
    J’ai même écrit un mini-livre de 80 pages sur MCP, et pourtant je continue à trouver cela infiniment frustrant.

    • Je suis l’un des principaux mainteneurs du projet MCP, et cette approche ne passe pas à l’échelle dans plusieurs scénarios.
      Elle pose des problèmes à la fois d’ergonomie et de sécurité, et les cookies sont conçus pour les navigateurs.
      Les serveurs et clients MCP fonctionnent souvent dans des environnements où la présence d’un navigateur n’est pas garantie.
    • Cela revient pratiquement à demander qu’on vous laisse vous faire voler vos identifiants.
      Les identifiants de longue durée impliquent une lourde responsabilité.

  • Je l’ai relu plusieurs fois et c’est clairement utile.
    L’audit et le contrôle d’accès peuvent être centralisés chez un seul fournisseur d’identité, qui peut aussi agir comme une API gateway proxy se chargeant de l’échange de tokens si nécessaire.
    C’est une approche également adoptée par d’autres acteurs du secteur.
    Personnellement, le fait que le fournisseur d’identité délègue mes autorisations au client sans que j’en sois conscient me met un peu mal à l’aise.
    C’est peut-être parce que je suis trop habitué aux flux où l’utilisateur est présent dans le navigateur, et j’ai l’impression qu’on évolue de plus en plus vers une centralisation des accès pour les machines.
    Dans un environnement d’entreprise, cela peut se comprendre, puisque l’identité appartient davantage à l’entreprise qu’à la personne.
    Mais l’intégrer côté identité client est un tout autre défi, et il ne sera probablement pas simple d’établir ce niveau de confiance entre fournisseur d’identité, client et serveur d’autorisation de ressources.

    • Il n’existe pas de barrière théorique qui empêcherait cette intégration de fonctionner dans le monde grand public.
      On pourrait par exemple créer une relation de confiance du type : si vous êtes connecté à GitHub, vous êtes automatiquement connecté à Sentry.
      Il reste encore beaucoup de travail, mais à l’heure actuelle, comme vous l’avez dit, le cas d’usage le plus évident reste l’entreprise.
      Les administrateurs n’ont pas envie que chaque employé clique partout pour choisir au hasard des identifiants.

  • Chez C1, l’authentification MCP était un vrai casse-tête, aussi bien pour l’usage interne de MCP que du côté de la passerelle MCP intégrée au produit, donc c’est une très bonne nouvelle de voir ça arriver
    Aujourd’hui, C1 a lancé la prise en charge du fonctionnement comme fournisseur d’identité EMA, avec émission de jetons à portée limitée et de courte durée de vie
    J’aimerais maintenant me connecter à Linear et aux autres MCP que nous utilisons pour sortir des flux OAuth répétitifs
    Claude faisait déjà ce genre de chose comme par magie avec certains connecteurs intégrés, au moins avec Slack, et l’expérience est plutôt bonne
    Pour être transparent, je suis le VPE de C1, et nous avons documenté l’approche pour ceux qui veulent creuser : https://www.c1.ai/docs/product/admin/enterprise-managed-auth...

  • Je ne comprends pas très bien quel est l’avantage par rapport à OAuth classique
    Il faudrait sans doute un exemple comparatif des flux d’autorisation

    • Avec OAuth classique, l’utilisateur final consent individuellement à ce que chaque application partage ses données
      Cela a du sens dans les cas d’usage grand public, où l’utilisateur final est propriétaire de ses données
      Mais dans beaucoup de cas d’usage en entreprise, l’entité qui doit partager les données et contrôler l’accès n’est pas l’utilisateur final, c’est l’entreprise
      En tant qu’employé d’Acme, je ne devrais pas décider si les données Google Drive d’Acme peuvent être connectées à Claude ou ChatGPT ; c’est au service informatique d’en décider
      Enterprise-Managed OAuth, ou Cross App Access (XAA), fait entrer dans le cadre OAuth un modèle de partage contrôlé de manière centralisée par l’administrateur IT, afin de fonctionner avec l’écosystème existant
      En outre, déplacer la gestion du consentement au partage des données des employés vers les administrateurs IT apporte aussi un gros avantage en matière d’expérience utilisateur
      Les employés n’ont pas besoin de passer par plusieurs flux OAuth pour connecter leurs comptes, puisque les administrateurs IT ont déjà configuré les contrôles de partage
      Il suffit d’imaginer qu’au premier jour, Slack est déjà connecté à Zoom, Drive, Calendar, etc.
    • L’avantage, c’est que les utilisateurs n’ont pas à contrôler ni à approuver quelles applications sont autorisées à partager leurs informations entre elles
      Parce que la décision de délégation d’accès est prise au niveau des politiques du fournisseur d’identité
      Les utilisateurs pourraient même ne jamais savoir quelles applications ou quels services sont autorisés à partager leurs informations
      Attendez, est-ce vraiment un avantage ? ;-)