Client et architecture navigateur
Comparer BFF, backend médiateur et client navigateur selon exposition des tokens, cookies, CSRF, XSS, CORS, exploitation et contraintes produit.
API
Intégrateur OAuth 2.0 pour accorder le bon accès à la bonne API
Dawap conçoit le contrat d’autorisation entre client, serveur d’autorisation et API métier. Nous choisissons l’architecture adaptée au navigateur, au mobile, au backend ou à la machine, puis prouvons redirect URI, PKCE, audience, scopes, cycle des tokens et fermeture d’accès dans le run réel.
Premier lot OAuth 2.0
Autoriser une opération métier, puis prouver son retrait.
Le pilote choisit un client, une API, une ressource et deux opérations de sensibilité différente. Il couvre l’obtention du token, son usage sur la bonne audience, un refus de scope, la rotation ou l’expiration, puis l’effet mesuré d’une révocation.
Entrée : client et ressource nommés
Sortie : opération et refus prouvés
Run : retrait chronométré de bout en bout
À l’issue du cadrage
- Qualifier le client : navigateur, mobile, backend, batch ou partenaire ; public ou confidentiel ; humain déléguant ou identité machine.
- Définir authorization server, resource server, audience, redirect URI exacte, scopes, consentement et autorisation métier résiduelle.
- Choisir où vivent code verifier, access token et refresh token, qui les renouvelle et comment les secrets ou clés sont distribués.
- Tester injection de code, mauvaise audience, scope absent, refresh rejoué, token volé, révocation non propagée et dépendance indisponible.
Réponse courte
Une intégration OAuth 2.0 relie chaque token à un client, une ressource et une action.
L’intégrateur distingue clients publics et confidentiels, retient Authorization Code avec PKCE pour les parcours concernés ou Client Credentials pour une machine agissant en son nom, restreint audience et scopes, puis organise rotation, détection de rejeu, révocation et validation côté API.
- OAuth 2.0 autorise l’accès à une ressource ; OpenID Connect ajoute l’identité utilisateur et ne doit pas être confondu avec lui.
- Les redirect URIs sont comparées exactement et le navigateur ne reçoit ni secret client prétendument confidentiel ni token inutile.
- La révocation d’un refresh token ne rend pas magiquement inutilisable tout access token déjà émis : la stratégie de fraîcheur doit être mesurée.
4 rôles
resource owner, client, authorization server et resource server séparés dans le contrat
1 audience
chaque token destiné à la ressource attendue et refusé par les autres API
2 familles
access token et refresh token gouvernés selon des risques et des durées différents
0 confiance
dans le seul fait de posséder un token sans vérifier émetteur, destinataire, droit et contexte
Architecture OAuth 2.0
Six contrats avant d’accepter le premier Bearer token
Un access token valide n’est pas encore une autorisation métier correcte. Le client, l’émetteur, la ressource, le droit, la preuve de possession éventuelle et la fraîcheur de la décision doivent rester vérifiables indépendamment.
Authorization Code et PKCE
Imposer une redirect URI exacte, PKCE S256 lié à la transaction et une défense CSRF ou mix-up cohérente ; écarter les flows hérités non justifiables.
Machines et clients confidentiels
Réserver Client Credentials à une machine agissant pour son propre compte ; préférer une authentification client asymétrique quand le risque le justifie.
Audience, scopes et métier
Restreindre le token à la ressource et aux opérations nécessaires, puis conserver dans l’API les contrôles de tenant, ownership, état et plafond.
Rotation et fermeture d’accès
Protéger les refresh tokens par rotation ou liaison à l’émetteur, détecter le rejeu et décrire la latence réelle de révocation des access tokens.
Validation et preuve de possession
Choisir JWT local ou introspection, vérifier issuer, audience, expiration et droits ; évaluer DPoP ou mTLS pour limiter le rejeu d’un token volé.
Parcours OAuth 2.0
Quatre contextes qui n’acceptent pas le même flow ni le même run
La bonne architecture dépend de l’endroit où s’exécute le client, de la présence d’un utilisateur, de la capacité à protéger une clé et du délai acceptable pour fermer un accès.
Garder les tokens hors du navigateur quand le BFF est possible
Faire du backend le client OAuth confidentiel, protéger la session par cookie et relayer uniquement les appels nécessaires vers l’API.
Le navigateur ne manipule pas directement les access et refresh tokens.Déléguer une capacité sans ouvrir tout le compte
Relier consentement, scopes, resource indicator, tenant et autorisation métier, avec retrait par client ou grant.
Le partenaire n’obtient que la ressource et l’opération convenues.Donner une identité propre à chaque traitement
Utiliser Client Credentials avec audience bornée, scopes de service, clé ou certificat rotatif et attribution technique.
Un batch compromis ne devient pas l’identité d’un utilisateur ni de toutes les machines.Retirer implicit ou password grant sans casser les consommateurs
Inventorier bibliothèques, callbacks et stockages, introduire Authorization Code avec PKCE ou un BFF, puis mesurer l’extinction du flow ancien.
Le risque historique diminue client par client avec rollback explicite.Scénarios de recette OAuth 2.0
Trois contre-tests qui révèlent un contrat d’autorisation trop faible
Ces scénarios complètent notre référence publique OAuth2/OIDC sur Keycloak. Ils sont adaptés à l’authorization server, aux profils de tokens, aux bibliothèques clientes et aux API de votre environnement.
Le code ne quitte pas la transaction qui l’a demandé
La recette modifie host, chemin ou paramètre de redirect URI, présente un code issu d’une autre transaction et tente un downgrade PKCE. Le client et le serveur refusent avant toute création de session ou utilisation de token.
À auditer
Client ID, redirect URI enregistrée et reçue, code challenge S256, code verifier, state ou nonce, issuer de réponse, session navigateur et open redirect éventuel.
Livrable
Registre exact des callbacks et matrice de refus contre injection, mix-up, CSRF, open redirect et réutilisation du code.
Traces
Transaction, client, issuer, callback, méthode PKCE, résultat d’échange, session créée ou refusée et cause normalisée.
Décision
Bloquer le go-live si un motif large, un callback relais ou une transaction non liée permet d’échanger le code.
Le rejeu ferme la famille sans masquer l’incident
Deux acteurs présentent successivement l’ancien refresh token. Le serveur détecte la réutilisation, invalide la chaîne concernée, refuse le renouvellement suivant et permet au support d’identifier client, grant et utilisateur sans journaliser le secret.
À auditer
Stockage, liaison client, rotation, famille de tokens, concurrence légitime, détection de rejeu, événement de sécurité, UX de reconnexion et révocation.
Livrable
Contrat de rotation avec états, fenêtre de concurrence assumée, alerte, réponse utilisateur et procédure de confinement.
Traces
Empreinte non réversible, client, grant, séquence, premier usage, rejeu, famille révoquée, accès résiduel et délai de fermeture.
Décision
Ne pas émettre de refresh token à un client public tant que rotation ou liaison cryptographique et reprise ne sont pas prouvées.
La possession du Bearer token ne suffit pas à élargir l’accès
Un access token prévu pour l’API catalogue est présenté à l’API paiement, puis après retrait du grant. La mauvaise audience est refusée immédiatement et la durée d’accès résiduelle est mesurée selon introspection, cache ou expiration locale.
À auditer
Issuer, audience ou resource, scopes, tenant, subject client ou utilisateur, algorithme, JWKS ou introspection, cache, DPoP ou mTLS et règle métier.
Livrable
Matrice ressource-action avec validation commune, tests croisés, stratégie de fraîcheur, contrôle compensatoire et SLO de révocation.
Traces
API cible, empreinte, issuer, audience, scope, preuve de possession, décision protocolaire, décision métier et latence après retrait.
Décision
Refuser le lancement si une API accepte un token destiné ailleurs ou si le délai de fermeture d’une opération sensible reste inconnu.
Intentions traitées
Pourquoi une équipe cherche un intégrateur OAuth2
Le besoin se révèle quand plusieurs clients partagent des scopes, qu’un token circule dans le navigateur, qu’un partenaire demande une délégation ou qu’une révocation ne ferme pas l’accès au rythme attendu.
Relier clients, authorization server, resource servers, flows, tokens, opérations métier, sécurité et run.
Arbitrer BFF ou client navigateur, Authorization Code, PKCE S256, session cookie, CSRF, XSS et exposition des tokens.
Attribuer une identité par workload, une ressource, des scopes, une clé rotative et une preuve exploitable.
Livrables OAuth 2.0
Ce que Dawap met en place pour une autorisation réellement exploitable
Le livrable relie le protocole au droit métier et au run. Chaque client sait ce qu’il peut demander, chaque API ce qu’elle doit vérifier et le support comment prouver puis fermer un accès.
- Cartographie des clients, owners, environnements, redirect URIs, authorization servers, resource servers, audiences, scopes, grants et opérations sensibles.
- Architecture navigateur et mobile documentée : BFF, médiation ou client public, Authorization Code, PKCE S256, protection CSRF, issuer et stockage.
- Contrat machine-to-machine : Client Credentials, subject technique, audience, scopes, private_key_jwt ou mTLS, rotation, inventaire et retrait.
- Profil des tokens et validation API : opaque ou JWT, issuer, audience, expiration, algorithmes, JWKS, introspection, cache, DPoP éventuel et erreurs.
Méthode
On part de l’opération protégée, pas du token endpoint
Nous choisissons une action réelle — lire un dossier, exporter un catalogue, déclencher un paiement — puis remontons vers la ressource, le scope, l’audience, le client et le grant. Cette lecture empêche le protocole de remplacer l’autorisation métier ou de masquer une ouverture trop large.
Résultats attendus
- Un flow justifié pour chaque type de client et non choisi par héritage.
- Des callbacks exacts et des transactions Authorization Code protégées par PKCE.
- Des audiences et scopes liés aux API et opérations réellement nécessaires.
- Des refresh tokens protégés contre le rejeu et attribués à leur grant.
Maillage autorisation et identité
Approfondir la frontière qui porte réellement la confiance
OAuth 2.0 organise l’autorisation. L’identité, la fédération, le produit IAM et la création de l’API déplacent les responsabilités sans rendre les contrôles interchangeables.
Des projets jugés sur la capacité à rendre les flux exploitables.
Cadrage clair
On nomme les objets, les responsabilités et le premier flux qui réduit vraiment le risque.
Développement robuste
On construit des connecteurs maintenables, testables et compréhensibles par les équipes.
Run maîtrisé
On garde de la visibilité après la mise en production : logs, alertes, reprises et suivi.
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, tokens, rôles et sessions. Les trois autres projets illustrent des contraintes B2B, comptes, droits et flux API, sans être présentés comme des implémentations OAuth 2.0.
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.
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.
OAuth 2.0 machine-to-machine sécurise les flux serveur à serveur lorsque identité du client, scopes et durée des jetons sont précisément définis. Le raisonnement permet de gérer émission, cache et rotation, afin qu’un service accède uniquement aux API nécessaires sans partager un secret permanent inutilement trop large.
Un scope admin ou write global transforme chaque connecteur en pouvoir latent sur toutes les données. Une matrice construite depuis les opérations métier sépare ressource, action, audience, tenant et risque. Voici comment nommer, attribuer, appliquer, tester, observer et faire évoluer les scopes OAuth sans déplacer l’autorisation dans des conventions impossibles à auditer.
API keys, OAuth et mTLS offrent des niveaux différents d’identité, délégation et exploitation pour une intégration partenaire. Pour obtenir un résultat fiable, mieux vaut comparer menace, cycle de vie, infrastructure et support, afin de choisir un mécanisme proportionné sans imposer une complexité que le partenaire ne saura pas maintenir.
FAQ
Contacter un expert API
Questions fréquentes sur l’intégration OAuth 2.0 API
Réponses précises sur OAuth 2.0, applications navigateur, clients machine, tokens et révocation.
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 plusieurs applications ou partenaires appellent vos API, qu’un ancien flow doit être retiré, que scopes et audiences sont trop larges, que des tokens vivent dans le navigateur ou que la fermeture d’un accès reste impossible à mesurer.
OAuth 2.0 est un framework d’autorisation d’accès à des ressources. OpenID Connect ajoute la couche d’authentification et d’identité avec notamment ID Token, subject et nonce. Un access token ne doit pas être détourné en preuve générique de login.
Un BFF peut conserver les tokens côté serveur et exposer une session cookie au navigateur. Un backend médiateur ou un client OAuth dans le navigateur répondent à d’autres contraintes et exposent davantage les tokens. Le choix dépend du modèle de menace et du produit.
Non. Le client agit en son propre nom, sans resource owner impliqué. L’API doit reconnaître une identité de workload, une audience et des scopes dédiés, sans fabriquer un utilisateur humain fictif.
Pas nécessairement. Un access token déjà émis peut rester accepté jusqu’à expiration ou jusqu’à une décision d’introspection ou de cache plus fraîche. Le délai réel est conçu, testé et surveillé selon la sensibilité de l’opération.
Le projet assurance publié décrit une migration Keycloak utilisant OAuth2/OIDC, les tokens, rôles et sessions. Les autres projets de cette page prouvent seulement des contraintes API adjacentes ; ils ne sont pas présentés comme des références OAuth 2.0.
On parle concret
Vos tokens passent, mais personne ne prouve la ressource, le droit et leur retrait ?
En 15 minutes, on peut qualifier un client, une opération, son audience, son flow et le premier contre-test à exécuter avant d’élargir les accès.