Quand un utilisateur clique sur « Se connecter avec Google », son navigateur quitte votre application, visite Google, puis revient quelques secondes plus tard avec l'accès accordé. Votre serveur n'a jamais vu son mot de passe. Il a reçu un token, l'a vérifié, et a ouvert la session.

Ce mécanisme s'appelle OpenID Connect. Si vous construisez ou maintenez des applications web, vous allez le croiser.

Ce qu'est réellement OpenID Connect

OpenID Connect, souvent abrégé OIDC, est une couche d'identité construite au-dessus d'OAuth 2.0. OAuth 2.0 résout l'autorisation : donner à une application le droit d'accéder à des ressources au nom de quelqu'un. OpenID Connect y ajoute l'authentification : savoir qui est cette personne. Les deux concepts sont souvent confondus, et ce n'est pas une erreur anodine.

Une analogie utile : vous donnez votre carte d'accès à un collègue pour qu'il récupère un colis à votre place. Il peut entrer dans l'entrepôt, mais le gardien ne sait pas qui il est. OAuth 2.0 seul, c'est cette carte sans identité. OIDC y ajoute une pièce d'identité vérifiable.

OIDC ajoute trois choses à OAuth 2.0 :

  • Un ID Token : un jeton cryptographiquement signé qui certifie l'identité de l'utilisateur.
  • Un scope openid : le signal qui indique qu'on demande une authentification, pas juste une autorisation.
  • Un endpoint /userinfo : une API standardisée pour récupérer les informations du profil.

Les acteurs du protocole

Trois acteurs sont en jeu dans un flux OIDC.

L'utilisateur final est la personne qui veut se connecter à votre application.

Le Client est votre application (site web, app mobile, API). C'est lui qui initie la demande d'authentification et qui reçoit les tokens.

L'OpenID Provider (OP) est le service qui authentifie l'utilisateur et émet les tokens. Google, Microsoft, GitHub, Okta et Auth0 sont des OpenID Providers publics. Keycloak est un OpenID Provider que vous pouvez héberger vous-même.

Le flux Authorization Code, étape par étape

Plusieurs flux OIDC existent (implicite, hybride, PKCE), mais le flux Authorization Code est le plus sécurisé et le plus courant pour les applications web et mobiles.

Étape 1 : l'application redirige vers l'OpenID Provider

Votre application construit une URL et redirige le navigateur vers l'OpenID Provider :

GET https://accounts.google.com/o/oauth2/v2/auth
  ?response_type=code
  &client_id=VOTRE_CLIENT_ID
  &redirect_uri=https://monapp.com/callback
  &scope=openid profile email
  &state=abc123
  &nonce=xyz789

Les paramètres clés :

  • scope=openid : signal OIDC obligatoire. Sans lui, c'est de l'OAuth 2.0 pur.
  • scope=profile email : on demande aussi accès au nom et à l'email.
  • state : une valeur aléatoire pour prévenir les attaques CSRF.
  • nonce : une valeur aléatoire qui sera incluse dans l'ID Token pour prévenir les attaques par rejeu.

Étape 2 : l'utilisateur s'authentifie

L'utilisateur voit la page de connexion de Google (ou Keycloak, ou Auth0). Il saisit ses identifiants et accepte les permissions. C'est la seule fois où son mot de passe est impliqué. Votre application ne le verra jamais.

Étape 3 : l'OpenID Provider retourne un code d'autorisation

Après authentification, le navigateur revient vers votre redirect_uri avec un code à usage unique :

GET https://monapp.com/callback
  ?code=4/P7q7W91
  &state=abc123

Votre serveur vérifie que le state correspond à ce qu'il a envoyé, puis passe à l'étape suivante.

Étape 4 : échange du code contre des tokens

Votre serveur (côté backend, jamais depuis le navigateur) échange le code contre les tokens :

POST https://oauth2.googleapis.com/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=4/P7q7W91
&client_id=VOTRE_CLIENT_ID
&client_secret=VOTRE_SECRET
&redirect_uri=https://monapp.com/callback

L'OpenID Provider répond avec :

{
  "access_token": "ya29.a0AfH...",
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "1//0gLkM..."
}

C'est l'id_token qui fait toute la différence avec OAuth 2.0 classique.

L'ID Token : le cœur d'OpenID Connect

L'id_token est un JSON Web Token (JWT) signé cryptographiquement par l'OpenID Provider. Il contient ce que vous avez besoin de savoir sur l'utilisateur, et vous pouvez vérifier son authenticité sans faire de requête réseau supplémentaire.

Un JWT a trois parties séparées par des points : header.payload.signature.

Le Header

{
  "alg": "RS256",
  "kid": "abc123",
  "typ": "JWT"
}

L'algorithme RS256 signifie RSA + SHA-256. La clé publique correspondante est disponible à l'endpoint JWKS de l'OpenID Provider.

Le Payload (les claims)

{
  "iss": "https://accounts.google.com",
  "sub": "110169484474386276334",
  "aud": "VOTRE_CLIENT_ID",
  "iat": 1718620800,
  "exp": 1718624400,
  "nonce": "xyz789",
  "email": "alice@example.com",
  "name": "Alice Diallo",
  "picture": "https://...",
  "email_verified": true
}

Les claims à retenir :

ClaimSignification
iss (issuer)URL de l'OpenID Provider émetteur
sub (subject)Identifiant unique et stable de l'utilisateur
aud (audience)Votre client_id : le token est destiné à vous
iat (issued at)Timestamp d'émission du token
exp (expiration)Timestamp d'expiration du token
nonceDoit correspondre au nonce envoyé à l'étape 1

La Signature

Calculée à partir du header et du payload. En la vérifiant avec la clé publique de l'OpenID Provider, votre serveur s'assure que le token n'a pas été falsifié et qu'il provient bien du bon émetteur.

Valider l'ID Token correctement

Recevoir un ID Token ne suffit pas. Votre serveur doit effectuer ces vérifications avant d'ouvrir la session :

// Exemple avec jose (Node.js)
import {createRemoteJWKSet, jwtVerify} from 'jose'

const JWKS = createRemoteJWKSet(
  new URL('https://accounts.google.com/.well-known/openid-configuration')
)

const {payload} = await jwtVerify(idToken, JWKS, {
  issuer: 'https://accounts.google.com',
  audience: process.env.GOOGLE_CLIENT_ID,
})

if (payload.nonce !== expectedNonce) {
  throw new Error('Nonce invalide')
}

const userId = payload.sub

Les vérifications à ne pas sauter :

  1. La signature est valide (gérée par la librairie).
  2. L'issuer (iss) correspond à l'OpenID Provider attendu.
  3. L'audience (aud) contient votre client_id.
  4. Le token n'est pas expiré (exp > maintenant).
  5. Le nonce correspond à celui envoyé à l'étape 1.

Si vous omettez ces vérifications, votre application devient vulnérable aux attaques de substitution de token : un attaquant réutilise un token valide émis pour une autre application sur le même provider.

OpenID Connect Discovery

Chaque OpenID Provider publie un document de configuration à l'URL {issuer}/.well-known/openid-configuration.

Pour Google : https://accounts.google.com/.well-known/openid-configuration

Ce document contient tout ce dont votre client a besoin :

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "response_types_supported": [
    "code",
    "token",
    "id_token"
  ],
  "scopes_supported": [
    "openid",
    "email",
    "profile"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ]
}

La plupart des librairies OIDC modernes utilisent ce document automatiquement. Vous configurez l'URL de base du provider, le reste est récupéré et mis à jour dynamiquement. C'est utile quand le provider fait tourner des clés de signature : votre code n'a rien à changer.

PKCE : la sécurité pour les clients publics

Le flux Authorization Code suppose que votre client_secret reste confidentiel sur un serveur backend. Pour une SPA ou une application mobile, il n'y a pas de backend sécurisé pour stocker ce secret.

La solution s'appelle PKCE (Proof Key for Code Exchange). PKCE remplace le client_secret par un mécanisme cryptographique dynamique :

// Côté client, avant la redirection
const codeVerifier = generateRandomString(64)
const codeChallenge = base64url(sha256(codeVerifier))

// Inclus dans la redirection
?code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK...&code_challenge_method=S256

// Lors de l'échange du code
?code_verifier=dBjftJeZ4CVP...

L'OpenID Provider vérifie que sha256(code_verifier) === code_challenge. Même si un attaquant intercepte le code d'autorisation, il ne peut pas l'échanger sans le code_verifier, qui n'a jamais transité sur le réseau.

PKCE est recommandé pour tous les flux aujourd'hui, pas seulement pour les SPAs.

Les librairies à utiliser

Ne réimplémentez pas un flux OIDC à la main. Les librairies éprouvées gèrent la validation des tokens, le renouvellement de session et les cas limites sécurité qui ne sont pas évidents à la première lecture de la spec.

Pour Node.js et Nuxt

openid-client est la référence côté serveur :

pnpm add openid-client

import {discovery, randomPKCECodeVerifier, randomState} from 'openid-client'

const config = await discovery(
  new URL('https://accounts.google.com'),
  process.env.GOOGLE_CLIENT_ID,
  process.env.GOOGLE_CLIENT_SECRET
)

const codeVerifier = randomPKCECodeVerifier()
const state = randomState()
const codeChallenge = await calculatePKCECodeChallenge(codeVerifier)

const authUrl = authorizationUrl(config, {
  redirect_uri: 'https://monapp.com/callback',
  scope: 'openid profile email',
  state,
  code_challenge: codeChallenge,
  code_challenge_method: 'S256',
})

Pour les SPAs React et Vue

oidc-client-ts gère le flux complet côté navigateur :

pnpm add oidc-client-ts

import {UserManager} from 'oidc-client-ts'

const userManager = new UserManager({
  authority: 'https://accounts.google.com',
  client_id: 'VOTRE_CLIENT_ID',
  redirect_uri: 'https://monapp.com/callback',
  scope: 'openid profile email',
  response_type: 'code',
})

await userManager.signinRedirect()

const user = await userManager.signinRedirectCallback()
console.log(user.profile.email)

Pour les applications mobiles

expo-auth-session pour React Native, flutter_appauth pour Flutter. Ces deux librairies intègrent PKCE et gèrent les redirections via deep links sans configuration particulière.

Choisir son OpenID Provider

Keycloak

Keycloak est un serveur d'identité open source, hébergeable sur votre propre infrastructure. C'est le bon choix si vous gérez des données sensibles, avez des contraintes réglementaires locales, ou voulez éviter la dépendance à des services cloud étrangers.

docker run -p 8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:26.0 start-dev

Issuer URL : http://localhost:8080/realms/votre-realm

Auth0

Auth0 s'intègre en moins d'une heure avec la plupart des frameworks modernes. Le plan gratuit couvre jusqu'à 7 500 utilisateurs actifs. C'est le point d'entrée logique pour une PME qui veut avancer vite sans gérer d'infrastructure d' authentification.

Google et Microsoft

Si vos utilisateurs travaillent avec Google Workspace ou Microsoft 365, utiliser leur provider respectif simplifie l'expérience : connexion avec le compte professionnel existant, sans créer de mot de passe supplémentaire.

Les erreurs à éviter

La première erreur est de stocker l'ID Token dans le localStorage. Tout JavaScript sur la page peut le lire, y compris du code injecté via XSS. Utilisez des cookies HttpOnly et SameSite=Strict côté serveur.

Vérifier le nonce à la légère, ou ne pas le vérifier du tout, expose votre application aux attaques par rejeu. Un attaquant peut réutiliser un ID Token intercepté si rien ne l'en empêche.

Confondre ID Token et Access Token arrive plus souvent qu'on ne le croit, surtout quand on lit vite la documentation. L'un certifie une identité, l'autre autorise un accès à une API. Ils ont des rôles distincts.

L'expiration est souvent oubliée côté serveur. Un ID Token dure généralement une heure. Sans renouvellement silencieux via le refresh_token, les utilisateurs se retrouvent déconnectés sans comprendre pourquoi.

Enfin, la validation se fait côté serveur. Ce que le navigateur prétend ne prouve rien.

OpenID Connect vs SAML

SAML est l'ancien protocole d'authentification fédérée, encore présent dans les grandes entreprises et les systèmes legacy. La question du choix revient régulièrement.

OpenID ConnectSAML 2.0
FormatJWT (JSON)XML
IntégrationSimpleComplexe
Support mobileNatifDifficile
ÉcosystèmeModerneMature

Pour toute nouvelle application, choisissez OIDC. Si vous devez vous connecter à un système RH ou SSO d'entreprise existant (Salesforce, SAP, Active Directory Federation Services), vous rencontrerez SAML. Un OpenID Provider comme Keycloak peut servir de bridge entre les deux.

OIDC et le contexte africain

Trois avantages d'OpenID Connect correspondent bien aux réalités du terrain.

Les tokens JWT se vérifient localement, sans appel réseau vers l'OpenID Provider à chaque requête. La connectivité instable n'affecte que la connexion initiale. Une fois authentifié, l'utilisateur peut travailler même sur une liaison médiocre.

La gestion multi-appareils est simple par construction. Via le refresh token, quelqu'un qui travaille depuis son téléphone le matin et son ordinateur l'après-midi maintient la même session sans ressaisir son mot de passe.

Les scopes permettent de ne demander que les données strictement nécessaires. L'utilisateur consent explicitement à chaque catégorie d'information. C'est un avantage concret pour la conformité avec les réglementations africaines sur la protection des données personnelles, qui s'alignent progressivement sur le modèle RGPD.

Conclusion

OpenID Connect est le protocole derrière le bouton « Se connecter avec Google », et la base de la plupart des systèmes SSO modernes.

Ce qui compte concrètement : comprendre le flux Authorization Code, valider correctement l'ID Token, et choisir une librairie qui gère les cas limites à votre place. Ce sont les trois points où les implémentations maison échouent presque toujours.

Pour les PME africaines qui construisent des applications ou migrent vers des outils modernes, adopter OIDC dès le départ évite de devoir tout reprendre six mois plus tard quand les besoins de sécurité évoluent.

Chez CodexSoft, nous accompagnons les entreprises dans la mise en place d'architectures d'authentification sécurisées, que ce soit avec Keycloak en self-hosted, Auth0, ou l'intégration avec des providers existants. Premier échange gratuit.

Discutons de votre projet d'authentification

Prochaine lecture : SSO avec Keycloak, le guide d'implémentation pas à pas