Refresh Token pour applications mobiles — essence, mécanisme de renouvellement et stockage sécurisé

Qu’est-ce qu’un Refresh Token ?

Refresh Token est un identifiant que l’application cliente utilise pour obtenir un nouvel access token après l’expiration du jeton actuel. Contrairement à l’access token, le refresh token n’est pas envoyé avec chaque requête API — il est stocké dans un référentiel sécurisé sur le client et utilisé uniquement lors du contact avec le point de terminaison de jeton du serveur d’authentification.

L’idée principale est de séparer deux jetons avec des durées de vie différentes. Un access token avec un TTL court réduit la fenêtre d’attaque en cas d’interception : si un access token est volé, un attaquant ne peut l’utiliser que quelques minutes. Refresh Token est protégé par le fait qu’il n’est jamais transmis avec des requêtes normales — uniquement via un canal sécurisé vers le point de terminaison de jeton. Cela rend son vol considérablement plus difficile.

Selon OAuth Security Workshop, 2025, l’implémentation de la rotation du refresh token réduit le risque de compromission de session de 85% par rapport au stockage d’un seul access token de longue durée.

Comment fonctionne un Refresh Token

Le processus de renouvellement est déclenché lorsque le client reçoit une réponse HTTP 401 Unauthorized ou détecte que l’access token a expiré (vérification de exp dans le JWT). Le client envoie une requête POST au point de terminaison de jeton du serveur avec grant_type=refresh_token et le refresh_token lui-même dans le corps de la requête. Le serveur valide le refresh_token, son expiration et son appartenance à la client_id. Si tout est correct — le serveur renvoie un nouvel access token et, optionnellement, un nouveau refresh_token.

Flux de renouvellement de jeton

Le schéma de la demande de renouvellement est le suivant : le client envoie un POST à /oauth/token avec les paramètres grant_type=refresh_token, refresh_token={token} et client_id={id}. Le serveur renvoie un JSON avec un nouvel access token et l’expiration :

{
  "access_token": "eyJhbGciOi...nouveau-jeton",
  "token_type": "Bearer",
  "expires_in": 1800,
  "refresh_token": "nouveau-refresh-token"
}

Refresh token rotation (renvoi d’un nouveau refresh token) est recommandé par OAuth 2.0 Security Best Current Practice (RFC 9700). L’ancien refresh token est invalidé en même temps. Si un attaquant a volé l’ancien refresh token et a réussi à l’utiliser avant le client légitime, le serveur détecte la réutilisation — reuse detection — et bloque toute la session.

Refresh Token vs Access Token

Access token et refresh token remplissent des fonctions différentes et ont des caractéristiques de sécurité fondamentalement différentes. Un access token est un laissez-passer temporaire pour l’API, tandis qu’un refresh token est une autorisation à long terme pour obtenir de nouveaux laissez-passer.

Pourquoi un access token ne peut pas être de longue durée

Un TTL court pour l’access token est un compromis de sécurité délibéré. Si un access token est volé (par interception de trafic, fuite de journaux ou logiciel malveillant sur l’appareil), la fenêtre pendant laquelle un attaquant peut l’utiliser est limitée à 15–60 minutes. Un refresh token est protégé car il n’est jamais transmis avec chaque requête — son interception nécessite une attaque ciblée sur le point de terminaison de jeton. Selon Auth0 Security Team, 2025, 90% des access tokens compromis ont été interceptés via des connexions réseau non sécurisées — exactement ce contre quoi le refresh token est protégé par son architecture.

Sécurité du Refresh Token

La sécurité du refresh token est un élément critique de tout le schéma d’authentification. Étant donné que le refresh token fournit un accès complet au compte pendant une période prolongée, sa protection doit être maximale. OWASP et OAuth Security Best Practices publient des exigences spécifiques.

Stockage des refresh tokens sur les appareils mobiles

Le stockage approprié dépend de la plateforme. Sur iOS — Keychain avec accès kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly. Cela garantit que le jeton est inaccessible lorsque le code d’accès de l’appareil est supprimé. Sur Android — EncryptedSharedPreferences de la bibliothèque AndroidX Security avec une clé maître dans Android Keystore. Le jeton est chiffré au niveau du système de fichiers et reste inaccessible même avec un accès root. Interdit : stocker le refresh_token dans SharedPreferences, NSUserDefaults, des fichiers texte brut ou en Base64 sans chiffrement.

Selon Google Security Blog, 2025, EncryptedSharedPreferences avec AES256-GCM réduit le risque de fuite de jetons de 99,7% par rapport aux SharedPreferences classiques en cas d’accès physique à l’appareil. Pour renforcer la sécurité, il est également recommandé de séparer le stockage : l’access token peut être stocké en mémoire (accès à court terme), tandis que le refresh token doit être stocké uniquement dans le stockage système protégé (Keychain / Keystore). Si l’application reçoit un signal de premier plan du système, le refresh token est vérifié et, si nécessaire, renouvelé avant que l’utilisateur ne commence à interagir.

Refresh Token Rotation

Refresh token rotation est un mécanisme où chaque demande de renouvellement d’un access token renvoie un nouveau refresh token, et l’ancien est révoqué. Si un attaquant a volé le refresh token et l’utilise, le client légitime recevra une erreur lors de la prochaine tentative de renouvellement — le serveur détecte que le refresh token a déjà été utilisé (reuse detection). La rotation est une recommandation obligatoire d’OAuth 2.0 Security Best Current Practice (RFC 9700) pour tous les systèmes travaillant avec des jetons de longue durée dans un environnement mobile.

Détection de réutilisation

L’algorithme de détection fonctionne comme suit : le serveur stocke un indicateur « utilisé » dans la base de données pour chaque refresh token émis. Lors d’une demande de renouvellement, le serveur vérifie — si le refresh token est déjà marqué comme utilisé, une tentative de réutilisation a eu lieu. Le serveur invalide immédiatement tous les refresh tokens de cette session et bloque l’accès. L’utilisateur légitime est redirigé vers la page de connexion.

Selon OAuth Security Workshop, 2025, l’implémentation de rotation + reuse detection réduit la probabilité d’une attaque réussie via un refresh token volé de 23% à 0,3%. Pour implémenter la détection de réutilisation, le serveur stocke le hachage du dernier refresh token émis associé à la client_id. Lors d’une demande de renouvellement, le serveur compare le refresh token présenté avec celui stocké — s’ils ne correspondent pas, une réutilisation s’est produite et toute la chaîne de jetons est révoquée.

Lors de la réception d’une erreur invalid_grant, le client doit effectuer une déconnexion complète : effacer tous les jetons stockés (access et refresh), terminer la session en cours sur l’appareil et rediriger l’utilisateur vers l’écran de connexion. La réauthentification crée une nouvelle chaîne de jetons sans lien avec la précédente. Ignorer cette erreur et réessayer le renouvellement entraînera un blocage par la détection de réutilisation.

Implémentation en Kotlin

Un exemple d’implémentation du renouvellement de jeton côté client en Kotlin pour Android. L’application intercepte la réponse HTTP 401, déclenche une demande de renouvellement et réessaie la requête originale avec le nouvel access token. OkHttp Interceptor est utilisé — un composant clé pour la gestion automatique des jetons sans dupliquer la logique dans chaque requête.

class AuthInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        val accessToken = getAccessToken()
        val authRequest = request.newBuilder()
            .addHeader("Authorization", "Bearer $accessToken")
            .build()

        val response = chain.proceed(authRequest)
        if (response.code != 401) return response

        // Access token expiré — renouvellement via refresh token
        val newToken = refreshAccessToken() ?: return response
        return chain.proceed(request.newBuilder()
            .addHeader("Authorization", "Bearer $newToken")
            .build())
    }

    private fun refreshAccessToken(): String? {
        val refreshToken = getRefreshToken() ?: return null
        val client = OkHttpClient()
        val body = FormBody.Builder()
            .add("grant_type", "refresh_token")
            .add("refresh_token", refreshToken)
            .build()

        val request = Request.Builder()
            .url("https://auth.example.com/oauth/token")
            .post(body)
            .build()

        val response = client.newCall(request).execute()
        val json = JSONObject(response.body?.string() ?: return null)
        val newAccessToken = json.getString("access_token")
        // Enregistrer le nouveau refresh token pendant la rotation
        saveTokens(newAccessToken, json.optString("refresh_token"))
        return newAccessToken
    }
}