OpenID Connect : qu'est-ce que c'est, protocole d'authentification et d'autorisation

Qu'est-ce qu'OpenID Connect ?

OpenID Connect (OIDC) est un protocole d'authentification ouvert construit comme une extension sur OAuth 2.0. Il standardise ce qui manquait à OAuth 2.0 : la vérification de l'identité de l'utilisateur. Si OAuth 2.0 répond à la question « quelle application a accès ? », alors OIDC répond « qui est exactement cet utilisateur ? ».

Le protocole utilise un ID Token — un JSON Web Token (JWT) qui contient un ensemble de claims : un identifiant de sujet unique, email, nom, avatar, horodatages d'émission et d'expiration. L'application cliente peut vérifier cryptographiquement l'ID Token — le serveur signe le token avec RS256 ou ES256, et le client vérifie la signature par rapport à la clé publique obtenue via l'endpoint JWKS.

Selon Auth0, 2025, plus de 78 % des applications mobiles utilisant une authentification tierce emploient OIDC via Google Sign-In ou Sign in with Apple. Cela fait du protocole le standard de facto pour la connexion sociale et l'authentification d'entreprise.

Comment fonctionne OpenID Connect

OpenID Connect définit plusieurs flux (flows) selon le type de client. Pour les applications mobiles, le standard est l'Authorization Code Flow avec Proof Key for Code Exchange (PKCE) — il assure la sécurité même sans client secret sur l'appareil.

Identity Provider et son rôle

Un Identity Provider (IdP) est un serveur qui authentifie les utilisateurs et émet des tokens. Dans l'écosystème OIDC, l'IdP fournit deux endpoints clés : l'Authorization Endpoint pour la connexion de l'utilisateur et le Token Endpoint pour échanger le code contre des tokens. Le client découvre les adresses de ces endpoints via la Discovery URL — le chemin standard /.well-known/openid-configuration, qui retourne un document JSON avec toute la configuration du fournisseur.

Chaque IdP publie son JWKS (JSON Web Key Set) — un ensemble de clés publiques pour vérifier la signature de l'ID Token. Le client met en cache ces clés et les utilise pour vérifier chaque token reçu sans contacter le serveur.

Authorization Code Flow avec PKCE

L'Authorization Code Flow est un processus en trois étapes. Premièrement, l'application mobile génère un code verifier (une chaîne aléatoire de 43 à 128 caractères) et son hash — le code challenge. L'application ouvre un navigateur ou WebView avec une URL contenant le client_id, redirect_uri, scope (openid profile email) et le code challenge. L'utilisateur saisit ses identifiants sur la page IdP et confirme son consentement. L'IdP redirige le navigateur vers l'application avec un authorization code.

Dans la deuxième étape, l'application envoie l'authorization code, le code verifier et le client_id au Token Endpoint du serveur. Le serveur vérifie le code verifier par rapport au code challenge stocké et retourne un ID Token, un Access Token et optionnellement un Refresh Token. Dans la troisième étape, l'application vérifie l'ID Token : elle valide la signature par rapport au JWKS, vérifie l'issuer (iss), l'audience (aud) et le temps d'expiration (exp). Si la vérification réussit, l'utilisateur est considéré comme authentifié.

PKCE (Proof Key for Code Exchange) élimine une vulnérabilité inhérente à l'Authorization Code Flow standard dans les clients publics. Étant donné qu'une application mobile ne peut pas stocker un client secret en toute sécurité, un attaquant qui intercepte l'authorization code pourrait l'échanger contre des tokens. Le code verifier résout ce problème : même si le code est intercepté, sans le code verifier original l'échange est impossible. Les OAuth Security Best Practices (RFC 9700) exigent PKCE pour tous les clients publics, y compris les applications mobiles.

ID Token et Access Token

OpenID Connect retourne deux tokens fondamentalement différents : l'ID Token et l'Access Token. L'ID Token est toujours un JWT que le client peut lire et vérifier par lui-même. Il contient des informations sur l'utilisateur et est utilisé pour l'authentification, pas pour l'accès à l'API.

Structure de l'ID Token

L'ID Token se compose d'un header, d'un payload et d'une signature, encodés en Base64 et séparés par des points. Le header contient alg (algorithme de signature) et kid (identifiant de clé). Le payload inclut les claims obligatoires : iss (issuer), sub (subject — ID unique de l'utilisateur), aud (audience — identifiant du client), exp (expiration), iat (issued at). Les claims optionnels incluent name, email, picture, locale.

Exemple d'un payload d'ID Token décodé de Google :

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ivan Petrov",
  "email": "ivan@example.com"
}

L'Access Token est un token opaque (chaîne arbitraire) ou JWT que le client transmet dans les requêtes API. Contrairement à l'ID Token, l'access token n'est pas destiné à être lu par le client — son format et son contenu ne sont connus que du serveur de ressources et du serveur d'autorisation. L'Access Token a un scope — une restriction de permission — et une durée de vie courte, généralement de 15 à 60 minutes.

Différences entre OpenID Connect et OAuth 2.0

OAuth 2.0 est un framework d'autorisation qui définit comment une application obtient l'accès aux ressources de l'utilisateur. OpenID Connect est une extension qui ajoute l'authentification à ce processus. La principale différence : OAuth 2.0 ne définit pas de format de token et ne donne pas à l'application un moyen de savoir qui a exactement fait la demande.

Quand choisir OpenID Connect

OpenID Connect est nécessaire lorsque l'application a besoin d'identifier l'utilisateur, pas seulement d'accéder à ses données. Si vous utilisez « Se connecter avec Google » ou « Se connecter avec Apple » — c'est OIDC. Si votre application appelle une API tierce au nom de l'utilisateur sans avoir besoin de connaître son identité — OAuth 2.0 pur suffit. Pour les systèmes d'entreprise avec Single Sign-On (SSO), le choix est clair : seulement OpenID Connect, car il fournit une déconnexion standardisée et une gestion de session.

Implémentation d'OpenID Connect dans les applications mobiles

L'intégration d'OpenID Connect dans une application mobile nécessite le choix de la bonne bibliothèque et la configuration correcte du flux. Pour Android, utilisez le gestionnaire d'identifiants (AndroidX Credentials) ou la bibliothèque AppAuth. Pour iOS, utilisez le framework AuthenticationServices avec ASWebAuthenticationSession.

Exemple de code en Kotlin (Android)

Ci-dessous un exemple de démarrage de l'Authorization Code Flow avec la bibliothèque AppAuth-Android. L'application crée une demande d'autorisation, ouvre un navigateur pour la connexion de l'utilisateur et traite le callback avec les tokens.

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

Exemple de code en Swift (iOS)

L'ASWebAuthenticationSession d'Apple fournit un navigateur intégré pour le flux OIDC avec prise en charge SSO via iCloud Keychain. La session démarre avec l'URL d'autorisation, et le callback est traité via un completion handler.

Lors du choix d'une bibliothèque pour OpenID Connect, considérez la prise en charge intégrée de PKCE : AppAuth-Android et AppAuth-iOS prennent en charge PKCE par défaut. Firebase Authentication utilise OIDC en interne pour Google Sign-In, Sign in with Apple et Microsoft — le développeur n'a pas besoin d'implémenter le flux manuellement. Pour les systèmes d'entreprise avec un IdP personnalisé (par exemple, Keycloak ou Okta), AppAuth reste le choix standard avec un contrôle total sur la configuration et la gestion des erreurs.

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()