Access Token ในการพัฒนา iOS และ Android — แนวคิดหลัก ประเภทของโทเค็น และวิธีการทำงาน

Access Token คืออะไร?

Access Token — คือสตริงที่ไคลเอ็นต์ (แอปมือถือ, SPA, เซิร์ฟเวอร์) ใช้เพื่อยืนยันตัวตนคำขอ HTTP ไปยัง API เอนด์พอยต์ที่ได้รับการป้องกัน โทเค็นถูกออกโดยเซิร์ฟเวอร์อนุญาตสิทธิ์หลังจากที่ผู้ใช้ยืนยันตัวตนและให้สิทธิ์ที่เหมาะสม (scope) แก่แอปพลิเคชัน

Access token เป็นองค์ประกอบหลักของโปรโตคอล OAuth 2.0 และระบบทั้งหมดที่สร้างบนนั้น — OpenID Connect, Firebase Authentication, Auth0, Keycloak หากไม่มี access token คำขอใดๆ ไปยัง API ที่ได้รับการป้องกันจะไม่ได้รับการประมวลผล: เซิร์ฟเวอร์จะส่งกลับ HTTP 401 Unauthorized โทเค็นไม่ได้ระบุตัวตนผู้ใช้โดยตรง — แต่ยืนยันว่าไคลเอ็นต์มีสิทธิ์ดำเนินการเฉพาะในนามของผู้ใช้ (การอนุญาต) ไม่ใช่ผู้ใช้คือใคร (การยืนยันตัวตน)

ตามข้อมูลจาก Okta, 2025 มากกว่า 80% ของ API สาธารณะใช้ Bearer scheme กับ access token ในส่วนหัว Authorization แทนที่วิธีการยืนยันตัวตนที่ล้าสมัย — Basic Auth และ API Key Access token ยังเป็นพื้นฐานสำหรับการอนุญาตแบบมอบหมาย (delegated authorization) — โมเดลที่ผู้ใช้ให้แอปพลิเคชันเข้าถึงข้อมูลของตนบนบริการอื่นอย่างจำกัด ตัวอย่างเช่น เมื่อแอปมือถือแก้ไขรูปภาพขอเข้าถึง Google Drive ผ่าน OAuth 2.0 ผู้ใช้จะเห็นหน้าจอให้ความยินยอมที่แสดง scopes เฉพาะ และหลังจากยืนยันจะได้รับ access token พร้อมสิทธิ์เหล่านั้น

Access Token ทำงานอย่างไร

กลไกของ access token ขึ้นอยู่กับ Bearer scheme: ไคลเอ็นต์เพิ่มส่วนหัว Authorization: Bearer <token> ไปยังทุกคำขอ HTTP เซิร์ฟเวอร์ทรัพยากร (API) รับโทเค็น ตรวจสอบความถูกต้อง และกำหนดว่าทรัพยากรใดบ้างที่เข้าถึงได้ การตรวจสอบสามารถเกิดขึ้นได้สองวิธี: ในเครื่อง (สำหรับ JWT) หรือผ่าน introspection endpoint (สำหรับ opaque token)

Bearer Token Scheme

Bearer token หมายความว่าใครก็ตามที่นำเสนอโทเค็น (bearer) จะได้รับการเข้าถึงที่เกี่ยวข้อง สิ่งนี้กำหนดข้อกำหนดสูงสำหรับการปกป้องโทเค็นระหว่างการส่งผ่านและการจัดเก็บ Bearer scheme ไม่ต้องการให้ไคลเอ็นต์พิสูจน์ความเป็นเจ้าของโทเค็นด้วยการเข้ารหัส — เพียงแค่ส่งก็เพียงพอ ดังนั้น HTTPS เป็นสิ่งจำเป็น: หากไม่มีการเข้ารหัสการรับส่งข้อมูล ผู้โจมตีสามารถสกัดกั้นโทเค็นและใช้งานได้ทันที

ตามข้อมูลจาก Cloudflare, 2025 การสกัดกั้น Bearer token ผ่านการเชื่อมต่อ HTTP ที่ไม่ปลอดภัยเกิดขึ้นโดยเฉลี่ยภายใน 12 วินาทีหลังจากส่งคำขอ การใช้ HTTPS และ TTL สั้นของ access token (15–30 นาที) ช่วยลดความเสี่ยงให้เหลือเกือบศูนย์ การป้องกันเพิ่มเติมระดับแอปพลิเคชัน — การตรวจสอบแหล่งที่มาของคำขอผ่าน OAuth 2.0 Token Binding (RFC 8471): ไคลเอ็นต์พิสูจน์ความเป็นเจ้าของคีย์ TLS ที่ผูกกับโทเค็น ทำให้การขโมยโทเค็นผ่านการสกัดกั้นไร้ประโยชน์

ประเภทของ Access Token

Access Token มีสองรูปแบบ: opaque และ JWT (ครบถ้วนในตัวเอง) การเลือกระหว่างทั้งสองเป็นหนึ่งในการตัดสินใจทางสถาปัตยกรรมที่สำคัญเมื่อออกแบบระบบยืนยันตัวตน

Opaque vs JWT

Opaque token เหมาะสำหรับระบบที่ต้องการการเพิกถอนการเข้าถึงทันทีและการตรวจสอบสิทธิ์แบบรวมศูนย์ JWT สำหรับสถาปัตยกรรมไมโครเซอร์วิสที่ประสิทธิภาพและการลดการเรียกเครือข่ายเป็นสิ่งสำคัญ ผู้ให้บริการหลายราย (Auth0, Keycloak) รองรับทั้งสองรูปแบบและอนุญาตให้กำหนดค่า type ของโทเค็นสำหรับแต่ละไคลเอ็นต์ การเลือกระหว่าง opaque และ JWT เป็นการแลกเปลี่ยนระหว่างการควบคุมและประสิทธิภาพ: opaque ให้การควบคุมเต็มที่แก่เซิร์ฟเวอร์ JWT ให้ความหน่วงต่ำที่สุด

วงจรชีวิตของ Access Token

วงจรชีวิตของ access token ประกอบด้วยสี่ระยะ: การออก, การส่งผ่าน, การใช้งาน และการหมดอายุ แต่ละระยะมีข้อกำหนดด้านความปลอดภัยและข้อจำกัดของโปรโตคอลของตัวเอง

การหมดอายุและการต่ออายุ

Access Token มีอายุจำกัด — โดยปกติ 15–60 นาที ค่า expires_in จะระบุในคำตอบของเซิร์ฟเวอร์อนุญาตสิทธิ์เมื่อออกโทเค็น หลังจากเวลานี้ โทเค็นจะไม่ถูกต้อง และไคลเอ็นต์ต้องรับใหม่ผ่านกลไก refresh token ไคลเอ็นต์สามารถตรวจสอบการหมดอายุได้สองวิธี: ผ่านฟิลด์ exp ใน JWT (ในเครื่อง) หรือผ่านการตอบกลับ HTTP 401 (สำหรับ opaque token)

ตามข้อมูลจาก Auth0 Best Practices, 2025 TTL ที่เหมาะสมที่สุดของ access token สำหรับแอปพลิเคชันมือถือคือ 15–30 นาที TTL ที่สั้นเกินไป (น้อยกว่า 5 นาที) สร้างภาระมากเกินไปบน token endpoint ทุกครั้งที่ต่ออายุ — ด้วยผู้ใช้ 10,000 คนและ TTL 5 นาที เซิร์ฟเวอร์ได้รับคำขอต่ออายุมากถึง 2,000 ครั้งต่อนาทีในช่วงชั่วโมงเร่งด่วน TTL ที่ยาวเกินไป (มากกว่า 2 ชั่วโมง) เพิ่มหน้าต่างการโจมตีเมื่อโทเค็นรั่วไหล — ผู้โจมตีสามารถใช้โทเค็นที่ถูกบุกรุกเป็นเวลาหลายชั่วโมงก่อนที่การเข้าถึงจะถูกบล็อกโดยอัตโนมัติ

ความปลอดภัยของ Access Token

ความปลอดภัยของ access token ต้องได้รับการรับประกันในทุกขั้นตอน: ระหว่างการจัดเก็บบนอุปกรณ์ ระหว่างการส่งผ่านเครือข่าย และระหว่างการประมวลผลบนเซิร์ฟเวอร์ คำแนะนำพื้นฐานคือไม่ควรเก็บ access token ในสถานที่ที่แอปพลิเคชันหรือกระบวนการอื่นสามารถเข้าถึงได้

การป้องกันระหว่างการจัดเก็บและการส่งผ่าน

บนอุปกรณ์มือถือ access token จะถูกจัดเก็บ: บน iOS — ใน Keychain ด้วยแอตทริบิวต์ kSecAttrAccessibleAfterFirstUnlock (โทเค็นสามารถเข้าถึงได้หลังจากปลดล็อคครั้งแรก แม้ว่าอุปกรณ์จะถูกล็อค — สำหรับการอัปเดตพื้นหลัง); บน Android — ใน EncryptedSharedPreferences ไม่ควรเก็บ access token ใน NSUserDefaults, SharedPreferences, ไฟล์บนที่จัดเก็บภายนอก หรือบันทึกของแอปพลิเคชัน ระหว่างการส่งผ่าน — เฉพาะ HTTPS กับ TLS 1.3 หรือ 1.2 สำหรับทุกคำขอ API access token ควรส่งในส่วนหัว Authorization: Bearer ไม่ใช่ในพารามิเตอร์ URL (query string) — URL จะถูกบันทึกในบันทึกของเซิร์ฟเวอร์และเบราว์เซอร์

ตามข้อมูลจาก OWASP Mobile Top 10, 2025 การจัดเก็บโทเค็นที่ไม่เหมาะสมบนอุปกรณ์ (M1: Improper Platform Usage) และการส่งผ่านข้อมูลที่ไม่ปลอดภัย (M3: Insecure Communication) อยู่ในสามช่องโหว่มือถือที่พบบ่อยที่สุดที่นำไปสู่การบุกรุกบัญชี มาตรการเพิ่มเติม — การใช้ certificate pinning สำหรับทุกคำขอที่มี access token: ไคลเอ็นต์ตรวจสอบใบรับรองเซิร์ฟเวอร์ไม่เพียงผ่านห่วงโซ่ CA มาตรฐาน แต่ยังผ่านลายนิ้วมือใบรับรองที่บันทึกไว้ล่วงหน้า (SHA-256 fingerprint) สิ่งนี้ป้องกันการโจมตีแบบ man-in-the-middle แม้กับ CA ที่ถูกบุกรุก

ตัวอย่างโค้ดใน Kotlin

ด้านล่างนี้เป็นตัวอย่างใน Kotlin สำหรับ Android แสดงการส่งคำขอด้วย access token ในส่วนหัว Authorization และการจัดการ 401 ด้วยการต่ออายุอัตโนมัติผ่าน refresh token ใช้ OkHttp กับ Interceptor ที่กำหนดเอง

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

ตัวอย่างแสดงสองแนวทาง: การใช้ OkHttp Interceptor สำหรับการจัดการโทเค็นอัตโนมัติและการส่งโดยตรงผ่าน HttpURLConnection OkHttp Interceptor เป็นที่นิยม — มันรวมศูนย์ตรรกะการเพิ่มและต่ออายุโทเค็น กำจัดการซ้ำซ้อนของโค้ดในทุกคำขอ คำขอทั้งหมดผ่าน interceptor เดียวที่ตรวจสอบสถานะการตอบสนองและต่ออายุโทเค็นเมื่อจำเป็นโดยไม่ต้องให้นักพัฒนามีส่วนร่วม