OAuth 2.0 : ce que c'est et comment fonctionne le protocole d'autorisation

Qu'est-ce que OAuth 2.0 ?

OAuth 2.0 est un protocole d'autorisation défini dans l'IETF RFC 6749 qui permet à des applications tierces d'obtenir un accès limité aux ressources d'un utilisateur sans révéler son nom d'utilisateur et son mot de passe. Le protocole résout un problème fondamental du modèle de mot de passe : une application à qui vous confiez votre mot de passe obtient un accès illimité à toutes les données du compte. OAuth 2.0 remplace cette approche en émettant un jeton temporaire avec un périmètre d'accès explicitement limité.

L'architecture d'OAuth 2.0 est l'autorisation déléguée. L'utilisateur (Resource Owner) autorise une application (Client) à accéder à ses données stockées sur un serveur de ressources (Resource Server) par l'intermédiaire d'un serveur d'autorisation (Authorization Server). Le serveur d'autorisation émet un Access Token, une chaîne cryptographique que l'application présente au serveur de ressources pour accéder aux données. Une différence importante entre OAuth 2.0 et SAML ou OpenID Connect : OAuth 2.0 résout la tâche d'autorisation (ce qui est autorisé), pas l'authentification (qui est l'utilisateur). Pour l'authentification, le protocole OpenID Connect (OIDC) est construit au-dessus d'OAuth 2.0.

Le protocole est pris en charge par toutes les grandes plateformes. Google utilise OAuth 2.0 pour accéder aux Google APIs (Gmail, Drive, Calendar), Facebook pour l'API Graph, Apple pour Sign in with Apple (ASAuthorizationAppleIDProvider) et GitHub pour l'accès aux dépôts. Dans le contexte du développement mobile, OAuth 2.0 est le mécanisme standard d'intégration de services tiers : connexion via les réseaux sociaux, accès au stockage cloud et publication de contenu au nom de l'utilisateur.

Rôles et composants d'OAuth 2.0

Le protocole OAuth 2.0 définit quatre rôles dont l'interaction forme le cycle d'autorisation complet. Comprendre chaque rôle est essentiel pour implémenter correctement le protocole dans une application mobile.

Les quatre rôles du protocole

Les entités clés du protocole sont l'Access Token, le Refresh Token et le Authorization Code. L'Access Token est un jeton de courte durée (généralement 15 à 60 minutes) présenté au serveur de ressources à chaque demande de données. Le Refresh Token est un jeton de longue durée (jours ou semaines) utilisé pour obtenir un nouvel Access Token sans que l'utilisateur ait à se reconnecter. L'Authorization Code est un code temporaire émis après l'autorisation de l'utilisateur et échangé contre un Access Token et un Refresh Token.

Types d'octroi : scénarios d'autorisation

OAuth 2.0 définit plusieurs types d'octroi, des scénarios d'obtention de jetons, chacun conçu pour un type de client et un contexte de sécurité spécifiques. Choisir le bon type d'octroi est une décision architecturale critique lors de la conception de l'autorisation dans une application mobile.

Les principaux types d'octroi sont : Authorization Code (le plus sûr pour les applications mobiles et web avec un composant serveur), Authorization Code avec PKCE (Proof Key for Code Exchange : pour les applications mobiles et SPA sans backend serveur), Client Credentials (pour l'authentification serveur à serveur sans participation de l'utilisateur) et Resource Owner Password Credentials (obsolète : transmet le mot de passe directement). PKCE est une extension obligatoire pour les clients publics (applications mobiles, SPA) selon les recommandations d'OAuth Security BCP (RFC 9700).

Principaux types d'octroi

• Authorization Code + PKCE est le type d'octroi recommandé pour les applications mobiles natives. Le client génère un code_verifier cryptographique, calcule un code_challenge (hash SHA-256) et le serveur vérifie la correspondance lors de l'échange du code contre un jeton. Cela empêche l'interception du code d'autorisation entre l'application et le serveur
• Client Credentials est utilisé pour l'autorisation machine à machine où le client est connu et authentifié. L'application obtient un jeton en utilisant son client_id et son client_secret. Aucune participation de l'utilisateur n'est requise. Scénario typique : une application serveur appelle une API pour le traitement par lots de données
• Device Authorization Grant est destiné aux appareils sans navigateur (Smart TV, IoT). L'utilisateur suit un lien sur un autre appareil et saisit un code. Utilisé, par exemple, lors de l'autorisation de Netflix sur un téléviseur via un smartphone
• Resource Owner Password Credentials est un type d'octroi obsolète interdit par OAuth Security BCP. Le mot de passe est transmis directement au client, violant le principe d'authentification à connaissance nulle. Utilisé uniquement pour la migration depuis des systèmes legacy

Authorization Code Flow avec PKCE pour les applications mobiles

Authorization Code Flow avec PKCE est la configuration recommandée d'OAuth 2.0 pour les applications mobiles natives. PKCE (Proof Key for Code Exchange) ajoute une couche de protection supplémentaire qui empêche les attaques d'interception du code d'autorisation. Le protocole est décrit dans l'IETF RFC 7636.

Séquence étape par étape de PKCE

La séquence des étapes : (1) le client génère un code_verifier aléatoire (une chaîne de 43 à 128 caractères utilisant uniquement des caractères non réservés), (2) le client calcule code_challenge = SHA-256(code_verifier), (3) le client ouvre un navigateur pour l'autorisation de l'utilisateur sur le serveur d'autorisation, en transmettant code_challenge, (4) après autorisation réussie, le serveur renvoie le code d'autorisation à l'application via un schéma d'URI personnalisé (lien profond de l'application), (5) le client envoie le code d'autorisation + code_verifier au serveur, (6) le serveur vérifie SHA-256(code_verifier) === code_challenge et émet un Access Token + Refresh Token.

L'avantage de PKCE : même si un attaquant intercepte le code d'autorisation dans le schéma d'URI, il ne peut pas l'échanger contre un jeton sans le code_verifier, qui n'est connu que du client légitime. Dans les applications mobiles, pour ouvrir le navigateur, il faut utiliser Chrome Custom Tabs (Android) ou ASWebAuthenticationSession (iOS) ; cela garantit que le navigateur système ne peut pas accéder au code_verifier depuis la mémoire de l'application.

Implémentation d'OAuth 2.0 sur Android via AppAuth

AppAuth est l'implémentation de référence d'OAuth 2.0 et d'OpenID Connect pour les applications natives, recommandée par l'IETF. La bibliothèque prend en charge PKCE, Chrome Custom Tabs, les schémas d'URI personnalisés pour retourner le code d'autorisation et l'actualisation automatique des jetons. AppAuth pour Android est disponible via la dépendance `net.openid:appauth:0.11.1`.

val serviceConfig = AuthorizationServiceConfiguration.fromUrl(
    Uri.parse("https://accounts.google.com/.well-known/openid-configuration")
)

val request = AuthorizationRequest.Builder(
    serviceConfig,
    "CLIENT_ID.apps.googleusercontent.com",
    ResponseTypeValues.CODE,
    Uri.parse("com.example.app:/oauth2callback")
)
.setScope("openid profile email")
.setCodeVerifier(
    CodeVerifierUtil.generateRandomCodeVerifier()
)
.build()

val authService = AuthorizationService(context)
val intent = authService.getAuthorizationRequestIntent(request)

// Lancer Chrome Custom Tab pour l'autorisation
startActivityForResult(intent, REQUEST_CODE_AUTH)

Après avoir reçu le code d'autorisation (onActivityResult), l'application l'échange contre un Access Token et un Refresh Token via une TokenRequest. Les jetons sont sauvegardés dans SharedPreferences avec chiffrement via EncryptedSharedPreferences (Android Security Crypto). Le Refresh Token doit être stocké dans le KeyStore, un magasin de clés matériel inaccessible aux autres applications. À chaque expiration de l'Access Token, l'application utilise le Refresh Token pour en obtenir un nouveau : l'utilisateur n'a pas besoin de se réauthentifier.

// Échanger le code d'autorisation contre des jetons
val data = intent?.data ?: return
val resp = AuthorizationResponse.fromIntent(data)
val exchangeReq = resp?.createTokenExchangeRequest()
    ?: return

authService.performTokenRequest(
    exchangeReq,
    ClientAuthentication.none()
) { tokenResp, ex ->
    if (tokenResp != null) {
        // Access Token et Refresh Token reçus
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // Sauvegarder dans EncryptedSharedPreferences
        saveTokens(accessToken, refreshToken)
    }
}

Le code ci-dessus illustre le flux complet d'OAuth 2.0 avec PKCE : création de la configuration du serveur via OpenID Connect Discovery, génération d'une demande d'autorisation avec code_verifier, lancement de Chrome Custom Tab, réception du code d'autorisation via un schéma d'URI personnalisé et échange du code contre des jetons via une TokenRequest. Il est important de gérer l'expiration de l'Access Token : lors de la réception d'une réponse HTTP 401 du Resource Server, l'application doit utiliser le Refresh Token pour obtenir un nouvel Access Token et réexécuter la demande.

Sécurité d'OAuth 2.0 : attaques typiques et protection

OAuth 2.0 est un protocole complexe avec de nombreux vecteurs d'attaque. L'IETF Security BCP (RFC 9700) décrit plus de 20 classes de vulnérabilités d'OAuth 2.0. Pour les applications mobiles, les plus critiques sont : l'interception du code d'autorisation via des schémas d'URI personnalisés, les attaques CSRF sur les points de terminaison de callback, le vol du Refresh Token depuis un stockage non sécurisé et l'usurpation du client par interception d'intent.

La protection contre ces attaques comprend des mesures obligatoires : (1) PKCE avec code_challenge S256 : empêche l'interception du code d'autorisation même en cas d'interception du schéma d'URI ; (2) utilisation d'un paramètre nonce ou state pour prévenir CSRF : le serveur vérifie que le code d'autorisation correspond à la demande d'origine ; (3) stockage du Refresh Token uniquement dans KeyStore (Android) ou Keychain (iOS), jamais dans SharedPreferences ou UserDefaults ; (4) utilisation de TLS avec Certificate Pinning pour se protéger contre MITM au niveau transport ; (5) validation de redirect_uri : le serveur d'autorisation doit valider strictement la correspondance avec l'URI enregistré.

Recommandations supplémentaires de l'IETF : les applications mobiles doivent utiliser AppAuth ou des bibliothèques similaires ayant passé des audits de sécurité ; ne pas compter sur WebView pour OAuth (WebView n'isole pas les données de l'application principale) ; implémenter la rotation automatique du Refresh Token (chaque Refresh Token peut être utilisé une seule fois) ; ajouter Certificate Pinning via TrustManager pour Android et URLSession pour iOS. OpenID Connect Discovery (point de terminaison well-known) aide à déterminer automatiquement les points de terminaison corrects du serveur d'autorisation et à éviter les redirections vers des pages de phishing.