Pourquoi votre produit a besoin d' OAuth 2.0 et OIDC — Surtout à l'ère de l'IA

Dès le début, Logto a été construit avec une forte croyance dans les standards ouverts. Nous avons choisi de suivre des protocoles comme OIDC, OAuth 2.0, et SAML — non seulement parce qu'ils sont largement utilisés, mais parce qu'ils représentent des pratiques bien établies et sûres, reconnues de l'industrie. La sécurité a toujours été une priorité pour nous. Ainsi que rester fidèle à l'esprit de l'open source, et adhérer aux meilleures pratiques en Customer Identity Management et à l'authentification moderne.

Mais nous avons aussi appris quelque chose en cours de route :

OAuth 2.0 et OIDC ne sont pas faciles pour tout le monde. Pour les développeurs novices avec ces protocoles, les concepts peuvent sembler étrangers et parfois même contre-intuitifs. Cela a mené à de véritables défis quand nous avons travaillé sur la simplification de l'expérience développeur sans compromettre la sécurité.

Deux points se sont distingués :

1. Même si nous avons travaillé dur pour rendre l'intégration aussi fluide que possible, il y a toujours une courbe d'apprentissage autour de la compréhension des concepts de base comme les jetons d'identification, les jetons d'accès, et leur fonctionnement.
2. Une question courante est : « Puis-je éviter la redirection sur l'écran de connexion ? » Malheureusement, la redirection est une partie essentielle de la manière dont OIDC fonctionne et est nécessaire pour une authentification sécurisée.

Une question fréquente de nos utilisateurs Discord (avec leur ID et avatar masqués pour la confidentialité).

Chaque décision implique des compromis — mais parfois, un choix que vous avez fait tôt se révèle particulièrement précieux au fur et à mesure que de nouveaux cas d'utilisation émergent. Et nous entrons maintenant dans une nouvelle ère : l'ère de l'IA.

Dans cet article, j'explorerai quand votre produit devrait utiliser OIDC et OAuth 2.0, quand il pourrait ne pas en avoir besoin, et pourquoi j'ai toujours préconisé l'adoption de ces standards ouverts dès le début — surtout si vous construisez une vraie entreprise et choisissez une solution CIAM. J'expliquerai aussi pourquoi l'essor de l'IA rend cette décision plus importante que jamais.

Ce que fait vraiment OAuth 2.0 (avec une analogie simple)#

Pour les lecteurs qui ne sont pas très familiers avec OAuth 2.0, permettez-moi de vous en expliquer brièvement quelques concepts de base — juste pour clarifier les choses.

OAuth 2.0 est pour l'autorisation déléguée : OAuth 2.0 est un protocole standard de l'industrie pour l'autorisation — il permet à un service d'accéder à des ressources sur un autre service, avec le consentement du propriétaire de la ressource.

Dans un scénario OAuth, l'utilisateur (propriétaire de la ressource) accorde à une application cliente un accès limité (autorisations définies) à une API ou à un serveur de ressources, sans partager son mot de passe. OAuth définit comment demander et émettre des jetons d'accès que le client peut utiliser pour appeler des APIs protégées. Cela a révolutionné les choses par rapport aux débuts où les applications pouvaient demander vos identifiants pour accéder à un autre service (un risque de sécurité sérieux). Avec OAuth 2.0, les utilisateurs approuvent un accès spécifique et le client obtient un jeton avec uniquement les autorisations et la durée nécessaires — aucun mot de passe n'est échangé, améliorant ainsi la sécurité de façon spectaculaire.

Pensez à OAuth 2.0 comme à l'enregistrement dans un hôtel.

Vous (l'utilisateur) êtes le propriétaire de la chambre (vos données). Mais au lieu de donner à quelqu'un votre clé de chambre (votre mot de passe), vous allez à la réception et demandez une carte d'accès temporaire (un jeton d'accès) qui ne permet qu'à votre invité ou ami d'entrer dans la salle de sport ou la piscine — pas dans toute la chambre.

Le personnel de l'hôtel (système OAuth) émet cette carte limitée avec des règles spécifiques :

• Elle ne fonctionne que pour la salle de sport (ressource spécifique).
• Elle est valide pour une courte période.
• Elle ne permet à personne d'entrer dans votre chambre.

De cette façon, vous n'avez pas à donner votre clé principale — et le système reste sécurisé, même si quelqu'un d'autre met la main sur cette carte limitée.

Voyons un autre exemple. OAuth 2.0 est largement utilisé dans le scénario de connexion sociale.

Disons que vous vous inscrivez à une nouvelle application comme Notion, et au lieu de créer un nouveau nom d'utilisateur et un mot de passe, vous cliquez sur « Continuer avec Google. »

Voici ce qui se passe en coulisses avec OAuth 2.0 :

1. Vous êtes redirigé vers la page de connexion de Google, où vous vous connectez (si ce n'est pas déjà fait).

2. Google demande :

   « Permettez-vous à cette application de voir votre profil de base et votre adresse e-mail ? »

3. Vous cliquez sur « Autoriser », et Google envoie un jeton d'accès à l'application.

4. L'application utilise ce jeton pour :

   • Confirmer votre identité (via votre e-mail et les informations de profil).
   • Créer ou vous connecter à un compte — sans jamais voir votre mot de passe Google.

Ce que fait vraiment OIDC (avec une analogie simple)#

Examinons maintenant OIDC — une norme plus récente et plus avancée. OpenID Connect vise à l'identité et l'authentification : c'est une couche d'authentification construite sur OAuth 2.0. Alors qu' OAuth 2.0 seul ne dit pas à l'application qui est l'utilisateur (il ne s'agit que des jetons d'accès et de leurs portées), OIDC ajoute une manière normalisée de gérer la connexion et l'identité de l'utilisateur.

En utilisant OIDC, le serveur d'autorisation agit également comme un fournisseur OpenID (un fournisseur d'identité) qui authentifie l'utilisateur et émet un jeton d'identité contenant des informations sur l'utilisateur (les « revendications d'identité »).

En résumé, OAuth 2.0 répond à la question « Ce client peut-il accéder à cette ressource ? » et OIDC répond à « Qui est l'utilisateur qui vient de se connecter ? ». Ensemble, ils permettent à votre application de vérifier l'identité de l'utilisateur et ensuite d'utiliser des jetons autorisés pour accéder aux APIs au nom de l'utilisateur.

Utilisons à nouveau l'analogie de l'hôtel pour mieux comprendre OAuth 2.0 vs. OIDC.

Imaginez que vous enregistrez dans un hôtel.

• OAuth 2.0 est comme demander à l'hôtel de laisser votre ami utiliser la salle de sport et la piscine en votre nom.

  Vous allez à la réception, donnez votre permission, et l'hôtel donne à votre ami un pass invité.

  L'hôtel ne se soucie pas de qui est l'ami — juste qu'il est autorisé à utiliser les installations.

  👉 C'est OAuth : « Cette appli peut accéder à certaines de mes données ou services. »

• OIDC c'est comme demander à l'hôtel de vérifier qui est la personne avant de lui donner l'accès.

  Ainsi votre ami montre également une pièce d'identité — et maintenant l'hôtel connaît leur nom, leur statut, et qu'ils sont un invité vérifié.

  👉 C'est OIDC : « Voici qui est l'utilisateur, et il est maintenant connecté. »

Comment Logto utilise OAuth 2.0 et OpenID Connect (OIDC)#

Les principales fonctionnalités d'authentification de Logto sont construites sur OIDC (OpenID Connect)#

À son cœur, Logto est un fournisseur OpenID Connect (OIDC) — une norme construite sur OAuth 2.0 qui se concentre sur l'authentification sécurisée et moderne des utilisateurs. Logto est une solution CIAM professionnelle, où les identités sont les éléments de base que nous gérons.

Nous avons conçu Logto en prenant la sécurité comme fondement. Cela signifie appliquer PKCE par défaut, bloquer les flux non sécurisés comme le flux implicite, et s'appuyer sur la redirection pour gérer les connexions en toute sécurité.

Pourquoi la redirection ?#

OIDC est conçu pour l'authentification basée sur le navigateur. Ce n'est pas juste un choix technique — il s'agit de donner aux utilisateurs une expérience cohérente et sécurisée sur toutes les plateformes. Rediriger l'utilisateur vers le fournisseur d'identité (comme Logto, Google ou Microsoft) rend cela possible.

Voici à quoi ressemble le flux typique :

1. L'utilisateur clique sur « Se connecter »

   → Votre application l'envoie à la page de connexion de Logto.

2. Ils se connectent en toute sécurité

   → C'est là que des éléments comme le MFA, les biométries, ou les connexions sociales ont lieu.

3. Logto les renvoie

   → Avec un jeton sécurisé ou un code d'autorisation.

4. Votre application termine la connexion

   → Le jeton est vérifié, et l'utilisateur est connecté.

Ce schéma peut sembler simple, mais il offre de puissants avantages :

• Votre application ne gère pas directement les identifiants — ce qui signifie moins de risques.
• Il est plus facile d'ajouter des fonctionnalités comme le MFA sans changer le code de l'application.
• Cela fonctionne également bien pour les mobiles :
  • iOS utilise ASWebAuthenticationSession
  • Android utilise Custom Tabs

Et si votre produit s'étend sur plusieurs applications, la redirection permet la connexion unique — les utilisateurs se connectent une fois, et naviguent entre les applications sans friction.

Logto ne supporte pas la collecte de mots de passe directement dans votre application. C'est intentionnel. Le flux ROPC n'est pas recommandé pour les meilleures pratiques de sécurité OAuth 2.0 pour de bonnes raisons — il est moins sécurisé et plus difficile à étendre en toute sécurité.

Logto est aussi un fournisseur OAuth 2.0/OIDC (Fournisseur d'identité)#

Logto n'est pas seulement un serveur d'authentification — c'est un OAuth 2.0, OpenID Connect (OIDC) et fournisseur d'identité (IdP) complet. Cela signifie qu'il peut gérer en toute sécurité les identités des utilisateurs et émettre des jetons que d'autres applications peuvent accepter.

En plus d'alimenter les expériences de connexion pour vos propres applications, Logto prend également en charge les intégrations d'applications tierces, permettant aux services externes de s'appuyer sur Logto comme source d'identité.

Que cela signifie-t-il concrètement ?

En tant que Fournisseur d'identité (IdP), Logto s'occupe de la vérification des utilisateurs, gère les identifiants, et émet les jetons d'authentification. Une fois qu'un utilisateur se connecte, Logto peut lui permettre d'accéder à différentes applications — même provenant d'autres vendeurs — sans avoir à se reconnecter. C'est le même concept derrière « Se connecter avec Google » ou « Se connecter avec Microsoft ».

Il existe deux types d'applications dans ce contexte :

• Applications de première partie : Applications que vous construisez et contrôlez entièrement, intégrées directement avec Logto.
• Applications tierces : Services externes construits par des partenaires ou des développeurs hors de votre organisation.

Logto permet à vos utilisateurs de se connecter à ces applications tierces en utilisant leurs comptes Logto existants — tout comme les utilisateurs d'entreprises se connectent à des outils comme Slack avec leurs identifiants Google Workspace. Cela vous permet de :

• Offrir la connexion unique (SSO) à travers votre écosystème.
• Construire une plateforme ouverte, où les développeurs tiers peuvent ajouter « Se connecter avec Logto » à leurs applications.

Quand avez-vous vraiment besoin d' OAuth 2.0 et OIDC ?#

1. Si vous utilisez auparavant Auth0 (ou similaire) : Auth0 est déjà un fournisseur d'OAuth 2.0 et OIDC. Il gère la connexion des utilisateurs, l'émission des jetons, et s'intègre avec vos APIs ou applications.
2. M2M authorization: Autorisation serveur à serveur (flux des identifiants clients) Les machines (ou services backend) doivent communiquer en toute sécurité sans un utilisateur.
3. Device flow: Smart TVs, consoles, appareils IoT : Des équipements comme les téléviseurs ou les imprimantes doivent authentifier un utilisateur. Le flux des appareils fait partie de l'OIDC.
4. Vous avez des besoins d'intégration : Vous n'authentifiez pas seulement des utilisateurs — vous créez un écosystème où des applications externes, partenaires, ou agents peuvent s'intégrer à votre plateforme et accéder aux données des utilisateurs en toute sécurité.

Pourquoi OAuth et OIDC sont plus importants que jamais à l'ère de l'IA#

À l'ère de l'IA, nous assistons à une montée en puissance des besoins en intégration et en accès — surtout dans des domaines comme les agents autonomes, les appareils intelligents, et la communication système à système. Ces tendances rendent OAuth 2.0 et OIDC plus importants que jamais. Voici quelques exemples :

1. Serveurs MCP distants

   Vous construisez un serveur MCP (Model Context Protocol) distant et souhaitez que des agents tiers s'y connectent. Ces agents ont besoin d'un accès sécurisé pour demander un contexte, exécuter des actions, et échanger des données — sans compromettre la confiance des utilisateurs. OAuth fournit le mécanisme pour déléguer l'accès en toute sécurité.

2. Ouvrir votre produit aux intégrations

   Vous gérez vos propres services d'entreprise — par exemple un outil de gestion de projet ou une plateforme client — et vous voulez permettre à d'autres produits ou agents de s'intégrer. Cela pourrait signifier extraire des données, déclencher des flux de travail, ou intégrer vos fonctionnalités dans d'autres environnements. OAuth 2.0/OIDC permet un contrôle d'accès basé sur des jetons bien précis sans partager les identifiants des utilisateurs.

3. Créer votre propre agent

   Vous créez un agent ou assistant IA et souhaitez qu'il interagisse avec d'autres applications et serveurs MCP — planifiant des réunions, envoyant des e-mails, publiant des mises à jour, ou interrogeant des données. Cela nécessite un accès sécurisé et authentifié à des services tiers. OAuth 2.0 est comment votre agent est autorisé à agir au nom de l'utilisateur.

4. L'essor des appareils intelligents Les appareils matériels comme les traducteurs IA ou les preneurs de notes intelligents deviennent plus performants grâce aux LLMs. Et avec des coûts réduits et des performances accrues, de plus en plus de ces appareils arrivent sur le marché. Ces appareils ont souvent besoin d'une méthode pour authentifier les utilisateurs et accéder aux services basés sur le cloud — surtout avec des interfaces d'entrée limitées. C'est là que des flux comme le flux d'autorisation des appareils d'OAuth et la validation d'identité basée sur OIDC deviennent critiques.

Quand vous pourriez ne pas avoir besoin de OAuth 2.0/OIDC#

Bien sûr, il existe des cas où vous pourriez ne pas avoir besoin d'OAuth 2.0 ou d'OIDC — du moins pas pour le moment. Autrement dit, si votre cas d'utilisation actuel est simple ou entièrement autonome, ces protocoles pourraient ne pas apporter de valeur immédiate.

Cependant, à mesure que votre produit évolue ou que votre écosystème s'étend, le besoin d'OAuth 2.0 et d'OIDC devient souvent beaucoup plus évident à long terme.

1. Applications simples et internes

   Si votre application est uniquement utilisée par une petite équipe au sein d'une entreprise et n'a pas besoin de s'intégrer avec des services tiers ou d'exposer des APIs, un système d'authentification de base par nom d'utilisateur et mot de passe (par exemple, sessions par cookies) pourrait suffire.

2. Pas de besoin en authentification utilisateur

   Si votre produit n'a pas de comptes utilisateurs ou de fonctionnalités conscientes d'identité — comme un site de contenu public ou un outil serveur à serveur avec des clés API statiques — l'OIDC n'est pas nécessaire.

3. Pas besoin d'accès délégué

   OAuth est excellent lorsque vous avez besoin que les utilisateurs autorisent votre application à accéder à leurs données dans un autre système (par exemple, Google Drive). Si vous n'intégrerez pas de APIs tiers ou ne construirez pas de flux de travail multi-services, OAuth ajoute de la complexité avec peu d'intérêt.

4. Environnement unique, risque minimal

   Pour les premiers prototypes, MVPs, ou outils de test internes où la simplicité et la rapidité priment sur les besoins de sécurité, vous pourriez retarder l'implémentation d' OAuth/OIDC jusqu'à plus tard.

Dernières réflexions sur le choix de la bonne stratégie d'authentification#

Vous pourriez ne pas avoir besoin d'OAuth 2.0 ou d'OIDC tout de suite — et c'est complètement normal. Aux premiers stades, des solutions simples font souvent le travail. Mais à mesure que votre produit se développe, que les agents et l'IA s'intègrent davantage dans la manière dont nous construisons, et que votre écosystème s'ouvre aux partenaires et aux tiers, l'authentification sécurisée et standardisée devient moins un luxe et plus une nécessité.

Au lieu de rattraper plus tard, il vaut la peine de poser les fondations dès maintenant. Adopter OAuth 2.0 et OIDC, ce n'est pas seulement résoudre les problèmes d'aujourd'hui — c'est être prêt pour ce qui arrive ensuite.