Issuer et discovery
Épingler l’issuer attendu, vérifier la cohérence de la configuration découverte et n’utiliser que les endpoints et clés du provider approuvé.
API
Intégrateur OpenID Connect pour prouver l’identité sans confondre les droits
Dawap relie votre application — le Relying Party — à un OpenID Provider sans réduire OIDC à un bouton de connexion. Nous lions chaque transaction au bon issuer, vérifions l’ID Token et le nonce, identifions le compte par issuer + subject, puis testons UserInfo, rotation JWKS, session locale et logout dans les conditions du run.
Premier lot OpenID Connect
Connecter une application à un issuer, puis éprouver l’identité et la sortie.
Le pilote retient un Relying Party, un OpenID Provider, deux comptes et une action sensible. Il couvre discovery, Authorization Code avec PKCE, validation de l’ID Token, création ou rapprochement du compte local, UserInfo éventuel, réauthentification et fermeture de la session.
Entrée : RP, issuer et sujets nommés
Sortie : identité et refus prouvés
Run : sessions et clés observables
À l’issue du cadrage
- Inventorier issuer exact, client_id, redirect URIs, discovery, JWKS URI, algorithmes, scopes OIDC et capacités de logout réellement exposées.
- Définir la clé de compte local à partir de issuer + sub, les règles de rapprochement, les attributs nécessaires et l’owner de chaque claim.
- Séparer ID Token, access token, session OP, session RP, droits métier et exigences de réauthentification sur les opérations sensibles.
- Tester mauvais issuer ou audience, nonce rejoué, UserInfo au subject différent, email modifié, clé inconnue, logout en retard et fournisseur indisponible.
Réponse courte
Une intégration OpenID Connect prouve qui s’est authentifié et pour quel client.
L’intégrateur configure le Relying Party sur un issuer connu, exécute le parcours Authorization Code avec PKCE, vérifie signature, issuer, audience, expiration et nonce de l’ID Token, puis relie le sujet au compte local par issuer + sub. Il traite séparément claims, droits métier, session locale, UserInfo, clés et logout.
- OpenID Connect ajoute une couche d’identité à OAuth 2.0 ; l’access token destiné à une API ne remplace pas l’ID Token reçu par le client.
- Le claim email peut évoluer et n’est pas une clé universelle : le subject n’est interprété que dans le périmètre de son issuer.
- Fermer la session du provider ne garantit pas à lui seul que toutes les sessions locales sont fermées ; chaque mécanisme de logout doit être testé.
iss + sub
clé composite conservée pour identifier un sujet dans le périmètre de son émetteur
1 nonce
valeur liée à la transaction et vérifiée dans l’ID Token lorsqu’elle a été envoyée
2 sessions
session chez le provider et session locale du Relying Party gouvernées séparément
0 email
utilisé seul comme identifiant durable ou comme preuve automatique de rattachement
Contrat d’identité OIDC
Six décisions avant de transformer un ID Token en session applicative
Décoder un JWT ne prouve rien. L’application doit savoir quel issuer elle accepte, pour quel client, comment elle rattache le subject, quels attributs restent informatifs et comment elle réagit quand une clé, une session ou une identité change.
ID Token et transaction
Valider signature, algorithme autorisé, iss, aud, azp si plusieurs audiences, exp, iat et le nonce lié à la demande quand il est présent.
Subject et compte local
Construire l’identité autour de issuer + sub, encadrer création et rapprochement de compte, puis traiter email et nom comme des attributs mutables.
Claims et UserInfo
Limiter les claims au besoin, vérifier que UserInfo retourne exactement le même sub que l’ID Token et versionner leur mapping métier.
Réauthentification sensible
Interpréter acr, amr, auth_time et max_age selon une politique documentée, sans déduire un niveau de garantie du seul écran de login.
Sessions, clés et logout
Distinguer sessions OP et RP, éprouver RP-Initiated, front-channel ou back-channel selon les capacités, et absorber une rotation JWKS sans ouverture silencieuse.
Parcours OpenID Connect
Quatre situations où le même login ne crée pas la même identité locale
Le protocole reste identique, mais le risque se déplace entre rattachement au bon tenant, coexistence de plusieurs providers, élévation de garantie et extinction de sessions dispersées.
Rattacher le sujet à la bonne organisation
Résoudre issuer + sub vers un compte puis un tenant local, contrôler invitation et domaine sans transformer un claim en autorisation définitive.
Un utilisateur ne rejoint pas une organisation par simple ressemblance d’email.Éviter les collisions entre deux émetteurs
Lier la transaction au provider choisi, isoler discovery et JWKS par issuer, puis conserver une identité composite côté application.
Deux subjects identiques émis par deux providers restent deux identités distinctes.Exiger une authentification assez récente et assez forte
Définir la garantie attendue, demander max_age ou un contexte approprié et vérifier auth_time, acr et amr selon le contrat du provider.
L’application ne confond plus session existante et preuve récente adaptée au risque.Faire coexister identité historique et OIDC
Définir les règles de liaison, les doublons, le rollback, la durée de coexistence et la source d’autorité sans réattribuer un compte au hasard.
La migration progresse application par application avec identité et sortie contrôlées.Scénarios de recette OpenID Connect
Trois contre-tests qui distinguent un SSO visible d’une identité fiable
Ces scénarios complètent notre référence publique OAuth2/OIDC sur Keycloak. Ils sont adaptés au provider, aux bibliothèques clientes, au modèle de comptes et aux mécanismes de session réellement disponibles.
Un JWT signé ne traverse ni issuer ni audience
La recette présente au Relying Party un ID Token correctement signé mais émis par un provider non attendu, destiné à un autre client ou lié à un autre nonce. Aucun compte ni session locale ne doit être créé.
À auditer
Issuer configuré, metadata discovery, algorithme autorisé, kid et JWKS, aud, azp, exp, iat, nonce, client_id, transaction et politique de tolérance temporelle.
Livrable
Matrice de validation ID Token avec cas acceptés, refus normalisés, stratégie de cache JWKS et comportement borné quand un kid est inconnu.
Traces
Transaction, issuer attendu et reçu, audience, azp, kid, résultat signature, nonce, session créée ou refusée et cause exploitable.
Décision
Bloquer le lancement si l’application sélectionne dynamiquement un issuer ou une clé depuis un token non approuvé, ou accepte une audience étrangère.
Le compte suit issuer + sub, jamais une ressemblance de profil
Le provider modifie l’adresse email d’un sujet, puis la recette retourne une réponse UserInfo dont le sub diffère de celui de l’ID Token. Le premier cas met à jour un attribut selon la règle prévue ; le second est refusé sans fusion de comptes.
À auditer
Clé locale issuer + sub, type de subject public ou pairwise, email et email_verified, invitation, tenant, règles de liaison, UserInfo, doublons et journal de décision.
Livrable
Contrat de rapprochement et de mutation des identités avec owners de claims, traitements des collisions, validation UserInfo et reprise manuelle.
Traces
Issuer, subject pseudonymisé, compte local, tenant proposé, origine du claim, ancienne et nouvelle valeur, décision de liaison et motif de refus.
Décision
Interdire l’auto-fusion tant qu’une égalité d’email peut transférer un compte, une organisation ou des droits entre deux subjects.
La session locale se ferme avec une preuve observable
L’utilisateur déclenche le logout chez le RP, puis un Logout Token back-channel valide, dupliqué et invalide est présenté. La recette vérifie la redirection enregistrée, ferme la bonne session locale, traite l’opération idempotemment et refuse l’événement non valide.
À auditer
Session OP, cookie et session RP, end_session_endpoint, post_logout_redirect_uri exacte, id_token_hint, front/back-channel, iss, aud, sid ou sub, events, exp, jti et reprise.
Livrable
Matrice de logout par application avec sessions ciblées, validation du Logout Token, idempotence, métriques, délai de fermeture et procédure fournisseur indisponible.
Traces
Initiateur, issuer, RP, sid ou subject pseudonymisé, jti, session trouvée, fermeture, rejeu, latence, réponse HTTP et cause d’échec.
Décision
Ne pas promettre de single logout tant que chaque RP concerné n’a pas prouvé son mécanisme, sa session fermée et son comportement en panne.
Intentions traitées
Pourquoi une équipe cherche un intégrateur OpenID Connect
Le besoin apparaît lorsqu’un produit doit accepter un nouvel IdP, qu’un SaaS rattache mal ses organisations, qu’une session survit au logout ou qu’une migration SSO ne sait plus quel compte local représente le sujet.
Relier provider, Relying Party, ID Token, sujet, compte local, session, logout, exploitation et responsabilités.
Vérifier iss, aud, azp, nonce, signature et expiration, puis traiter sub, attributs et réponse UserInfo sans substitution.
Distinguer sessions OP/RP, capacités de logout, rotation de clés, indisponibilité provider et collisions entre issuers.
Livrables OpenID Connect
Ce que Dawap met en place pour une identité fédérée exploitable
Le livrable ne s’arrête pas à la redirection vers le provider. Il relie chaque preuve cryptographique au compte local, chaque attribut à son owner et chaque session à une procédure d’ouverture, d’expiration et de fermeture.
- Cartographie des OpenID Providers, issuers, Relying Parties, environnements, client IDs, redirect URIs, discovery documents, JWKS et capacités déclarées.
- Contrat de validation de l’ID Token : algorithmes autorisés, signature, iss, aud, azp, exp, iat, nonce, horloges, erreurs et journalisation sans token brut.
- Modèle d’identité local : clé issuer + sub, sujets publics ou pairwise, invitations, liaisons, fusions interdites, tenants, doublons et reprise opérateur.
- Dictionnaire de claims et UserInfo : source, finalité, caractère mutable, validation du sub, fraîcheur, consentement, minimisation et mapping applicatif.
Méthode
On part du compte local et de la session à fermer, pas de l’écran du provider
Nous suivons une identité depuis l’issuer et le subject jusqu’au compte, au tenant et à la session locale. Puis nous remontons la preuve : transaction, nonce, ID Token, claims, UserInfo éventuel et contexte d’authentification. Cette lecture empêche un login réussi de masquer une mauvaise personne, une mauvaise organisation ou une session impossible à retirer.
Résultats attendus
- Un issuer et un client explicitement liés à chaque transaction d’authentification.
- Des ID Tokens vérifiés avant toute création de compte ou de session locale.
- Une identité fondée sur issuer + sub plutôt que sur un email mutable.
- Des claims minimisés, sourcés et séparés des permissions métier.
Maillage identité et accès
Approfondir la couche qui porte réellement chaque décision
OpenID Connect traite l’authentification et l’identité. OAuth 2.0 porte l’autorisation vers les API, le produit IAM implémente les capacités et le provisioning gère un autre temps du cycle de vie.
Des clients témoignent de leurs projets avec Dawap.
Bruno Pichot
« Nous disposons aujourd’hui d’une application robuste, performante et parfaitement intégrée. »
Mathilde Bordeaux
« Là où j’utilisais auparavant des intégrations fragiles via Zapier, ils ont mis en place de vraies intégrations directes en API, beaucoup plus fiables et performantes. »
Loic O
« Aujourd’hui, tous nos flux produits, stocks et prix sont synchronisés automatiquement : plus besoin de ressaisir les données manuellement. »
Technologies et partenaires
Nous concevons des plateformes digitales robustes à partir de technologies éprouvées. Applications métier, marketplaces, middleware et APIs sont sélectionnés pour leur fiabilité, leur performance et leur intégration dans des environnements complexes.
-
Docker
-
Symfony
-
Mysql
-
Postman
-
Swagger
-
Redis
-
Memcached
-
Algolia
-
Arch Linux
-
Ubuntu
-
Drupal
-
Magento
-
Prestashop
-
Shopify
-
Docker
-
Symfony
-
Mysql
-
Postman
-
Swagger
-
Redis
-
Memcached
-
Algolia
-
Arch Linux
-
Ubuntu
-
Drupal
-
Magento
-
Prestashop
-
Shopify
Niveau de preuve
Une référence publique OAuth2/OIDC ; trois preuves API adjacentes
Le projet assurance documente explicitement une migration vers Keycloak fondée sur OAuth2/OIDC, avec tokens, rôles, sessions et coexistence. Les trois autres projets illustrent des contraintes B2B et SI proches, sans être présentés comme des implémentations OpenID Connect.
Pour Branchassist, passer du SSO historique à Keycloak ne devait pas transférer aveuglément les autorisations. Dawap a séparé la connexion externe des droits internes : échange du code, contrôle de l’utilisateur actif, rôles Symfony, accès par ressource, révocation des jetons et trace des connexions. Une migration IAM ancrée dans l’application métier.
Pour Art’Sacs, activité reprise depuis par France Appro, Dawap a relié Aster et PrestaShop afin de transformer le catalogue fournisseur, synchroniser les quantités, enrichir les fiches et préparer les commandes dropshipping. Les tâches, états et erreurs donnent aux équipes un flux pilotable plutôt qu’une synchronisation opaque.
OpenID Connect devient critique quand le SI doit relier ID Token, issuer, audience, nonce, JWKS, UserInfo, claims, sessions et logout. Le bon connecteur évite les identités impossibles à prouver, les rôles qui divergent, les sessions mal terminées et les applications qui acceptent un utilisateur hors contexte.
OAuth2 devient critique quand une API doit relier authorization code, PKCE, client credentials, scopes, access tokens, refresh tokens, introspection, metadata et révocation. Le bon connecteur évite les clients trop larges, les tokens impossibles à retirer et les APIs qui acceptent un accès hors contexte métier.
Keycloak devient critique quand le SSO doit relier realms, clients, users, groups, rôles, scopes, mappers, tokens, sessions, events et admin events. Le bon connecteur évite les droits fantômes, les refresh tokens non révoqués et les audits IAM impossibles à expliquer au support sécurité et métier interne.
SAML et OpenID Connect répondent à des environnements B2B différents selon applications, identités et capacité des partenaires. L’article compare flux, signatures, provisioning et exploitation, afin de choisir le protocole réellement supportable plutôt que celui qui paraît le plus moderne sur le papier.
FAQ
Contacter un expert API
Questions fréquentes sur l’intégration OpenID Connect API
Réponses précises sur OpenID Connect, ID Token, subjects, claims, UserInfo, sessions et logout.
Ce qu’on clarifie dès le premier échange
- Les systèmes source et cible à connecter.
- Les flux à sécuriser, leurs volumes et leurs incidents actuels.
- Le bon mode de mission : cadrage, forfait, lots agiles, reprise, hébergement ou run.
La question à poser avant de coder
Si un flux critique décroche demain matin, qui le voit, qui décide, qui corrige et comment prouve-t-on que la reprise n’a pas créé un nouvel incident ?
Quand une application doit accepter un ou plusieurs fournisseurs d’identité, qu’un SaaS rattache ses utilisateurs à des organisations, qu’une migration SSO doit préserver les comptes ou que sessions, claims, clés et logout deviennent difficiles à expliquer en production.
OpenID Connect ajoute une couche d’authentification et d’identité à OAuth 2.0, notamment avec l’ID Token. OAuth 2.0 reste le cadre d’autorisation vers une ressource. Un ID Token reçu par un client et un access token destiné à une API ne sont pas interchangeables.
Le client vérifie la signature avec les clés de l’issuer approuvé, l’algorithme autorisé, iss, aud, azp quand nécessaire, exp, iat et le nonce si la demande en contenait un. Il lie aussi la réponse à la transaction initiée.
L’email est un attribut utile mais mutable et pas une clé globale sûre par défaut. Le rattachement local repose sur la paire issuer + sub, complétée par des règles explicites d’invitation, de liaison et de récupération.
Non. UserInfo sert quand des claims utiles ne sont pas dans l’ID Token ou qu’un besoin de profil le justifie. Sa fréquence dépend de la fraîcheur attendue. Dans tous les cas, son sub doit correspondre exactement à celui de l’ID Token.
Le projet assurance publié décrit une migration Keycloak utilisant OAuth2/OIDC, avec tokens, rôles, sessions et coexistence. Les autres projets affichés prouvent seulement des contextes API adjacents ; ils ne sont pas présentés comme des références OIDC.
On parle concret
Votre SSO ouvre une session, mais pouvez-vous prouver l’identité et sa fermeture ?
En 15 minutes, on peut qualifier un issuer, un Relying Party, la clé de compte locale et le premier contre-test à exécuter avant d’étendre OpenID Connect.