Access Token dans le développement iOS et Android — concepts clés, types de tokens et fonctionnement

Qu'est-ce qu'un Access Token ?

Access Token ꬀ une chaîne qu'un client (application mobile, SPA, serveur) utilise pour authentifier les requêtes HTTP aux endpoints d'API protégés. Le token est émis par le serveur d'autorisation après que l'utilisateur a confirmé son identité et accordé à l'application les autorisations appropriées (scope).

L'access token est un élément central du protocole OAuth 2.0 et de tous les systèmes construits dessus ꬀ OpenID Connect, Firebase Authentication, Auth0, Keycloak. Sans access token, aucune requête vers une API protégée ne sera traitée : le serveur renvoie HTTP 401 Unauthorized. Le token n'identifie pas directement l'utilisateur ꬀ il confirme que le client a le droit d'effectuer une action spécifique au nom de l'utilisateur (autorisation), et non qui est l'utilisateur (authentification).

Selon Okta, 2025, plus de 80% des API publiques utilisent le schéma Bearer avec un access token dans l'en-tête Authorization, remplaçant les méthodes d'authentification obsolètes ꬀ Basic Auth et API Key. L'access token est également le fondement de l'autorisation déléguée ꬀ un modèle dans lequel l'utilisateur accorde à une application un accès limité à ses données sur un autre service. Par exemple, lorsqu'une application mobile de retouche photo demande l'accès à Google Drive via OAuth 2.0, l'utilisateur voit un écran de consentement listant les scopes spécifiques, et après confirmation reçoit un access token avec ces autorisations.

Comment fonctionne un Access Token

Mécanisme de l'access token repose sur le schéma Bearer : le client ajoute l'en-tête Authorization: Bearer <token> à chaque requête HTTP. Le serveur de ressources (API) reçoit le token, le valide et détermine quelles ressources sont accessibles. La validation peut se faire de deux manières : localement (pour JWT) ou via un endpoint d'introspection (pour les tokens opaques).

Schéma Bearer Token

Bearer token signifie que quiconque présente le token (bearer) obtient l'accès correspondant. Cela impose des exigences élevées de protection du token lors de la transmission et du stockage. Le schéma Bearer n'exige pas que le client prouve cryptographiquement la possession du token ꬀ il suffit de le transmettre. Par conséquent, HTTPS est obligatoire : sans chiffrement du trafic, un attaquant peut intercepter le token et l'utiliser immédiatement.

Selon Cloudflare, 2025, l'interception d'un Bearer token via une connexion HTTP non sécurisée se produit en moyenne dans les 12 secondes suivant l'envoi de la requête. L'utilisation de HTTPS et d'un TTL court d'access token (15–30 minutes) réduit le risque à pratiquement zéro. Protection supplémentaire au niveau de l'application ꬀ vérification de l'origine de la requête via OAuth 2.0 Token Binding (RFC 8471) : le client prouve la possession de la clé TLS liée au token, rendant le vol du token par interception inutile.

Types d'Access Token

Access Token existe en deux formats : opaque et JWT (autonome). Le choix entre eux est l'une des décisions architecturales clés lors de la conception d'un système d'authentification.

Opaque vs JWT

Opaque token est préférable pour les systèmes nécessitant une révocation d'accès instantanée et une vérification centralisée des droits. JWT est pour l'architecture de microservices où la performance et la minimisation des appels réseau sont importantes. De nombreux fournisseurs (Auth0, Keycloak) supportent les deux formats et permettent de configurer le type de token pour chaque client. Le choix entre opaque et JWT est un compromis entre contrôle et performance : opaque donne un contrôle total au serveur, JWT offre une latence minimale.

Cycle de vie de l'Access Token

Cycle de vie d'un access token comprend quatre phases : émission, transmission, utilisation et expiration. Chaque phase a ses propres exigences de sécurité et contraintes protocolaires.

Expiration et renouvellement

Access Token a une durée de vie limitée ꬀ généralement 15–60 minutes. La valeur expires_in est indiquée dans la réponse du serveur d'autorisation lors de l'émission du token. Après ce délai, le token devient invalide et le client doit en obtenir un nouveau via le mécanisme de refresh token. Le client peut vérifier l'expiration de deux manières : par le champ exp dans le JWT (localement) ou par la réponse HTTP 401 (pour les tokens opaques).

Selon Auth0 Best Practices, 2025, le TTL optimal d'access token pour les applications mobiles est de 15–30 minutes. Un TTL trop court (moins de 5 minutes) crée une charge excessive sur l'endpoint du token lors de chaque renouvellement ꬀ avec 10 000 utilisateurs et un TTL de 5 minutes, le serveur reçoit jusqu'à 2 000 requêtes de renouvellement par minute aux heures de pointe. Un TTL trop long (plus de 2 heures) augmente la fenêtre d'attaque en cas de fuite du token ꬀ un attaquant peut utiliser le token compromis pendant plusieurs heures avant que l'accès ne soit automatiquement bloqué.

Sécurité de l'Access Token

Sécurité de l'access token doit être assurée à toutes les étapes : lors du stockage sur l'appareil, lors de la transmission sur le réseau et lors du traitement sur le serveur. La recommandation de base est de ne jamais stocker l'access token dans des endroits accessibles à d'autres applications ou processus.

Protection lors du stockage et de la transmission

Sur les appareils mobiles, l'access token est stocké : sur iOS ꬀ dans le Keychain avec l'attribut kSecAttrAccessibleAfterFirstUnlock (le token est accessible après le premier déverrouillage, même si l'appareil est verrouillé ꬀ pour les mises à jour en arrière-plan) ; sur Android ꬀ dans EncryptedSharedPreferences. L'access token ne doit jamais être sauvegardé dans NSUserDefaults, SharedPreferences, des fichiers sur le stockage externe ou les journaux d'application. Lors de la transmission ꬀ uniquement HTTPS avec TLS 1.3 ou 1.2. Pour chaque requête API, l'access token doit être envoyé dans l'en-tête Authorization: Bearer, et non dans les paramètres d'URL (query string) ꬀ les URL se retrouvent dans les journaux des serveurs et navigateurs.

Selon OWASP Mobile Top 10, 2025, le stockage inapproprié des tokens sur l'appareil (M1 : Improper Platform Usage) et la transmission non sécurisée des données (M3 : Insecure Communication) font partie des trois vulnérabilités mobiles les plus courantes entraînant la compromission des comptes. Une mesure supplémentaire ꬀ utiliser le certificate pinning pour toutes les requêtes avec access token : le client vérifie le certificat du serveur non seulement via la chaîne CA standard, mais aussi via une empreinte de certificat préenregistrée (SHA-256 fingerprint). Cela empêche les attaques man-in-the-middle même avec un CA compromis.

Exemple de code en Kotlin

Ci-dessous un exemple en Kotlin pour Android, démontrant l'envoi d'une requête avec un access token dans l'en-tête Authorization et la gestion de 401 avec renouvellement automatique via un refresh token. OkHttp avec un Interceptor personnalisé est utilisé.

data class TokenStore {
    fun getAccessToken(): String? {
        // Reading from EncryptedSharedPreferences
        return encryptPrefs.getString("access_token", null)
    }

    fun isTokenExpired(): Boolean {
        val expiresAt = encryptPrefs.getLong("expires_at", 0)
        return System.currentTimeMillis() > expiresAt
    }
}

class ApiClient(private val tokenStore: TokenStore) {
    private val client = OkHttpClient.Builder()
        .addInterceptor(AuthInterceptor(tokenStore))
        .build()

    fun fetchUserProfile(): UserProfile? {
        val request = Request.Builder()
            .url("https://api.example.com/user/profile")
            .get()
            .build()

        val response = client.newCall(request).execute()
        return if (response.isSuccessful) {
            parseProfile(response.body?.string() ?: return null)
        } else null
    }
}

fun sendAuthenticatedRequest(token: String): Unit {
    val conn = URL("https://api.example.com/data").openConnection() as HttpURLConnection
    conn.setRequestProperty("Authorization", "Bearer $token")
    conn.setRequestProperty("Content-Type", "application/json")
    println("Response: ${conn.responseCode}")
}

L'exemple montre deux approches : utiliser OkHttp Interceptor pour la gestion automatique des tokens et l'envoi direct via HttpURLConnection. OkHttp Interceptor est préférable ꬀ il centralise la logique d'ajout et de renouvellement du token, éliminant la duplication de code dans chaque requête. Toutes les requêtes passent par un seul interceptor qui vérifie le statut de la réponse et renouvelle le token si nécessaire sans intervention du développeur.