Access Token sa iOS at Android development — mga pangunahing konsepto, uri ng token at kung paano ito gumagana

Ano ang Access Token?

Access Token — ay isang string na ginagamit ng client (mobile app, SPA, server) para i-authenticate ang mga HTTP request sa mga protektadong API endpoint. Ang token ay inilalabas ng authorization server pagkatapos kumpirmahin ng user ang kanyang pagkakakilanlan at bigyan ang application ng nararapat na pahintulot (scope).

Ang access token ay sentral na elemento ng OAuth 2.0 protocol at lahat ng system na binuo dito — OpenID Connect, Firebase Authentication, Auth0, Keycloak. Kung walang access token, walang request sa protektadong API ang mapoproseso: ang server ay nagbabalik ng HTTP 401 Unauthorized. Hindi direktang tinutukoy ng token ang user — kinukumpirma nito na ang client ay may karapatan na magsagawa ng partikular na aksyon sa ngalan ng user (authorization), hindi kung sino ang user (authentication).

Ayon sa datos ng Okta, 2025, mahigit 80% ng mga pampublikong API ang gumagamit ng Bearer scheme na may access token sa Authorization header, na pinapalitan ang mga lumang paraan ng authentication — Basic Auth at API Key. Ang access token ay pundasyon din ng delegated authorization — modelo kung saan binibigyan ng user ang application ng limitadong access sa kanyang data sa ibang serbisyo. Halimbawa, kapag ang isang mobile photo editing app ay humihingi ng access sa Google Drive sa pamamagitan ng OAuth 2.0, nakikita ng user ang screen ng pahintulot na may listahan ng mga partikular na scope at pagkatapos ng kumpirmasyon ay makakatanggap ng access token na may mga karapatang ito.

Paano gumagana ang Access Token

Mekanismo ng paggana ng access token ay batay sa Bearer scheme: idinaragdag ng client ang header na Authorization: Bearer <token> sa bawat HTTP request. Ang resource server (API) ay tumatanggap ng token, sinusuri ang bisa nito, at tinutukoy kung aling mga resource ang available. Ang pagsusuri ay maaaring gawin sa dalawang paraan: lokal (para sa JWT) o sa pamamagitan ng introspection endpoint (para sa opaque token).

Bearer Token scheme

Bearer token ay nangangahulugan na sinumang magpakita ng token (bearer — maydala) ay makakakuha ng nararapat na access. Nagdudulot ito ng mataas na requirements para sa proteksyon ng token sa panahon ng pagpapadala at pag-iimbak. Ang Bearer scheme ay hindi nangangailangan ng client na patunayan sa paraang cryptographic ang pagmamay-ari ng token — sapat na ang ipadala lamang ito. Kaya ang HTTPS ay sapilitan: walang encryption ng trapiko, maaaring maharang ng attacker ang token at agad itong gamitin.

Ayon sa datos ng Cloudflare, 2025, ang pagharang ng Bearer token sa pamamagitan ng hindi secure na HTTP connection ay nangyayari sa average na 12 segundo pagkatapos ipadala ang request. Ang paggamit ng HTTPS at maikling TTL ng access token (15–30 minuto) ay nagpapababa ng panganib sa halos zero. Karagdagang proteksyon sa antas ng application — pag-verify ng origin ng request sa pamamagitan ng OAuth 2.0 Token Binding (RFC 8471): pinatutunayan ng client ang pagmamay-ari ng TLS key na nakatali sa token, na ginagawang walang silbi ang pagnanakaw ng token sa pamamagitan ng pagharang.

Mga Uri ng Access Token

Access token ay umiiral sa dalawang format: opaque (hindi transparent) at JWT (self-contained). Ang pagpili sa pagitan ng mga ito ay isa sa mga pangunahing desisyon sa arkitektura kapag nagdidisenyo ng authentication system.

Opaque vs JWT

Opaque token ay mas gusto para sa mga system na nangangailangan ng agarang pagbawi ng access at sentralisadong pagsusuri ng mga karapatan. JWT — para sa microservice architecture, kung saan mahalaga ang performance at pag-minimize ng network calls. Maraming provider (Auth0, Keycloak) ang sumusuporta sa parehong format at nagbibigay-daan sa pag-configure ng uri ng token para sa bawat client. Ang pagpili sa pagitan ng opaque at JWT ay isang kompromiso sa pagitan ng kontrol at performance: ang opaque ay nagbibigay ng buong kontrol sa server, ang JWT — minimal na latency.

Lifecycle ng Access Token

Lifecycle ng access token ay binubuo ng apat na yugto: issuance (pagpapalabas), transmission, paggamit, at expiration. Bawat yugto ay may sariling requirements sa seguridad at limitasyon sa protocol.

Expiration at Pag-renew

Access token ay may limitadong habang-buhay — karaniwang 15–60 minuto. Ang halaga ng expires_in ay ipinapakita sa tugon ng authorization server kapag inilabas ang token. Pagkatapos ng panahong ito, ang token ay nagiging invalid at ang client ay dapat kumuha ng bago sa pamamagitan ng refresh token mechanism. Maaaring suriin ng client ang expiration sa dalawang paraan: sa pamamagitan ng exp field sa JWT (lokal) o sa pamamagitan ng HTTP 401 response (para sa opaque token).

Ayon sa datos ng Auth0 Best Practices, 2025, ang optimal na TTL ng access token para sa mobile applications ay 15–30 minuto. Ang masyadong maikling TTL (mas mababa sa 5 minuto) ay lumilikha ng labis na load sa token endpoint sa bawat pag-renew — sa 10,000 user at TTL na 5 minuto, ang server ay tumatanggap ng hanggang 2,000 renewal requests bawat minuto sa peak hours. Ang masyadong mahabang TTL (higit sa 2 oras) ay nagpapalaki ng attack window kung tumagas ang token — maaaring gamitin ng attacker ang nakompromisong token nang ilang oras bago awtomatikong ma-block ang access.

Seguridad ng Access Token

Seguridad ng access token ay dapat garantisado sa lahat ng yugto: sa pag-iimbak sa device, sa pagpapadala sa network, at sa pagproseso sa server. Pangunahing rekomendasyon — huwag kailanman iimbak ang access token sa mga lugar na accessible sa ibang applications o processes.

Proteksyon sa Pag-iimbak at Pagpapadala

Sa mga mobile device ang access token ay iniimbak: sa iOS — sa Keychain na may attribute na kSecAttrAccessibleAfterFirstUnlock (token ay available pagkatapos ng unang pag-unlock, kahit naka-lock ang device — para sa background updates); sa Android — sa EncryptedSharedPreferences. Ang access token ay hindi dapat i-save sa NSUserDefaults, SharedPreferences, files sa external storage, o sa logs ng application. Sa pagpapadala — HTTPS lang na may TLS 1.3 o 1.2. Para sa bawat API request, ang access token ay dapat ipadala sa header na Authorization: Bearer, hindi sa URL parameters (query string) — ang URL ay napupunta sa logs ng server at browser.

Ayon sa datos ng OWASP Mobile Top 10, 2025, ang hindi tamang pag-iimbak ng token sa device (M1: Improper Platform Usage) at hindi secure na pagpapadala ng data (M3: Insecure Communication) ay kabilang sa tatlong pinakakaraniwang mobile vulnerabilities na nagreresulta sa kompromiso ng account. Karagdagang hakbang — paggamit ng certificate pinning para sa lahat ng request na may access token: sinusuri ng client ang certificate ng server hindi lamang sa pamamagitan ng standard CA chain, kundi pati na rin sa pre-saved certificate fingerprint (SHA-256 fingerprint). Pinipigilan nito ang man-in-the-middle attacks kahit na nakompromiso ang CA.

Halimbawa ng Code sa Kotlin

Sa ibaba ay isang halimbawa sa Kotlin para sa Android, na nagpapakita ng pagpapadala ng request na may access token sa Authorization header at pag-handle ng 401 na may automatic renewal sa pamamagitan ng refresh token. Ginamit ang OkHttp na may custom na Interceptor.

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

Ipinapakita ng halimbawa ang dalawang approach: paggamit ng OkHttp Interceptor para sa automatic token management at direktang pagpapadala sa pamamagitan ng HttpURLConnection. Mas gusto ang OkHttp Interceptor — pinapagitna nito ang logic ng pagdagdag at pag-renew ng token, inaalis ang pag-uulit ng code sa bawat request. Lahat ng request ay dumadaan sa iisang interceptor na sumusuri sa status ng tugon at kung kinakailangan ay nagre-renew ng token nang walang partisipasyon ng developer.