Guide sur l’enregistrement d’application et OAuth pour une intégration sécurisée

By Mirko Peters · 2026-05-04

Enregistrez votre application avec OAuth 2.0. Comprenez le flux de code d’autorisation pour un accès sécurisé, un élément clé de l’octroi de code d’autorisation OAuth 2.0.

Automatically translated with AI from the original post. Read the English original

Soyons honnêtes : réussir l’authentification et l’enregistrement d’application ne se résume pas à suivre des protocoles astucieux ; il s’agit de garantir que vos utilisateurs, vos données et votre organisation restent protégés. Ce guide démystifie l’enregistrement d’application et OAuth 2.0, afin que vous puissiez mettre en place une authentification sécurisée et conforme aux standards avec Microsoft Entra ID (anciennement Azure AD) ou le fournisseur de votre choix.

Nous détaillons les étapes et les notions dont vous avez besoin, de la compréhension des raisons d’être d’OAuth à la mise en œuvre concrète sur des applications web, mobiles ou SaaS. Vous y trouverez des définitions claires, des conseils pratiques et une feuille de route conçue pour garder votre intégration sur les rails et éviter les erreurs courantes qui piègent les développeurs qui découvrent OAuth. Que vous exploriez le sujet pour la première fois ou que vous peaufiniez une configuration d’entreprise avancée, vous êtes au bon endroit pour bâtir en toute confiance et comprendre les identifiants nécessaires à votre application.

Guide sur l’enregistrement d’application et OAuth — Définition

L’enregistrement d’application est le processus de création et de configuration d’une identité d’application auprès d’un fournisseur d’identité (comme Azure AD, Google ou Auth0), afin que l’application puisse demander de manière sécurisée une authentification et une autorisation. Il implique généralement d’attribuer un ID client, un secret client ou un certificat, de définir les URI de redirection, de configurer les autorisations et les étendues (scopes), et de paramétrer les types d’octroi autorisés.

8 faits surprenants sur l’enregistrement d’application et le guide OAuth

• Les secrets client peuvent fuir dans les journaux : de nombreux développeurs consignent sans le savoir les ID client et les secrets pendant le débogage, ce qui rend les identifiants de l’enregistrement d’application vulnérables si les stratégies de journalisation ne sont pas renforcées. Traitez toujours les identifiants avec précaution.
• Les URI de redirection sont plus stricts que vous ne le pensez : les fournisseurs OAuth exigent souvent une correspondance exacte des URI de redirection (y compris les barres obliques finales et le schéma). De légères différences peuvent donc casser des flux qui semblent correctement configurés dans votre enregistrement d’application.
• Les clients publics n’ont pas besoin de secrets, mais doivent tout de même être protégés : les applications natives et les applications monopage sont considérées comme des clients publics sans secret client ; elles doivent néanmoins utiliser PKCE et des approches sécurisées pour les URI de redirection afin d’empêcher l’interception du code.
• Les étendues ne garantissent pas le moindre privilège par défaut : lors de l’enregistrement d’applications, les étendues par défaut ou les écrans de consentement peuvent demander des autorisations étendues. Des restrictions explicites d’étendues et un consentement progressif sont indispensables pour appliquer le principe du moindre privilège.
• La révocation des jetons n’est pas prise en charge partout : tous les fournisseurs d’identité ne respectent pas la révocation des jetons ni ne proposent une déconnexion immédiate sur l’ensemble des sessions. L’enregistrement d’application doit donc inclure une gestion des sessions et des stratégies de jetons d’actualisation.
• Les métadonnées de l’enregistrement d’application constituent une surface d’attaque : les noms, logos et URI de redirection d’application exposés publiquement peuvent aider les attaquants à élaborer des campagnes d’hameçonnage convaincantes ou des attaques par redirection ouverte s’ils ne sont pas soigneusement gérés.
• L’approvisionnement automatisé peut mal configurer les autorisations : les automatisations CI/CD qui créent des enregistrements d’application accordent souvent des autorisations d’API trop permissives ou n’enregistrent pas les URI de redirection requis, ce qui entraîne des échecs silencieux ou une exposition en matière de sécurité.
• L’expérience de consentement influence les décisions de sécurité : les utilisateurs et les administrateurs accordent fréquemment un consentement large, car les boîtes de dialogue de consentement sont peu claires ; concevoir des demandes de consentement claires et minimales dans l’enregistrement d’application et le guide OAuth réduit l’octroi excessif d’accès.

Comprendre les fondamentaux d’OAuth 2.0 et d’Entra ID

OAuth 2.0 constitue le socle des flux d’authentification modernes : il permet aux applications d’accéder en toute sécurité aux données et aux ressources des utilisateurs, sans jamais voir de mot de passe. Voici un aperçu du fonctionnement du processus. Au cœur du protocole, OAuth 2.0 définit la manière dont un utilisateur (le « propriétaire de la ressource »), une application (le « client ») et un fournisseur d’identité (le « serveur d’autorisation ») collaborent, afin que les utilisateurs gardent le contrôle de leurs informations.

Mais que se passe-t-il lorsque vous souhaitez authentifier les utilisateurs, et non plus seulement autoriser l’accès aux données ? C’est là qu’intervient OpenID Connect, qui ajoute une couche d’identité et de connexion sécurisées au-dessus d’OAuth 2.0. Grâce à OpenID Connect, des fournisseurs comme Microsoft Entra ID et Google permettent à vos applications de vérifier l’identité des utilisateurs et de demander des autorisations ciblées pour accéder à d’autres ressources, dans une expérience unifiée.

Si vous rencontrez des termes comme « ID client », « point de terminaison d’autorisation » ou « jeton d’accès », ne vous laissez pas submerger. Ils renvoient tous à une même question : qui communique avec qui, et que lui est-il permis de faire ? Microsoft Entra ID utilise précisément ces protocoles pour offrir aux développeurs un socle conforme aux standards, adapté aussi bien aux applications métier mono-locataire qu’aux produits SaaS multi-locataires à très grande échelle.

Maîtriser ces fondamentaux, c’est construire sur des bases éprouvées. Choisir le flux OAuth adapté à votre scénario (par exemple, le flux de code pour les applications web ou le flux d’appareil pour les téléviseurs connectés) garantit une connexion simple et sécurisée, en laquelle les utilisateurs peuvent avoir confiance et que vos équipes de conformité apprécieront.

Guide d’enregistrement d’applications et d’OAuth : les erreurs courantes avec OAuth 2.0 et Entra ID

Ce guide d’enregistrement d’applications et d’OAuth recense les erreurs fréquentes commises par les équipes lors de la mise en œuvre d’OAuth 2.0 avec Microsoft Entra ID (Azure AD), ainsi que leurs conséquences sur la sécurité, le fonctionnement et l’expérience utilisateur.

• Mélanger les concepts d’OAuth 2.0 et d’OpenID Connect (par exemple, s’attendre à recevoir des jetons ID là où seuls des jetons d’accès sont émis).
• Utiliser incorrectement les flux OAuth, en considérant le flux implicite comme adapté aux applications modernes, au lieu du code d’autorisation avec PKCE.

• Enregistrer incorrectement les URI de redirection (mauvais schéma, barre oblique finale ou utilisation de localhost en production).
• Utiliser les paramètres de client public pour des applications confidentielles, ou inversement, ce qui provoque des erreurs de jetons ou expose des secrets.
• Ne pas définir les autorisations d’API ou les étendues (scopes) appropriées, ou oublier d’accorder le consentement administrateur lorsque celui-ci est requis.

• Intégrer des secrets client dans du code côté client ou dans des dépôts publics.
• Ne pas renouveler régulièrement les secrets ou certificats, ou ne pas supprimer les identifiants expirés de l’enregistrement de l’application.
• Utiliser inutilement des secrets à longue durée de vie plutôt que des certificats à courte durée de vie ou des identités managées.

• Ne pas valider correctement les jetons (émetteur, audience, signature, nonce, exp).
• Stocker les jetons d’accès ou d’actualisation de manière non sécurisée (par exemple, dans le stockage local du navigateur sans protection).
• Faire confiance au contenu des jetons sans vérifier les étendues (scopes) et les rôles renvoyés par Entra ID.

• Supposer que le consentement de l’utilisateur équivaut à l’autorisation de l’application, sans réaliser que certaines autorisations exigent le consentement administrateur.
• Demander un nombre excessif d’autorisations ou d’étendues, ce qui entraîne un risque inutile et un taux de refus plus élevé lors du consentement.

• Ne pas gérer la rotation et les stratégies de révocation des jetons d’actualisation définies dans Entra ID, ce qui provoque des déconnexions inattendues.
• Utiliser des jetons d’actualisation dans des clients publics sans protections appropriées (utilisez PKCE et des durées de vie de jetons adaptées).

• Ne pas configurer correctement les paramètres multi-locataires pour les applications destinées à fonctionner sur plusieurs locataires.
• Utiliser les mauvais points de terminaison (propres au locataire ou common) et rencontrer des problèmes de connexion ou de consentement.

• Ne pas tester le comportement de l’application lorsque les stratégies d’accès conditionnel, l’authentification multifacteur ou les stratégies de conformité des appareils sont appliquées.
• Supposer que les jetons seront toujours émis dans les mêmes conditions, alors que les stratégies peuvent bloquer ou exiger des étapes d’authentification supplémentaires.

• Suivre des flux OAuth hérités ou des schémas Azure AD v1 au lieu des recommandations de la plateforme d’identité Microsoft (v2).
• Utiliser des exemples communautaires sans vérifier qu’ils mettent en œuvre des pratiques sécurisées (PKCE, stockage sécurisé, validation appropriée).

• Ne pas journaliser les échecs d’authentification ni les erreurs d’émission de jetons, ce qui rend le diagnostic difficile.
• Afficher des messages d’erreur bruts aux utilisateurs au lieu de les traduire en indications exploitables.

Utilisez ce guide sur l’inscription d’applications et OAuth pour vérifier votre implémentation, suivre les bonnes pratiques de la plateforme d’identité Microsoft et réduire les risques de sécurité et d’exploitation lors de l’intégration d’OAuth 2.0 avec Entra ID.

Prérequis à l’inscription d’une application pour la configuration d’OAuth

Avant de commencer les écrans d’inscription et de copier-coller le nom de votre application dans un portail, vérifiez quelques incontournables. Tout d’abord, vous devez disposer d’un accès au Centre d’administration Microsoft Entra de votre organisation, ou à la console appropriée du fournisseur d’identité que vous utilisez : pas de raccourci possible. Sans les autorisations nécessaires, vous vous heurterez à un mur avant même d’avoir franchi la porte.

Ensuite, décidez du type d’application que vous développez et des identifiants nécessaires à son fonctionnement. S’agit-il d’une application web, d’une application monopage, d’une application mobile ou peut-être d’un service automatisé ? Chaque type a ses propres exigences en matière d’authentification et d’autorisation. Faire ce choix en amont conditionne les paramètres de sécurité que vous sélectionnerez plus tard.

Il est également important de définir qui utilisera votre application. Sera-t-elle réservée aux personnes de votre organisation (locataire unique) ? Ou doit-elle servir des utilisateurs d’autres entreprises ou le grand public (multilocataire) ? Cela influe sur les paramètres d’inscription, les annuaires d’utilisateurs applicables et le flux de consentement que verront vos utilisateurs.

Enfin, rassemblez les détails techniques, comme les URL autorisées pour les redirections de connexion, les plateformes que vous prendrez en charge (iOS, Android, Windows ?) et les autorisations (ou « étendues ») que votre application devra demander. Regrouper ces informations vous fait gagner un temps considérable lors de la configuration et évite des pièges courants, comme des URI non valides ou des types de comptes incohérents par la suite.

Comment inscrire votre application auprès de Microsoft Entra ID

Inscrire votre application dans Microsoft Entra ID (anciennement Azure AD) pose les bases de toute l’authentification et de l’accès aux API. Le processus commence dans le Centre d’administration Entra, où vous créez une nouvelle inscription d’application, ce qui attribue à votre application une identité unique (appelée « ID client ») au sein de l’annuaire de votre organisation.

Vous saisissez un nom pour votre application, puis vous sélectionnez qui peut l’utiliser : uniquement votre organisation, plusieurs organisations ou n’importe quel compte Microsoft. Cette étape est cruciale, en particulier pour les applications SaaS et B2B, car elle détermine la portée de votre application et la manière dont le consentement du locataire est géré.

Une fois le public défini, vous configurez les paramètres de plateforme de votre application. Pour les applications web, vous ajoutez un URI de redirection ; pour les applications mobiles ou monopage, des paramètres propres à chaque plateforme garantissent une expérience de connexion fluide. Le portail Entra vous guide dans l’ajout des identifiants, tels que les secrets client ou les certificats, que votre application utilisera pour prouver son identité.

Finaliser l’inscription aligne votre application sur les normes OAuth 2.0 et garantit que votre flux d’authentification reste sécurisé et conforme. Que vous optiez pour un locataire unique ou que vous visiez le multilocataire, comprendre ces paramètres dès le départ pose des bases solides pour l’évolution et les besoins d’intégration futurs.

Principaux avantages de l’inscription de votre application dans Microsoft Entra ID

• Gestion centralisée des identités : gérez l’authentification, l’autorisation et les identités des utilisateurs de votre application depuis un seul locataire Entra ID.
• Flux OAuth sécurisés : profitez de la prise en charge intégrée d’OAuth 2.0 et d’OpenID Connect pour mettre en œuvre une connexion sécurisée, l’émission de jetons et l’accès délégué.
• Authentification unique (SSO) : offrez une authentification unique fluide dans Microsoft 365, Azure et les autres services intégrés, pour améliorer l’expérience utilisateur et réduire les demandes de mot de passe.
• Contrôle granulaire des autorisations : définissez et gérez des autorisations d’API précises, les expériences de consentement et un accès selon le principe du moindre privilège, tant pour les autorisations déléguées que pour les autorisations d’application.
• Accès conditionnel et stratégies de sécurité : imposez l’authentification multifacteur, la conformité des appareils, les conditions de localisation et les stratégies fondées sur le risque pour protéger l’accès aux applications et les données sensibles.
• Secrets et identifiants d’application gérés : stockez et renouvelez en toute sécurité les secrets client, les certificats et la configuration multilocataire, en appliquant des pratiques de gestion du cycle de vie afin de préserver l’intégrité des usages applicatifs.
• Intégration aux services de la plateforme Microsoft : accédez à Microsoft Graph, aux API Azure, à Teams et aux autres fonctionnalités de la plateforme à l’aide de jetons standardisés et de modèles de consentement.
• Prise en charge des applications hybrides et multiplateformes : authentifiez les utilisateurs sur le web, sur mobile, sur ordinateur et dans les scénarios service à service, avec des protocoles d’identité cohérents, en veillant à ce que chaque application utilise les identifiants appropriés.
• Surveillance et audit : exploitez les journaux, les rapports de connexion et les informations de sécurité pour détecter les anomalies, enquêter sur les incidents et maintenir la conformité.
• Évolutivité et aptitude au déploiement en entreprise : tirez parti de l’infrastructure mondiale d’Entra ID, des options multilocataires et des fonctionnalités d’entreprise pour accompagner la croissance du nombre d’utilisateurs et la complexité des organisations.
• Outils de développement et documentation : profitez des kits SDK, des exemples de code et du guide d’inscription d’application & OAuth pour accélérer la mise en œuvre et résoudre les scénarios courants.

Configuration des URI de redirection et des paramètres de plateforme pour les applications Entra ID

Définir les bons URI de redirection lors de l’inscription de l’application semble simple, mais cette étape est déterminante pour la sécurité. Les URI de redirection indiquent à Entra ID où envoyer les utilisateurs (avec leurs jetons) après une tentative de connexion réussie. Lors de leur configuration, Entra applique des règles strictes : aucun domaine générique, aucun schéma d’URI dangereux et aucun élément laissé au hasard que des attaquants pourraient exploiter.

Si vous développez une application monopage (SPA), vous utiliserez généralement une URL HTTPS pointant vers le domaine de votre application, afin de garantir une communication sécurisée pour l’obtention des données. Les applications natives nécessitent des schémas d’URI liés au nom du bundle ou du package de votre application, ce qui empêche des applications quelconques de détourner les jetons sur le même appareil. Les applications web utilisent généralement leurs points de terminaison de rappel de connexion, chacun devant être explicitement répertorié.

Les erreurs de configuration entraînent les classiques erreurs « redirect URI mismatch » et, pire encore, ouvrent la porte à des attaquants capables d’intercepter les jetons. Prendre le temps de recenser chaque plateforme sur laquelle votre application s’exécutera, ainsi que les URI de redirection correspondants, contribue à assurer une authentification fluide et une tranquillité d’esprit.

Pensez à mettre à jour l’inscription de votre application chaque fois que vous modifiez les URL client, ajoutez des plateformes ou étendez les environnements (comme les environnements de test et de production). Maintenir ces URI verrouillés et bien ordonnés constitue la première étape pour garantir l’étanchéité de votre flux de jetons.

Notions essentielles sur les flux OAuth et la gestion des jetons

OAuth 2.0 repose sur un ensemble de flux d’autorisation qui répondent à des cas d’usage variés : connexions web, authentifications mobiles, appels serveur à serveur ou applications fonctionnant sans utilisateur présent. Le plus répandu et le plus sûr d’entre eux est le flux de code d’autorisation, conçu pour empêcher les jetons sensibles de se retrouver dans les navigateurs et les applications mobiles, en plaçant la sécurité au premier plan.

Une fois l’utilisateur authentifié et son consentement accordé, votre application reçoit un code de courte durée. Elle doit échanger ce code au niveau du point de terminaison de jeton pour obtenir des jetons d’accès et d’actualisation. Ces jetons accordent un accès limité dans le temps aux données : à leur expiration, le jeton d’actualisation peut demander un nouveau jeton d’accès afin de maintenir votre session active.

La gestion des jetons ne se limite pas au traitement des dates d’expiration ; il s’agit de préserver la sécurité des jetons à chaque étape. Cela implique d’utiliser une communication sécurisée (par exemple HTTPS), de ne jamais exposer de secrets dans le code côté client et d’appliquer le principe du moindre privilège lors de la demande d’étendues d’autorisation.

Cette section vous permet de comprendre comment OAuth gère les échanges critiques entre utilisateurs, applications et plateformes, et comment une gestion robuste des jetons soutient des flux de travail persistants et sécurisés, aussi bien pour les utilisateurs finaux que pour les systèmes automatisés.

Mise en œuvre du flux de code d’autorisation OAuth

1. Lancer l’autorisation : votre application redirige l’utilisateur vers le point de terminaison d’autorisation d’Entra ID, en incluant des informations telles que votre ID client, les étendues demandées et un paramètre state unique et aléatoire pour la protection contre les attaques CSRF.
2. Octroi de l’autorisation par l’utilisateur : l’utilisateur examine l’écran de consentement, qui indique clairement les autorisations dont votre application a besoin, puis approuve l’accès.
3. Recevoir le code d’autorisation\u00a0: après le consentement, Entra ID redirige vers l’URI de redirection que vous avez spécifiée, en transmettant un code d’autorisation temporaire ainsi que la valeur state que vous aviez définie au départ.
4. Échanger le code contre des jetons\u00a0: votre backend envoie en toute sécurité le code, accompagné de vos informations d’identification client (et du vérificateur de code PKCE le cas échéant), au point de terminaison de jetons d’Entra. Si la vérification réussit, vous obtenez des jetons d’accès (et souvent des jetons d’actualisation).
5. Utiliser les jetons pour accéder aux API\u00a0: votre application joint désormais le jeton d’accès à chaque requête d’API, ce qui prouve l’autorisation accordée au nom de l’utilisateur. Les jetons d’accès ne sont valables que pendant une courte durée, ce qui limite l’exposition, tandis que les jetons d’actualisation permettent d’obtenir de nouveaux jetons d’accès pour les sessions en cours.

Respecter ces étapes dans le bon ordre permet de colmater les failles de sécurité et d’empêcher des attaques telles que l’interception de codes ou l’utilisation abusive de jetons, en particulier lorsque vous travaillez avec des clients publics ou manipulez des données sensibles.

Bonnes pratiques pour la gestion de l’expiration des jetons d’accès et d’actualisation

1. Stocker les jetons en toute sécurité\u00a0: utilisez des solutions de stockage sécurisées fournies par le système d’exploitation, comme Keychain sur iOS, Keystore sur Android, ou des gestionnaires de secrets chiffrés côté serveur. Ne codez jamais les jetons en dur dans les binaires de l’application et ne les exposez jamais dans les journaux.
2. Respecter la durée de vie des jetons\u00a0: surveillez la valeur d’expiration (revendication exp) de chaque jeton et actualisez-le de manière proactive avant qu’il n’expire, afin d’éviter les requêtes d’API en échec et une mauvaise expérience utilisateur.
3. Prendre en charge la rotation des jetons\u00a0: utilisez systématiquement le jeton d’actualisation le plus récent à chaque requête et rejetez rapidement les jetons réutilisés ou périmés. Cela limite les conséquences en cas de compromission d’un jeton.
4. Limiter les autorisations par jeton\u00a0: ne demandez que les étendues dont vous avez besoin et privilégiez des jetons d’accès à courte durée de vie. Cela réduit considérablement les dégâts si un jeton venait à fuiter ou à être volé.

Sécuriser les implémentations OAuth selon les contextes

Réussir une intégration OAuth ne se résume pas à cocher des étapes\u00a0: il s’agit de mettre en place plusieurs couches de sécurité adaptées à l’architecture de votre application et à ses modes d’utilisation. Qu’elle s’exécute dans le navigateur, sur un téléphone ou uniquement dans le cloud, chaque contexte requiert une stratégie d’authentification adaptée.

Des technologies comme PKCE (Proof Key for Code Exchange) sécurisent le flux d’autorisation pour les clients publics, en empêchant les attaquants d’intercepter les codes et de les échanger contre des jetons. En revanche, pour les applications qui s’exécutent dans des environnements sécurisés, les secrets client et les certificats constituent vos meilleurs outils pour attester de l’identité et gérer la confiance.

Un stockage maîtrisé des jetons et une attention rigoureuse aux niveaux de privilèges évitent les fuites accidentelles et limitent l’impact potentiel en cas d’incident. En choisissant les bons outils de sécurité (PKCE, secrets, certificats et étendues bien définies), vous réduisez considérablement votre surface d’attaque et augmentez vos chances d’un fonctionnement fluide et conforme.

Les stratégies présentées ci-après ont fait leurs preuves pour contrer les menaces courantes et adapter votre configuration OAuth à une protection robuste, quel que soit le type d’application ou d’environnement.

Comment PKCE protège l’autorisation OAuth dans les clients publics

PKCE (Proof Key for Code Exchange) est essentiel lorsque OAuth est utilisé dans des applications mobiles et des applications web basées sur navigateur, c’est-à-dire des clients publics pour lesquels le stockage d’un secret n’est pas envisageable. Lorsque vous lancez le flux d’autorisation par code, votre application génère un « vérificateur de code » aléatoire et un « défi de code » haché. Ces valeurs accompagnent l’utilisateur jusqu’à la requête finale de jeton. Même si un attaquant s’empare d’un code d’autorisation, il ne peut pas l’échanger contre un jeton sans ce vérificateur secret, ce qui rend les attaques par interception de codes quasiment impossibles sur Microsoft Entra ID et les plateformes similaires.

Gérer les secrets client, les certificats et les informations d’identification fédérées

• Secrets client\u00a0: utilisés par les applications confidentielles, comme les services backend de confiance, pour prouver leur identité au point de terminaison de jetons. Stockez les secrets dans des coffres sécurisés, renouvelez-les régulièrement et ne les intégrez jamais au code client de l’application.
• Certificats\u00a0: pour un niveau d’assurance supérieur, utilisez des certificats X.509 plutôt que de simples secrets afin de renforcer la sécurité des identifiants de votre application. Les certificats permettent une validation plus sûre grâce à des paires de clés publique/privée et sont idéaux pour les secteurs réglementés ou les applications soumises à des exigences de conformité strictes.
• Informations d’identification fédérées\u00a0: pour les configurations « apportez votre propre identité », utilisez des informations d’identification fédérées, comme l’identité fédérée de Microsoft Entra ou des fournisseurs externes. Cela permet de s’authentifier sans manipuler directement de secrets, ce qui réduit la charge de gestion.
• Gestion dans les pipelines\u00a0: dans les workflows CI/CD, injectez et renouvelez les secrets et certificats selon les besoins, sans jamais les coder en dur dans le contrôle de source. Des alertes automatiques d’expiration ajoutent une couche de résilience supplémentaire.

Sécuriser les jetons et réduire l’exposition aux priviléges

• Stockez les jetons uniquement dans des emplacements sécurisés (coffres du système d’exploitation, environnements serveur chiffrés), jamais dans un espace de stockage accessible aux utilisateurs.
• Transmettez toujours les jetons via HTTPS ou des canaux sécurisés : le HTTP en clair expose les jetons à l’interception.
• Demandez des autorisations minimales (« scopes ») pour chaque jeton : ne demandez jamais davantage que ce dont votre application a besoin.
• Auditez régulièrement l’utilisation des jetons et l’attribution des priviléges afin d’éviter une extension silencieuse des autorisations.

Bonnes pratiques OAuth pour les applications mobiles et natives

Les applications mobiles et natives présentent aujourd’hui des difficultés particulières : les appareils se perdent, les applications partagent un espace de stockage et les utilisateurs attendent une authentification rapide, presque invisible. C’est pourquoi suivre les bonnes pratiques OAuth sur iOS, Android et ordinateur de bureau, en s’appuyant sur les SDK intégrés et des mécanismes de stockage éprouvés, fait toute la différence.

Le bon SDK (comme MSAL pour Microsoft Entra ID) prend en charge une grande partie du travail difficile : gestion des jetons, logique de renouvellement et intégration au stockage sécurisé du système d’exploitation. Pour les jetons sensibles, ces SDK déterminent par défaut le dépôt le plus sûr, en gérant les particularités propres à chaque appareil ou système d’exploitation.

Ne négligez pas l’expérience utilisateur fluide : les liens universels, les liens profonds et les flux via le navigateur système aident les utilisateurs à terminer l’authentification sans confusion ni risque d’hameçonnage. Bien configurée, votre application transfère l’utilisateur vers une vue web système sécurisée et fiable, puis le ramène en toute sécurité dans l’application une fois la connexion terminée, sans fenêtres contextuelles ni fuite de jetons.

Ces pratiques visent non seulement à protéger les jetons, mais aussi à renforcer la confiance des utilisateurs, ce qui favorise l’adoption et réduit les difficultés de support à long terme.

Liens universels et authentification native de première partie

Les liens universels (sur iOS) et les schémas d’application (sur Android) rendent l’authentification des utilisateurs bien plus sûre. En utilisant des liens vérifiés par le système d’exploitation et liés à l’identité de votre application, vous empêchez les applications malveillantes d’intercepter les redirections d’authentification et de récupérer des jetons qui ne leur appartiennent pas. L’authentification native s’appuie sur des navigateurs système de confiance : c’est bien le véritable utilisateur qui se connecte, ce qui écarte l’hameçonnage, l’espionnage des jetons et les connexions accidentelles entre applications sans rapport. Combinés, ces outils offrent à l’utilisateur une expérience fluide et sécurisée, presque à toute épreuve face aux menaces courantes liées à OAuth sur mobile.

Dépanner les erreurs OAuth et les scénarios avancés

Les intégrations OAuth se déroulent rarement parfaitement du premier coup : erreurs et cas limites particuliers font partie du jeu. Bien souvent, les problèmes proviennent de non-concordances d’URI de redirection, de codes expirés ou de secrets client erronés, qui peuvent bloquer les flux d’authentification et affecter l’utilisation des applications. Cette section vous aidera à interpréter les réponses d’erreur, à retracer les échanges en échec et à résoudre les problèmes avant qu’ils n’atteignent votre service d’assistance.

Au-delà des bases, certains scénarios, comme la communication serveur à serveur entre applications, la connexion d’appareils IoT ou le besoin de garanties de protocole plus fortes, exigent des extensions OAuth spécialisées ou des flux non interactifs. Les comptes de service, le TLS mutuel et le flux de code d’appareil sont spécialement conçus pour répondre à ces besoins.

Grâce à des conseils portant à la fois sur les défaillances courantes et sur les cas d’usage avancés, vous serez mieux armé pour diagnostiquer, concevoir et maintenir des solutions OAuth robustes, même lorsque votre écosystème d’applications gagne en complexité.

Que vous traquiez une erreur persistante sur le point de terminaison de jeton ou que vous prépariez votre application aux aléas du monde réel, où les appareils à saisie limitée et les services sans interface sont omniprésents, ces éléments vous aideront à garder vos intégrations fluides et sécurisées.

Interpréter les réponses d’erreur OAuth et les échecs d’échange de code

• URI de redirection non valide : se produit lorsque la redirection ne correspond pas à la liste enregistrée ; vérifiez attentivement les saisies et la casse.
• Code d’autorisation expiré : les utilisateurs mettent trop de temps ou les codes sont réutilisés ; utilisez-les toujours une seule fois et rapidement après leur réception.
• Identifiants client incohérents : le mauvais secret ou certificat a été fourni ; vérifiez-les et faites-les tourner au besoin.
• Étendue ou ressource non valide : l’API ou les étendues demandées ne sont pas autorisées ou sont mal saisies ; vérifiez la configuration et les autorisations de l’application.

Comptes de service, appareils à saisie limitée et extensions OAuth

• Comptes de service (flux d’identifiants client) : permettent aux applications de s’authentifier sans utilisateur, idéal pour l’automatisation et les tâches serveur à serveur.
• Flux de code d’appareil : destiné aux téléviseurs connectés et aux objets connectés, il invite l’utilisateur à se connecter sur un autre appareil ; adapté aux cas où aucun navigateur n’est disponible.
• Extension TLS mutuel : utilise des certificats côté serveur et côté client, renforçant la sécurité des intégrations sensibles et garantissant que l’application emploie des méthodes d’authentification robustes.
• Inscription dynamique de clients : automatise l’intégration des applications dans les grands systèmes SaaS ou multilocataires et simplifie la gestion des identifiants à grande échelle.

Guide d’inscription d’applications et OAuth dans Entra ID

Avantages

• Gestion centralisée des identités : s’intègre à Microsoft Entra ID pour assurer une identité cohérente des utilisateurs et des applications sur l’ensemble des services.
• Contrôles de sécurité robustes : prend en charge OAuth 2.0, OpenID Connect, l’accès conditionnel et des autorisations granulaires (étendues et rôles).
• Protocoles conformes aux standards du secteur : repose sur les standards OAuth et OIDC largement adoptés, ce qui simplifie l’interopérabilité avec les outils et bibliothèques tiers.
• Configuration détaillée des applications : permet de configurer les URI de redirection, les certificats et secrets, les autorisations d’API et les options d’image de marque des applications.
• Modèle de consentement granulaire : prend en charge les autorisations déléguées et les autorisations d’application, avec des flux de consentement administrateur pour limiter les applications disposant de privilèges excessifs.
• Fonctionnalités pour les entreprises : prend en charge les applications multilocataires, la collaboration B2B et l’intégration avec les services Microsoft 365 et Azure.
• Surveillance et audit : journaux intégrés, connexions et pistes d’audit pour les inscriptions d’applications et les flux OAuth, afin de faciliter la conformité et le dépannage.
• Outils et SDK pour développeurs : nombreux SDK de la plateforme d’identité Microsoft, documentation et exemples de démarrage rapide qui simplifient la mise en œuvre.

Inconvénients

• Complexité pour les débutants : la configuration et les modèles d’autorisation (URI de redirection, URL de réponse, flux implicite et flux de code d’autorisation, étendues) peuvent dérouter les nouveaux développeurs.
• Courbe d’apprentissage abrupte pour les fonctionnalités de sécurité : l’accès conditionnel, les identités managées et les paramètres avancés de jetons exigent des connaissances approfondies en sécurité pour être configurés en toute sécurité.
• Risque de prolifération des autorisations : un consentement mal maîtrisé ou des autorisations d’application trop larges peuvent conduire à des applications disposant de privilèges excessifs si elles ne sont pas revues régulièrement.
• Subtilités de gestion des jetons : la gestion des jetons d’actualisation, des durées de vie des jetons et de leur révocation présente des comportements propres à chaque plateforme, susceptibles de provoquer des problèmes d’intégration.
• Considérations liées aux frontières des locataires : le comportement des applications multilocataires et les invites de consentement administrateur ajoutent de la complexité opérationnelle pour les scénarios inter-locataires.
• Évolutions de l’interface et de la terminologie : Microsoft met régulièrement à jour l’interface et la nomenclature d’Entra (Azure AD → Entra ID), ce qui peut entraîner un décalage avec la documentation ou de la confusion.
• Dépendance à l’écosystème Microsoft : un couplage étroit avec les fonctionnalités d’Entra ID peut limiter la portabilité vers des fournisseurs d’identité non Microsoft sans refonte.
• Risque de mauvaise configuration : des paramètres d’inscription d’application incorrects (par exemple URI de redirection, URL de réponse, paramètres du flux implicite) peuvent créer des failles de sécurité ou interrompre les flux d’authentification.

Prochaines étapes et ressources communautaires clés pour réussir avec OAuth

Très bien, OAuth est configuré et fonctionne, mais ne levez pas le pied pour autant : assurez-vous que l’application qui obtient les jetons est correctement configurée. Mettre en place les bases n’est que la première étape. Si vous voulez que votre application se démarque et que vos utilisateurs restent protégés, c’est le moment de vous intéresser aux compléments. Commencez par explorer les bibliothèques clientes avancées, expérimentez avec Microsoft Graph et découvrez les nouvelles fonctionnalités d’identité qui peuvent renforcer votre intégration et la rendre plus fluide pour tous.

Vous n’avez d’ailleurs pas à tout résoudre seul. La documentation de Microsoft Entra ID est aussi riche que le lac Michigan : elle regorge de guides à jour, d’exemples de code et de spécifications techniques que vous voudrez probablement avoir sous la main. Prenez l’habitude de vérifier les mises à jour, surtout à mesure que les standards OAuth et d’identité cloud continuent d’évoluer.

Satisfait de votre inscription d’application ? Très bien. Voyons maintenant comment les praticiens font preuve d’inventivité. Parcourez les forums de développeurs, les espaces de discussion officiels, et jetez même un œil aux dépôts GitHub des bibliothèques d’authentification. Si vous butez sur un problème, il y a de fortes chances que quelqu’un l’ait déjà résolu, ou du moins s’en soit plaint assez fort pour obtenir une réponse.

Si vous aimez bricoler et apprendre en pratiquant, consultez les essais gratuits, les locataires de test et les fonctionnalités en préversion publique. Ils vous permettent de tout casser (sans risque) et de découvrir ce qui fonctionne avant de déployer des modifications auprès de vos utilisateurs réels. N’oubliez pas non plus que OAuth et la sécurité sont des efforts collectifs : partagez vos réussites et vos questions. Cela contribue à garder l’écosystème sain et à le faire prospérer, et aide chacun à comprendre le fonctionnement des flux OAuth.

Liste de contrôle du guide d’inscription d’applications et OAuth - Entra ID

• Définir le type d’application et le modèle d’accès : choisissez entre locataire unique, multilocataire ou comptes Microsoft personnels, et déterminez s’il s’agit d’une application SPA, d’une application web, mobile, d’un démon ou d’une application de service.
• Enregistrer l’application dans Entra ID : créez une nouvelle inscription d’application avec un nom explicite et les types de comptes pris en charge adaptés.
• Configurer les URI de redirection : ajoutez les URI de redirection ou de rappel appropriés pour chaque plateforme (https, schéma personnalisé, localhost pour le développement).
• Définir les paramètres de plateforme de l’application : activez les options de plateforme SPA, web, mobile & bureau et configurez les flux implicites ou d’autorisation selon les besoins.
• Créer et gérer les secrets client : générez des secrets client pour les clients confidentiels, notez leur date d’expiration et stockez-les en toute sécurité (Key Vault).
• Utiliser des certificats pour l’authentification : téléversez des certificats à clé publique pour les clients confidentiels en production, plutôt que des secrets à longue durée de vie.
• Configurer les autorisations d’API : ajoutez les autorisations et étendues requises par l’application pour Microsoft Graph ou pour vos API personnalisées.
• Accorder le consentement administrateur lorsque c’est nécessaire : demandez et consignez le consentement administrateur pour les autorisations déléguées qui exigent un consentement à l’échelle du locataire.
• Définir et exposer des étendues personnalisées (si l’application est une API) : ajoutez des étendues sous « Exposer une API », puis définissez leurs noms, descriptions et noms d’affichage pour le consentement administrateur.
• Configurer les rôles d’application (si nécessaire) : définissez des rôles d’application et des rôles délégués pour le contrôle d’accès basé sur les rôles, et attribuez-les à des utilisateurs, à des groupes ou à des applications clientes.
• Configurer CORS pour les SPA qui appellent des API : ajoutez les origines autorisées sur l’API ou configurez les stratégies CORS de la passerelle.
• Choisir le flux OAuth 2.0 : sélectionnez le code d’autorisation (avec PKCE pour les clients publics), les identifiants client pour les applications démon, ou le code d’appareil, selon le cas.
• Implémenter PKCE pour les clients publics : exigez Proof Key for Code Exchange pour les SPA et les applications natives afin d’empêcher l’interception du code.
• Valider correctement les jetons : vérifiez l’émetteur, l’audience, la signature, l’expiration et les revendications requises à l’aide des bibliothèques d’identité Microsoft ou d’une logique de validation JWT.
• Utiliser les bibliothèques d’authentification Microsoft (MSAL) : privilégiez MSAL pour l’acquisition, la mise en cache et le renouvellement des jetons, ainsi que pour leur gestion sécurisée sur toutes les plateformes.
• Configurer l’accès conditionnel et le MFA (si nécessaire) : appliquez des stratégies à l’inscription de l’application ou aux flux de connexion des utilisateurs pour imposer les contrôles de sécurité.
• Surveiller les connexions et les journaux d’audit : activez la journalisation et examinez les événements de connexion, les consentements et les opérations d’administration dans les journaux Entra ID.
• Appliquer le principe du moindre privilège : ne demandez que les autorisations nécessaires et privilégiez le consentement progressif afin de limiter l’exposition.
• Renouveler régulièrement les secrets et les certificats : mettez en place une rotation automatisée et des alertes pour les identifiants qui arrivent à expiration.
• Sécuriser le code et le stockage côté client : évitez de stocker des secrets dans les applications clientes, utilisez un stockage sécurisé et suivez les bonnes pratiques propres à chaque plateforme.
• Tester les connexions et les flux de jetons en développement et en préproduction : validez les flux d’authentification, la durée de vie des jetons, la logique de renouvellement, la gestion des erreurs et l’expérience de consentement.
• Préparer la documentation à destination des utilisateurs et des administrateurs : incluez les étapes de consentement, les autorisations requises et les conseils de dépannage.
• Revoir et mettre à jour régulièrement les inscriptions d’applications : auditez les autorisations, les rôles, les secrets et les inscriptions pour repérer les applications obsolètes ou inutilisées.
• Appliquer des protections réseau et API : envisagez API Management, un WAF, la limitation de débit et les points de terminaison de service pour protéger les API back-end.

jeton d’accès Azure utilisation OAuth authentification

Qu’est-ce qu’un guide d’inscription d’application et OAuth, et pourquoi est-il important ?

Un guide d’inscription d’application et OAuth explique comment inscrire une application cliente auprès d’un fournisseur d’identité (par exemple Azure) et mettre en œuvre les flux d’autorisation OAuth 2.0 afin que votre application puisse demander l’accès à des ressources protégées en toute sécurité. C’est essentiel que vous développiez des applications web, des applications monopage, des applications de bureau ou des back-ends de serveurs web, car l’application a besoin d’un ID d’application (application id ou app id) ainsi que d’un ID client et d’un secret client (pour les clients confidentiels) afin d’obtenir un jeton d’accès et, le cas échéant, un jeton d’ID.

Comment enregistrer une application Azure et obtenir l’ID d’application et l’app id ?

Pour enregistrer une application Azure, accédez au portail Azure, créez une nouvelle inscription d’application, indiquez un nom et des URI de redirection, puis notez l’ID client (ID d’application) affiché dans la vue d’ensemble de l’application. Si votre application est un client confidentiel (serveur web ou application web classique), créez un secret client à utiliser avec l’ID client et le secret client. Cette application inscrite sert à l’autorisation et à la demande de jetons d’accès auprès des services Microsoft.

Quel flux d’autorisation OAuth 2.0 dois-je utiliser pour les applications monopage ?

Les applications monopage doivent utiliser le flux d’autorisation par code avec PKCE (Proof Key for Code Exchange) plutôt que le flux implicite, afin de garantir que l’application obtient les jetons de manière sécurisée. Le flux par code avec PKCE permet à l’application d’échanger le code contre un jeton d’accès de façon sécurisée depuis un client basé sur le navigateur, ce qui permet aux applications monopage d’utiliser OAuth sans exposer les secrets client dans le navigateur.

Comment fonctionne la demande d’autorisation et quels paramètres sont requis ?

Une demande d’autorisation est envoyée au point de terminaison d’autorisation du fournisseur d’identité et comprend généralement client_id (ID de l’application), response_type (par exemple code), redirect_uri, scope et state. Pour les applications monopage qui utilisent le flux par code avec PKCE, vous ajoutez également code_challenge et code_challenge_method. L’utilisateur s’authentifie et donne son consentement (consentement OAuth), puis le serveur d’autorisation renvoie un code à l’URI de redirection, que l’application peut échanger contre un jeton d’accès.

Comment coder l’échange d’un code contre un jeton d’accès ?

Après avoir reçu le code d’autorisation, l’application cliente envoie une requête au point de terminaison de jetons, incluant le code, client_id (et client_secret pour les clients confidentiels), redirect_uri et grant_type=authorization_code. Avec PKCE, vous ajoutez le code_verifier. Le point de terminaison de jetons renvoie un jeton d’accès, un jeton d’ID (si demandé) et éventuellement un jeton d’actualisation permettant d’obtenir un nouveau jeton d’accès lorsque celui-ci expire.

Comment obtenir un jeton d’accès et l’utiliser pour appeler des API ?

Obtenez un jeton d’accès en suivant le flux d’autorisation OAuth 2.0 choisi et en appelant le point de terminaison de jetons. Une fois le jeton d’accès obtenu, transmettez-le dans l’en-tête Authorization avec le schéma Bearer lorsque vous appelez les services Microsoft ou d’autres API (par exemple Google Calendar ou des API personnalisées). Vérifiez les jetons côté serveur web ou côté ressource afin de vous assurer que les requêtes de l’application sont autorisées.

Que faire lorsque le jeton d’accès expire, et comment obtenir un nouveau jeton d’actualisation ?

Lorsque le jeton d’accès expire, utilisez le jeton d’actualisation (s’il est fourni) pour demander un jeton d’accès au point de terminaison de jetons avec grant_type=refresh_token. Certains flux ou fournisseurs émettent un nouveau jeton d’actualisation lors du renouvellement, d’autres réutilisent le même. Si aucun jeton d’actualisation n’est disponible (clients publics ou flux de courte durée), redirigez l’utilisateur vers votre application pour effectuer une nouvelle demande d’autorisation.

Faut-il des inscriptions d’application distinctes pour les applications web et pour les applications mobiles ou de bureau ?

Il est souvent nécessaire de disposer d’inscriptions distinctes lorsque les types d’application diffèrent sensiblement (par exemple serveur web traditionnel, applications monopage et applications de bureau), car les URI de redirection, les secrets client et les flux autorisés varient. Des inscriptions distinctes permettent de configurer des flux d’autorisation et des URI de redirection spécifiques à chaque type d’application.

Quelle est la différence entre l’inscription d’une application cliente et une application dans un locataire ?

L’inscription d’une application cliente désigne l’entrée spécifique dans le fournisseur d’identité (l’application Azure) qui contient la configuration, comme les URI de redirection et les secrets. Une application dans un locataire indique que l’inscription se trouve dans un locataire Azure AD donné et qu’elle peut se voir attribuer des rôles et des autorisations au sein de ce locataire. Une même inscription d’application peut être multilocataire ou monolocataire, selon vos besoins.

Comment demander l’accès aux services Microsoft, et quelles autorisations sont nécessaires ?

Demandez l’accès en indiquant dans la demande d’autorisation les étendues (scopes) dont votre application a besoin. Pour les services Microsoft, configurez les autorisations d’API dans l’inscription d’application Azure, puis invitez les utilisateurs à donner leur consentement (consentement OAuth) ou demandez à un administrateur d’accorder un consentement à l’échelle du locataire. L’application demande des étendues comme User.Read ou des étendues d’API personnalisées dans ses demandes d’application, puis utilise le jeton d’accès pour appeler les services.

Comment sécuriser les secrets client et éviter la fuite d’identifiants dans les applications monopage ?

Les applications monopage ne doivent pas stocker de secrets client, car le code exécuté dans le navigateur peut être inspecté. Utilisez le flux par code avec PKCE afin que l’application obtienne en toute sécurité un jeton d’accès sans secret client. Pour les applications confidentielles (serveur web), stockez l’ID client et le secret client côté serveur, là où ils ne sont pas exposés aux utilisateurs.

Quel est le rôle de l’URI de redirection, et pourquoi doit-il correspondre à l’inscription de l’application ?

L’URI de redirection est l’endroit où le fournisseur d’identité envoie la réponse d’autorisation (code ou jeton). Elle doit correspondre à l’URI de redirection enregistrée dans l’inscription de l’application afin d’empêcher le détournement de la réponse d’autorisation. Utilisez une correspondance exacte ou les modèles autorisés définis par le fournisseur ; une différence entraînera l’échec de l’échange de jetons.

Comment amener les utilisateurs à s’authentifier et à recevoir un jeton d’identification (id token) en plus d’un jeton d’accès ?

Pour recevoir un jeton d’identification, demandez l’étendue openid et incluez un response_type qui déclenche l’émission du jeton d’identification (flux de code d’autorisation avec openid). Le jeton d’identification contient les revendications d’identité de l’utilisateur authentifié. Utilisez-le pour connecter l’utilisateur à votre application cliente, et le jeton d’accès pour appeler les API en aval.

Quels flux d’autorisation spécifiques s’appliquent aux applications web traditionnelles et aux applications monopage ?

Les applications web traditionnelles (côté serveur) utilisent généralement le flux de code d’autorisation avec des identifiants client (ID client et secret client), et échangent le code sur le serveur web. Les applications monopage utilisent l’octroi de code d’autorisation avec PKCE, sans secret client. Les applications de bureau utilisent également PKCE. Choisissez le flux en fonction du type d’application et de l’endroit où les secrets peuvent être stockés de manière sécurisée.

Une seule inscription d’application peut-elle servir à plusieurs applications clientes, ou faut-il créer une inscription par application ?

Vous pouvez utiliser une seule inscription d’application pour plusieurs applications clientes si elles partagent la même configuration et les mêmes URI de redirection. Toutefois, les bonnes pratiques recommandent souvent de créer des inscriptions distinctes pour des applications différentes (inscriptions d’application séparées), afin d’isoler les autorisations, les URI de redirection et la gestion du cycle de vie. Vérifiez si l’application pourrait avoir besoin d’étendues d’autorisation différentes ou d’un comportement de consentement administrateur différent.

Comment valider les jetons dans mon serveur web ou mon API ?

Votre serveur web ou votre API doit valider la signature, l’émetteur, le public (audience : ID d’application ou ID d’application cliente) et la date d’expiration du jeton d’accès ou du jeton d’identification. Utilisez le document de découverte du fournisseur pour obtenir les clés de signature et suivez les bibliothèques de validation recommandées pour votre plateforme. Cette validation garantit que seules les requêtes provenant d’applications authentifiées et autorisées sont acceptées.

Quelle est la procédure pour demander un jeton d’accès pour un service backend à l’aide des identifiants client ?

Pour les scénarios serveur à serveur, inscrivez une application Azure, accordez-lui des autorisations d’application, puis utilisez le flux d’identifiants client : envoyez une requête POST au point de terminaison de jeton avec grant_type=client_credentials, client_id, client_secret et scope/resource. Le point de terminaison de jeton renvoie un jeton d’accès que le backend peut utiliser pour appeler les services Microsoft ou les API protégées.

Comment gérer le consentement OAuth et le consentement administrateur pour les applications multilocataires ?

Lorsque votre application est inscrite comme multilocataire, les utilisateurs d’autres locataires peuvent consentir aux autorisations déléguées lors de la demande d’autorisation. Pour les autorisations qui exigent un consentement administrateur, un administrateur doit accorder ce consentement pour son locataire. Fournissez des instructions et une URL de consentement aux administrateurs de locataires afin qu’ils accordent le consentement OAuth à grande échelle.

Quelles étapes de dépannage suivre si ma demande d’autorisation échoue ?

Vérifiez que l’application est inscrite dans le portail Microsoft, que l’URI de redirection correspond, que l’ID client et le secret client sont corrects, que les étendues sont valides, et que le type d’octroi ainsi que les paramètres PKCE (le cas échéant) sont corrects. Consultez les messages d’erreur renvoyés par le point de terminaison d’autorisation ou de jeton, ainsi que les journaux côté client et côté serveur. Stack Overflow et la documentation du fournisseur peuvent aider à interpréter des codes d’erreur spécifiques.

Comment intégrer des API tierces, comme Google Agenda, à mon application inscrite ?

Pour intégrer Google Agenda ou d’autres API tierces, implémentez les flux d’autorisation OAuth 2.0 requis par ces fournisseurs. Votre application doit demander les étendues appropriées pour l’API tierce et gérer des cycles de vie de jetons distincts. Vous devrez peut-être créer des inscriptions d’application distinctes auprès de chaque fournisseur et coordonner l’obtention des jetons d’accès pour chaque service.

Quand faut-il utiliser le flux de code d’appareil ou d’autres flux spécifiques pour certains appareils ?

Utilisez le flux de code d’appareil pour les appareils à saisie limitée où aucun navigateur n’est disponible. Ce flux permet à un utilisateur de se rendre sur une URL de vérification depuis un autre appareil pour s’authentifier. Il fait partie des flux d’autorisation spécifiques pris en charge, aux côtés du flux de code d’autorisation, des identifiants client et des flux de jeton d’actualisation, afin de s’adapter aux différents types de factEurs de forme d’application.