Comment choisir le bon Flux OAuth 2.0/OIDC et Serveur d’autorisation Okta pour votre Infrastructure

Introduction

Dans l'écosystème du développement moderne, la sécurisation des applications repose sur deux fondamentaux : l'authentification (qui est l'utilisateur ?) et l'autorisation (que peut-il faire ?). Si OAuth 2.0 et OpenID Connect se sont imposés comme standards incontournables, leur mise en œuvre concrète soulève souvent de nombreuses questions : quel flux d'autorisation utiliser ? Comment configurer son serveur d'autorisation ? Quelle stratégie adopter selon le type d'application ?

Avec Okta, ces choix techniques deviennent encore plus cruciaux : entre les multiples flux OAuth 2.0/OIDC disponibles et les deux types de serveurs d'autorisation (Org Authorization Server vs Custom Authorization Server), il est essentiel de comprendre les implications de chaque décision pour garantir à la fois la sécurité et la maintenabilité de votre système.

Cet article vous accompagne dans cette réflexion stratégique en clarifiant :

• Les différents flux d'authentification/autorisation et leurs cas d'usage selon votre architecture (application web traditionnelle, SPA, application mobile, API, ou service backend)

• Les critères de choix entre l'Org Authorization Server et un Custom Authorization Server

• Les bonnes pratiques pour implémenter une solution robuste et évolutive

Que vous débutiez avec Okta ou que vous cherchiez à optimiser une intégration existante, ce guide vous donnera les clés pour prendre les bonnes décisions techniques.

Dans le développement moderne d’applications, l’authentification et l’autorisation sont devenues des piliers essentiels de la sécurité. Entre OAuth 2.0, OpenID Connect, et les serveurs d’autorisation d’Okta, il est parfois difficile de savoir quel flux choisir pour son application ou quel serveur utiliser.

Cet article vous guide pas à pas pour comprendre quel flux d’authentification correspond à votre type d’application (Web, SPA, mobile, ou service), et quel serveur d’autorisation (Org ou Custom) répond le mieux à vos besoins.

Avant de détailler OAuth 2.0 et OpenID Connect, faisons un point sur les serveurs d’autorisation (Org et Custom)

Qu’est‑ce qu’un serveur d’autorisation (vue fonctionnelle)

Un serveur d’autorisation est le composant qui contrôle l’accès à des ressources protégées dans un domaine de sécurité. Dans OAuth 2.0 / OIDC, il reçoit des demandes de la part d’applications clientes, authentifie l’utilisateur ou le client, recueille le consentement, applique des politiques d’accès (scopes, audiences, groupes, conditions), puis émet des jetons signés (Access Token, ID Token, et éventuellement Refresh Token). Chaque serveur est identifié par un issuer (URI) et publie sa clé publique pour que les API puissent vérifier les jetons.

Entrées → Traitements → Sorties

• Entrées : paramètres de la demande (client_id, redirect_uri, scope, code_challenge PKCE…), identifiants/preuves d’authentification (utilisateur ou client), consentement.

• Traitements : authentification, évaluation des policies, génération et signature des jetons, journalisation.

• Sorties : redirection avec authorization code (selon le flow), Access Token, ID Token, Refresh Token ou erreurs normalisées.

Les endpoints standard d’un serveur d’autorisation Okta

Chaque serveur (Org ou Custom) expose des URLs bien définies. Voici les plus importantes :

• Discover

  • https://yourOktaDomain.com/.well-known/openid-configuration → Retourne toute la configuration OIDC (endpoints, scopes supportés, clés, etc.).

  • https://yourOktaDomain.com/.well-known/oauth-authorization-server → Version OAuth 2.0 pure (moins courante).

• Autorisation

  • https://yourOktaDomain.com/oauth2/{auth_server_id}/v1/authorize → Démarre le flux : affiche la page de login, gère le consentement, redirige avec un code.

• Émission de jetons

  • https://yourOktaDomain.com/oauth2/{auth_server_id}/v1/token → Échange un code contre des tokens (Authorization Code + PKCE), ou délivre un token via client_credentials.

• Vérification et informations

  • /v1/keys → Clés publiques (JWKS) pour vérifier la signature des tokens.

  • /v1/userinfo → Retourne les données de l’utilisateur (email, nom, etc.) avec un Access Token valide.

  • /v1/introspect → Vérifie si un token est actif, expiré ou révoqué (uniquement sur Custom Server).

  • /v1/revoke → Révoque un token immédiatement (logout forcé, sécurité).

Note : Remplace {auth_server_id} par default (Custom Server par défaut) ou ton ID personnalisé. Pour l’Org Authorization Server, les chemins sont en /oauth2/v1/... sans auth_server_id.

Comprendre les fondamentaux : OAuth 2.0 et OpenID Connect

Okta prend en charge plusieurs protocoles d'authentification et d'autorisation : SAML 2.0, Secure Web Authentication (SWA), ainsi que les standards modernes OAuth 2.0 et OpenID Connect (OIDC). Ces deux derniers se sont imposés comme les piliers des intégrations d'applications web, mobiles et API.

Alors que SAML et SWA répondent encore à des cas d'usage legacy, OAuth 2.0 et OIDC offrent une approche plus flexible et standardisée. Mais avant de plonger dans leurs subtilités, posons-nous les bonnes questions : avez-vous besoin de savoir qui se connecte (identité), à quoi il peut accéder (autorisations), ou s'agit-il d'un service qui appelle un autre service sans utilisateur humain ? Ces distinctions orientent directement vos choix d'architecture.

OAuth 2.0 vs OpenID Connect : deux protocoles complémentaires

• OAuth 2.0 contrôle et délègue l'autorisation d'accès à une ressource protégée. Il assure la sécurité des APIs via des Access Tokens à portée limitée (scopes), sans exposer les identifiants utilisateur.

• OIDC étend OAuth 2.0 en ajoutant l'authentification et le Single Sign-On (SSO). Il fournit un ID Token (JWT signé) contenant l'identité vérifiée de l'utilisateur : nom, email, rôle, photo de profil.

En pratique avec Okta La majorité des applications nécessitent les deux protocoles. Lors d'un flux complet, Okta délivre à la fois un ID Token (identité) et un Access Token (autorisation). Okta propose des modèles de déploiement qui abstraient ces protocoles, vous n'avez donc pas à les manipuler directement.

Comprendre cette complémentarité vous permet de choisir le bon flux et d'éviter les erreurs courantes : utiliser un Access Token pour l'identité, exposer un ID Token à une API tierce, ou mal dimensionner la durée de vie des tokens

Choisir le flux OAuth 2.0 / OpenID Connect adapté à votre type d’application

Lors de la création d’une nouvelle intégration d’application dans Okta, comme illustré dans la capture ci-dessous, vous êtes invité à choisir une méthode de connexion (Sign-in method) et un type d’application (Application type).

Ces deux choix déterminent directement le flux d’authentification OAuth 2.0 / OIDC que votre application utilisera.

Okta propose plusieurs méthodes d’intégration, chacune adaptée à un cas d’usage particulier.

• SAML 2.0 : un standard basé sur XML, principalement utilisé dans les environnements d’entreprise pour le Single Sign-On (SSO). Il reste adapté aux applications existantes qui ne prennent pas en charge OAuth 2.0 ou OIDC.

• SWA (Secure Web Authentication) : une méthode propre à Okta, utile lorsque l’application ne supporte ni SAML ni OIDC. Elle repose sur une authentification simulée via un formulaire web.

• API Services : utilisée pour les intégrations sans utilisateur (machine-to-machine), basée sur le flux Client Credentials d’OAuth 2.0.

Cependant, pour la plupart des applications modernes – web, mobiles ou orientées API – le choix recommandé est OIDC – OpenID Connect, qui s’appuie sur la puissance et la flexibilité du protocole OAuth 2.0.

1. La section Sign-in method permet de sélectionner le protocole d’authentification :

   • OIDC – OpenID Connect (recommandé pour les applications modernes basées sur OAuth 2.0),

   • SAML 2.0,

   • SWA (Secure Web Authentication),

   • ou API Services pour les échanges machine-to-machine.

2. La section Application type définit l’environnement et le flux approprié :

   • Web Application → flux Authorization Code ( + PKCE : Optionnel mais fortement recommandé )

   • Single-Page Application → flux Authorization Code with PKCE,

   • Native Application → flux Authorization Code with PKCE,

   • API Services → flux Client Credentials.

En combinant ces deux paramètres, Okta détermine automatiquement le flux OAuth 2.0 ou OIDC le plus adapté à votre architecture — qu’il s’agisse d’une application web, d’un front-end SPA, d’une app mobile ou d’un service backend.

OIDC : le standard moderne pour l’authentification et l’autorisation

OpenID Connect (OIDC) étend le protocole OAuth 2.0 en ajoutant une couche d’authentification.

Alors qu’OAuth 2.0 se concentre sur le contrôle d’accès aux ressources (autorisation), OIDC permet d’identifier l’utilisateur de manière sécurisée.

• Authorization Code Flow :

Le Authorization Code Flow (ou Code Flow) est défini par la spécification OAuth 2.0 (RFC 6749, section 4.1). C'est le flux le plus couramment utilisé pour les applications web côté serveur et constitue la base des intégrations OAuth/OIDC modernes.

Ce flux est conçu pour offrir un haut niveau de sécurité en séparant l'authentification de l'utilisateur (qui se déroule dans le navigateur) de l'échange de tokens (qui se produit de manière sécurisée entre serveurs backend). Les tokens d'accès ne transitent jamais directement dans le navigateur, réduisant ainsi les risques d'exposition.

Étapes du flux Authorization Code

1. Ton application demande un code d’autorisation Elle redirige l’utilisateur vers Okta (/authorize).

2. Okta affiche la page de connexion L’utilisateur voit le login Okta dans son navigateur.

3. L’utilisateur se connecte et donne son accord Il entre ses identifiants, accepte les permissions demandées.

4. Okta renvoie un code d’autorisation au navigateur Le code arrive dans l’URL de redirection (ex: ?code=abc123).

5. Ton application envoie le code + le client secret à Okta Appel backend vers /token (pas dans le navigateur !).

6. Okta répond avec les tokens Tu reçois :

   • access_token (pour appeler l’API)

   • id_token (identité de l’utilisateur)

   • refresh_token (optionnel, pour renouveler)

7. Ton application appelle l’API avec l’access_token En-tête : Authorization: Bearer <token>

8. L’API vérifie le token avant de répondre Elle utilise les clés publiques d’Okta (/keys) pour valider la signature.

💡

Recommandation: Franchement, mettez PKCE partout — SPA, mobile, ou même backend

En fait, depuis 2023, il est fortement recommandé d’utiliser le flux “Authorization Code Flow with PKCE”, y compris pour les applications web côté serveur.

Cette approche, initialement conçue pour les applications mobiles et SPA, ajoute une couche de sécurité supplémentaire au flux classique en protégeant l’échange du code d’autorisation.

Nous reviendrons plus loin sur le fonctionnement détaillé du PKCE (Proof Key for Code Exchange) et sur les raisons de son adoption généralisée.

Référence : Okta Developer Docs – Authorization Code Flow with PKCE

• Authorization Code Flow with PKCE : la version renforcée du Code Flow

Le Authorization Code Flow with PKCE (Proof Key for Code Exchange) est une évolution du flux d’autorisation classique décrite dans la RFC 7636.

À l’origine, ce mécanisme a été conçu pour les applications mobiles et Single Page Applications (SPA), où le client_secret ne peut pas être protégé.

Il est aujourd’hui recommandé pour toutes les applications, y compris celles côté serveur, car il renforce la sécurité du processus d’échange de tokens.

Principe de fonctionnement

Le fonctionnement reste globalement identique au Code Flow classique, à une différence majeure :

l’application génère une clé temporaire unique, appelée code_verifier, qu’elle transforme en un code challenge (haché).

Cette clé permet au serveur d’autorisation (Okta) de vérifier que le code d’autorisation échangé n’a pas été intercepté ou modifié pendant le processus.

Étapes du flux Authorization Code avec PKCE

1. Génération de la clé PKCE
   L’application commence par générer un code verifier (clé aléatoire) et en déduit un code challenge (sa version hachée). Ces deux éléments serviront à prouver l’identité de l’application lors de l’échange du code d’autorisation.

2. Demande d’un code d’autorisation
   L’application redirige l’utilisateur vers le serveur d’autorisation Okta (/authorize), en incluant le code_challenge.

3. Affichage de la page de connexion
   Okta affiche la page de connexion à l’utilisateur. Celui-ci choisit une méthode d’authentification (identifiant/mot de passe, SSO, etc.).

4. Authentification et consentement
   L’utilisateur s’identifie et, si nécessaire, accepte les autorisations demandées par l’application (scopes).

5. Redirection vers l’application
   Une fois authentifié, Okta redirige le navigateur vers l’application avec un code d’autorisation temporaire.

6. Échange du code d’autorisation contre des tokens
   L’application envoie ce code à Okta, accompagné du code_verifier, pour prouver qu’elle est bien à l’origine de la demande.

7. Validation du code PKCE
   Okta compare le code_verifier reçu avec le code_challenge initial afin de vérifier l’intégrité de la requête.

8. Remise des tokens
   Si tout est correct, Okta renvoie un Access Token, un ID Token, et éventuellement un Refresh Token.

9. Accès aux ressources protégées
   L’application utilise l’Access Token pour interroger une API (le Resource Server) au nom de l’utilisateur.

10. Réponse du serveur de ressources
    L’API valide le token et renvoie les données demandées.

Exemple de code : Authorization code flow + PKCE

// On commence par générer deux valeurs aléatoires et uniques pour chaque connexion :
// 1. code_verifier : une chaîne longue et imprévisible (minimum 43 caractères)
//    Elle sert à prouver que c'est bien notre application qui a initié la demande.
//    On la garde en mémoire (session ou stockage local) pour la réutiliser plus tard.
const { generators } = require('openid-client');
const code_verifier = generators.codeVerifier();

// 2. state : une autre valeur aléatoire, différente à chaque fois.
//    Elle empêche les attaques CSRF : si quelqu'un essaie de forcer une redirection,
//    cette valeur ne correspondra pas à celle qu'on a envoyée.
const state = require('crypto').randomBytes(32).toString('hex');

// On calcule le code_challenge à partir du code_verifier (hash en SHA256)
const code_challenge = generators.codeChallenge(code_verifier);

// On construit l'URL complète pour rediriger l'utilisateur vers Okta
const authUrl = `https://my-domaine.okta.com/oauth2/default/v1/authorize?` +
  `client_id=0oaxxx` +
  `&response_type=code` +
  `&scope=openid profile email` +
  `&redirect_uri=http://localhost:3000/callback` +
  `&state=${state}` +              // Valeur aléatoire, vérifiée au retour
  `&code_challenge=${code_challenge}` +  // Preuve que le code vient bien de nous
  `&code_challenge_method=S256`;

// On supprime les espaces et retours à la ligne pour une URL propre
const cleanUrl = authUrl.replace(/\s/g, '');

// On stocke les deux valeurs secrètes avant de rediriger
req.session.code_verifier = code_verifier;
req.session.state = state;

res.redirect(cleanUrl); // L'utilisateur est envoyé vers la page de login Okta

Client Credentials Flow : le flux pour les communications machine-to-machine

Le Client Credentials Flow est conçu pour les applications sans utilisateur final — autrement dit, pour les scénarios où une application ou un service doit accéder à une ressource protégée au nom d’elle-même.

Ce flux est typique dans les architectures de microservices ou pour les automatisations backend, où un service doit appeler une API sécurisée.

Principe général

Contrairement aux autres flux OAuth 2.0, celui-ci ne passe pas par une interaction utilisateur.

L’application cliente s’authentifie directement auprès du serveur d’autorisation à l’aide de ses propres identifiants (généralement un Client ID et un Client Secret), et obtient en retour un Access Token.

Ce jeton permet ensuite d’appeler les API protégées.

Étapes du flux Client Credentials Flow

• Requête de jeton d’accès
  L’application envoie une requête au serveur d’autorisation Okta vers le point de terminaison /token, en s’authentifiant à l’aide de ses propres identifiants (client_id et client_secret).
  Ces identifiants sont configurés lors de la création de l’intégration d’application (type API Services).

• Réponse avec le jeton d’accès
  Si les informations d’identification sont valides, Okta renvoie un Access Token signé, limité dans le temps et contenant les scopes autorisés.

• Appel de l’API avec le jeton
  L’application utilise ce jeton d’accès pour appeler le Resource Server (votre API sécurisée). Le jeton prouve que la requête vient d’une application autorisée.

• Validation et réponse
  Le serveur de ressources vérifie la validité du jeton auprès d’Okta avant de fournir les données ou d’exécuter l’action demandée.

💡

Points clés à retenir

• Ce flux ne fournit pas d’ID Token, car aucun utilisateur n’est impliqué.

• Les scopes doivent être définis avec précision afin de limiter les permissions du client.

• Les identifiants (client_id et client_secret) doivent être stockés de manière sécurisée (jamais dans le code source).

• En pratique, ce flux est presque toujours utilisé avec un Custom Authorization Server, car il permet de créer des tokens sur mesure pour vos propres APIs.

Exemple de code : Client Credentials Flow (M2M)

const getApiToken = async () => {
  // Prépare la requête sans utilisateur
  const params = new URLSearchParams({
    grant_type: 'client_credentials',
    scope: 'api:read api:write' // -> Scopes définis dans le Custom Server
  });

  // Authentifie le service avec client_id + secret, ici on pointe sur le custom serveur
  const response = await fetch('https://my-domain.okta.com/oauth2/default/v1/token', {
    method: 'POST',
    headers: {
      'Authorization': 'Basic ' + Buffer.from('0oayyy:secret').toString('base64'),
      'Content-Type': 'application/x-www-form-urlencoded'
    },
    body: params
  });

  const { access_token } = await response.json();
  return access_token; // -> Token pour appeler ton API
};

// Exemple d'appel API
const token = await getApiToken();
fetch('https://api.monservice.com/data', {
  headers: { Authorization: `Bearer ${token}` }
});

Les flux OAuth 2.0 dépréciés : Implicit et ROPG

Bien que toujours définis dans la spécification OAuth 2.0 (RFC 6749), certains flux historiques sont aujourd’hui considérés comme obsolètes ou à usage restreint.

C’est notamment le cas de l’Implicit Flow et du Resource Owner Password Credentials Flow (ROPG).

L’Implicit Flow, conçu à l’origine pour les applications Single-Page (SPA) dépourvues de capacités sécurisées côté serveur, permettait de récupérer un jeton d’accès directement via l’URL après redirection.

Mais cette approche présente plusieurs failles : exposition du jeton dans le navigateur, impossibilité de vérifier sa signature, et risques de vol via des scripts tiers.

C’est pourquoi Okta, comme l’ensemble de l’écosystème OAuth, recommande désormais de le remplacer par le Authorization Code avec PKCE plus sûr et universel.

Le Resource Owner Password Flow (ROPG), lui, autorise une application à collecter directement les identifiants de l’utilisateur (nom d’utilisateur et mot de passe) pour obtenir un jeton d’accès.

Ce flux contourne toutefois la page d’authentification Okta et empêche l’application de bénéficier de mécanismes avancés tels que la MFA, la détection d’anomalies ou l’authentification adaptative.

Okta précise dans sa documentation officielle que ce flux ne doit être utilisé que dans les environnements de confiance ou à des fins de compatibilité technique :

“If your app is high-trust and you own both the client and the resource it accesses, you can use the Resource Owner Password flow. However, this flow is not compatible with multifactor authentication, and should be replaced by the Authorization Code or Interaction Code flow whenever possible.”

(Source : Okta Developer Docs – OAuth & OpenID Connect Concepts)

💡

Recommandation actuelle

Depuis 2023, les bonnes pratiques de sécurité (Okta, IETF, Auth0) convergent :

Utilisez le Code Flow with PKCE pour toutes les applications avec utilisateur, et le Client Credentials Flow pour les échanges entre services.

Conclusion

On arrive au bout de ce guide, et l’essentiel tient en une idée : choisir le bon flux OAuth/OIDC et le bon serveur Okta, c’est protéger ton application sans te prendre la tête.

• Si tu as des utilisateurs (web, SPA, mobile) → Authorization Code avec PKCE, point final. C’est le standard depuis 2023, ça marche partout, ça supporte la MFA, et les SDK Okta le font tout seul.

• Si c’est du machine-to-machine → Client Credentials + Custom Authorization Server. C’est là que tu définis tes propres audiences, scopes, claims. Tes APIs deviennent vraiment à toi.

• Oublie l’Implicit et le ROPG. Sauf si t’as une vieille app qui traîne dans un coin… et même là, planifie la migration.

Org vs Custom : le match en 3 lignes

Mon conseil de dev à dev : Commence avec l’Org Server — c’est prêt en 2 clics. Dès que tu a besoin d’un scope custom, une audience propre ou un claim métier → passe au Custom.