Access Token trong phát triển iOS và Android — khái niệm chính, loại token và cách hoạt động

Access Token là gì?

Access Token — là một chuỗi mà khách hàng (ứng dụng di động, SPA, máy chủ) sử dụng để xác thực các yêu cầu HTTP đến các endpoint API được bảo vệ. Token được máy chủ ủy quyền cấp sau khi người dùng xác nhận danh tính và cấp cho ứng dụng các quyền thích hợp (scope).

Access token là thành phần trung tâm của giao thức OAuth 2.0 và tất cả các hệ thống xây dựng trên nó — OpenID Connect, Firebase Authentication, Auth0, Keycloak. Không có access token, không có yêu cầu nào đến API được bảo vệ sẽ được xử lý: máy chủ trả về HTTP 401 Unauthorized. Token không xác định trực tiếp người dùng — nó xác nhận rằng khách hàng có quyền thực hiện một hành động cụ thể thay mặt người dùng (ủy quyền), chứ không phải người dùng là ai (xác thực).

Theo Okta, 2025, hơn 80% API công cộng sử dụng Bearer scheme với access token trong tiêu đề Authorization, thay thế các phương pháp xác thực lỗi thời — Basic Auth và API Key. Access token cũng là nền tảng cho ủy quyền được ủy thác (delegated authorization) — mô hình trong đó người dùng cho phép ứng dụng truy cập giới hạn vào dữ liệu của họ trên một dịch vụ khác. Ví dụ, khi một ứng dụng di động chỉnh sửa ảnh yêu cầu truy cập Google Drive qua OAuth 2.0, người dùng thấy màn hình đồng ý liệt kê các scope cụ thể và sau khi xác nhận nhận được access token với các quyền đó.

Access Token hoạt động như thế nào

Cơ chế access token dựa trên Bearer scheme: khách hàng thêm tiêu đề Authorization: Bearer <token> vào mỗi yêu cầu HTTP. Máy chủ tài nguyên (API) nhận token, xác thực nó và xác định tài nguyên nào có thể truy cập. Xác thực có thể xảy ra theo hai cách: cục bộ (đối với JWT) hoặc thông qua introspection endpoint (đối với opaque token).

Bearer Token Scheme

Bearer token có nghĩa là bất kỳ ai trình bày token (bearer) đều nhận được quyền truy cập tương ứng. Điều này đặt ra yêu cầu cao về bảo vệ token trong quá trình truyền và lưu trữ. Bearer scheme không yêu cầu khách hàng chứng minh quyền sở hữu token bằng mật mã — chỉ cần truyền nó là đủ. Do đó, HTTPS là bắt buộc: nếu không có mã hóa lưu lượng, kẻ tấn công có thể chặn token và sử dụng ngay lập tức.

Theo Cloudflare, 2025, việc chặn Bearer token qua kết nối HTTP không bảo mật xảy ra trung bình trong vòng 12 giây sau khi gửi yêu cầu. Sử dụng HTTPS và TTL ngắn của access token (15–30 phút) giảm rủi ro xuống gần như bằng không. Bảo vệ bổ sung ở cấp ứng dụng — kiểm tra nguồn gốc yêu cầu qua OAuth 2.0 Token Binding (RFC 8471): khách hàng chứng minh quyền sở hữu khóa TLS liên kết với token, làm cho việc đánh cắp token qua chặn bắt trở nên vô dụng.

Các loại Access Token

Access Token tồn tại ở hai định dạng: opaque và JWT (tự chứa). Lựa chọn giữa chúng là một trong những quyết định kiến trúc chính khi thiết kế hệ thống xác thực.

Opaque vs JWT

Opaque token được ưa chuộng cho các hệ thống yêu cầu thu hồi truy cập tức thì và kiểm tra quyền tập trung. JWT phù hợp cho kiến trúc microservice nơi hiệu suất và giảm thiểu cuộc gọi mạng là quan trọng. Nhiều nhà cung cấp (Auth0, Keycloak) hỗ trợ cả hai định dạng và cho phép cấu hình loại token cho từng khách hàng. Lựa chọn giữa opaque và JWT là sự đánh đổi giữa kiểm soát và hiệu suất: opaque trao toàn quyền kiểm soát cho máy chủ, JWT cung cấp độ trễ tối thiểu.

Vòng đời của Access Token

Vòng đời của access token bao gồm bốn giai đoạn: cấp phát, truyền, sử dụng và hết hạn. Mỗi giai đoạn có các yêu cầu bảo mật và giới hạn giao thức riêng.

Hết hạn và làm mới

Access Token có thời gian sống giới hạn — thường là 15–60 phút. Giá trị expires_in được chỉ ra trong phản hồi của máy chủ ủy quyền khi cấp token. Sau thời gian này, token trở nên không hợp lệ và khách hàng phải lấy token mới thông qua cơ chế refresh token. Khách hàng có thể kiểm tra hết hạn theo hai cách: qua trường exp trong JWT (cục bộ) hoặc qua phản hồi HTTP 401 (đối với opaque token).

Theo Auth0 Best Practices, 2025, TTL tối ưu của access token cho ứng dụng di động là 15–30 phút. TTL quá ngắn (dưới 5 phút) tạo ra tải quá mức lên token endpoint trong mỗi lần làm mới — với 10.000 người dùng và TTL 5 phút, máy chủ nhận tới 2.000 yêu cầu làm mới mỗi phút vào giờ cao điểm. TTL quá dài (trên 2 giờ) làm tăng cửa sổ tấn công khi token bị rò rỉ — kẻ tấn công có thể sử dụng token bị xâm phạm trong nhiều giờ trước khi quyền truy cập bị chặn tự động.

Bảo mật Access Token

Bảo mật của access token phải được đảm bảo ở tất cả các giai đoạn: trong quá trình lưu trữ trên thiết bị, trong quá trình truyền qua mạng và trong quá trình xử lý trên máy chủ. Khuyến nghị cơ bản là không bao giờ lưu trữ access token ở những nơi có thể truy cập được bởi các ứng dụng hoặc tiến trình khác.

Bảo vệ trong quá trình lưu trữ và truyền

Trên thiết bị di động, access token được lưu trữ: trên iOS — trong Keychain với thuộc tính kSecAttrAccessibleAfterFirstUnlock (token có thể truy cập sau lần mở khóa đầu tiên, ngay cả khi thiết bị bị khóa — cho cập nhật nền); trên Android — trong EncryptedSharedPreferences. Access token không bao giờ được lưu trong NSUserDefaults, SharedPreferences, tệp trên bộ nhớ ngoài hoặc nhật ký ứng dụng. Trong quá trình truyền — chỉ HTTPS với TLS 1.3 hoặc 1.2. Cho mỗi yêu cầu API, access token phải được gửi trong tiêu đề Authorization: Bearer, không phải trong tham số URL (query string) — URL sẽ xuất hiện trong nhật ký máy chủ và trình duyệt.

Theo OWASP Mobile Top 10, 2025, lưu trữ token không đúng cách trên thiết bị (M1: Improper Platform Usage) và truyền dữ liệu không an toàn (M3: Insecure Communication) nằm trong ba lỗ hổng di động phổ biến nhất dẫn đến xâm phạm tài khoản. Một biện pháp bổ sung — sử dụng certificate pinning cho tất cả các yêu cầu có access token: khách hàng xác minh chứng chỉ máy chủ không chỉ qua chuỗi CA tiêu chuẩn mà còn qua dấu vân tay chứng chỉ được lưu trước (SHA-256 fingerprint). Điều này ngăn chặn các cuộc tấn công man-in-the-middle ngay cả khi CA bị xâm phạm.

Ví dụ mã Kotlin

Dưới đây là ví dụ bằng Kotlin cho Android, minh họa việc gửi yêu cầu với access token trong tiêu đề Authorization và xử lý 401 với tự động làm mới qua refresh token. OkHttp với Interceptor tùy chỉnh được sử dụng.

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}")
}

Ví dụ cho thấy hai cách tiếp cận: sử dụng OkHttp Interceptor để quản lý token tự động và gửi trực tiếp qua HttpURLConnection. OkHttp Interceptor được ưa chuộng — nó tập trung hóa logic thêm và làm mới token, loại bỏ trùng lặp mã trong mỗi yêu cầu. Tất cả các yêu cầu đi qua một interceptor duy nhất kiểm tra trạng thái phản hồi và làm mới token khi cần mà không cần sự can thiệp của nhà phát triển.