Access Token în dezvoltarea iOS și Android — concepte cheie, tipuri de tokenuri și cum funcționează

Ce este Access Token?

Access Token — este un șir pe care clientul (aplicație mobilă, SPA, server) îl folosește pentru autentificarea cererilor HTTP către endpoint-urile API protejate. Tokenul este emis de serverul de autorizare după ce utilizatorul și-a confirmat identitatea și a acordat aplicației permisiunile corespunzătoare (scope).

Access token este elementul central al protocolului OAuth 2.0 și al tuturor sistemelor construite pe baza acestuia — OpenID Connect, Firebase Authentication, Auth0, Keycloak. Fără access token, nicio cerere către un API protejat nu va fi procesată: serverul returnează HTTP 401 Unauthorized. Tokenul nu identifică utilizatorul direct — confirmă că clientul are dreptul de a executa o acțiune specifică în numele utilizatorului (autorizare), nu cine este utilizatorul (autentificare).

Conform datelor Okta, 2025, peste 80% dintre API-urile publice folosesc schema Bearer cu access token în antetul Authorization, înlocuind metodele vechi de autentificare — Basic Auth și API Key. Access token este, de asemenea, baza pentru delegated authorization — modelul în care utilizatorul acordă aplicației acces limitat la datele sale pe un alt serviciu. De exemplu, când o aplicație mobilă de editare foto solicită acces la Google Drive prin OAuth 2.0, utilizatorul vede un ecran de consimțământ cu scope-urile specifice listate și, după confirmare, primește un access token cu aceste drepturi.

Cum funcționează Access Token

Mecanismul de funcționare al access token se bazează pe schema Bearer: clientul adaugă antetul Authorization: Bearer <token> la fiecare cerere HTTP. Serverul de resurse (API) primește tokenul, verifică validitatea acestuia și determină ce resurse sunt disponibile. Verificarea se poate face în două moduri: local (pentru JWT) sau prin introspection endpoint (pentru opaque token).

Schema Bearer Token

Bearer token înseamnă că oricine prezintă tokenul (bearer — deținătorul) obține accesul corespunzător. Acest lucru impune cerințe ridicate de protecție a tokenului în timpul transmiterii și stocării. Schema Bearer nu necesită ca clientul să demonstreze criptografic deținerea tokenului — este suficient să îl transmită. De aceea, HTTPS este obligatoriu: fără criptarea traficului, un atacator poate intercepta tokenul și îl poate folosi imediat.

Conform datelor Cloudflare, 2025, interceptarea unui Bearer token printr-o conexiune HTTP neprotejată are loc în medie în 12 secunde după trimiterea cererii. Utilizarea HTTPS și a unui TTL scurt al access token (15–30 minute) reduce riscul la aproape zero. Protecția suplimentară la nivel de aplicație — verificarea originii cererii prin OAuth 2.0 Token Binding (RFC 8471): clientul demonstrează deținerea cheii TLS asociate tokenului, ceea ce face inutilă furtul tokenului prin interceptare.

Tipuri de Access Token

Access token există în două formate: opaque (opac) și JWT (autosuficient). Alegerea între ele este una dintre deciziile arhitecturale cheie la proiectarea sistemului de autentificare.

Opaque vs JWT

Opaque token este preferat pentru sistemele care necesită revocare instantanee a accesului și verificare centralizată a drepturilor. JWT — pentru arhitectura de microservicii, unde performanța și minimizarea apelurilor de rețea sunt importante. Mulți furnizori (Auth0, Keycloak) suportă ambele formate și permit configurarea tipului de token pentru fiecare client. Alegerea între opaque și JWT este un compromis între control și performanță: opaque oferă control complet serverului, JWT — întârziere minimă.

Ciclul de viață al Access Token

Ciclul de viață al access token constă din patru faze: emitere (issuance), transmitere, utilizare și expirare. Fiecare fază are propriile cerințe de securitate și limitări protocolare.

Expirare și reînnoire

Access token are o durată de viață limitată — de obicei 15–60 de minute. Valoarea expires_in este indicată în răspunsul serverului de autorizare la emiterea tokenului. După expirarea acestei perioade, tokenul devine invalid, iar clientul trebuie să obțină unul nou prin mecanismul refresh token. Clientul poate verifica expirarea în două moduri: prin câmpul exp din JWT (local) sau prin răspunsul HTTP 401 (pentru opaque token).

Conform datelor Auth0 Best Practices, 2025, TTL-ul optim al access token pentru aplicațiile mobile este de 15–30 de minute. Un TTL prea scurt (sub 5 minute) creează o încărcare excesivă asupra token endpoint la fiecare reînnoire — la 10 000 de utilizatori și un TTL de 5 minute, serverul primește până la 2 000 de cereri de reînnoire pe minut în orele de vârf. Un TTL prea lung (peste 2 ore) mărește fereastra de atac în cazul scurgerii tokenului — un atacator poate folosi tokenul compromis timp de câteva ore înainte ca accesul să fie blocat automat.

Securitatea Access Token

Securitatea access token trebuie asigurată în toate etapele: la stocarea pe dispozitiv, la transmiterea prin rețea și la procesarea pe server. Recomandarea de bază — nu stocați niciodată access token în locuri accesibile altor aplicații sau procese.

Protecția la stocare și transmitere

Pe dispozitivele mobile access token se stochează: pe iOS — în Keychain cu atributul kSecAttrAccessibleAfterFirstUnlock (tokenul este disponibil după prima deblocare, chiar dacă dispozitivul este blocat — pentru actualizări în fundal); pe Android — în EncryptedSharedPreferences. Access token nu trebuie niciodată salvat în NSUserDefaults, SharedPreferences, fișiere pe stocarea externă sau în jurnalele aplicației. La transmitere — doar HTTPS cu TLS 1.3 sau 1.2. Pentru fiecare cerere API, access token trebuie transmis în antetul Authorization: Bearer, nu în parametrii URL (query string) — URL-ul ajunge în jurnalele serverelor și browserelor.

Conform datelor OWASP Mobile Top 10, 2025, stocarea incorectă a tokenurilor pe dispozitiv (M1: Improper Platform Usage) și transmiterea nesigură a datelor (M3: Insecure Communication) se află în top trei cele mai frecvente vulnerabilități mobile care duc la compromiterea conturilor. O măsură suplimentară — utilizarea certificate pinning pentru toate cererile cu access token: clientul verifică certificatul serverului nu doar prin lanțul CA standard, ci și prin amprenta certificatului salvată anterior (SHA-256 fingerprint). Acest lucru previne atacurile man-in-the-middle chiar și în cazul unui CA compromis.

Exemplu de cod în Kotlin

Mai jos este un exemplu în Kotlin pentru Android, care demonstrează trimiterea unei cereri cu access token în antetul Authorization și gestionarea 401 cu reînnoire automată prin refresh token. Se folosește OkHttp cu un Interceptor personalizat.

data class TokenStore {
    fun getAccessToken(): String? {
        // Citire din 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}")
}

Exemplul prezintă două abordări: utilizarea OkHttp Interceptor pentru gestionarea automată a tokenurilor și trimiterea directă prin HttpURLConnection. OkHttp Interceptor este preferat — centralizează logica de adăugare și reîmprospătare a tokenului, eliminând duplicarea codului în fiecare cerere. Toate cererile trec printr-un singur interceptor care verifică starea răspunsului și, dacă este necesar, reîmprospătează tokenul fără implicarea programatorului.