Access Token στην ανάπτυξη iOS και Android — βασικές έννοιες, τύποι token και πώς λειτουργεί

Τι είναι το Access Token;

Access Token — είναι μια συμβολοσειρά που χρησιμοποιεί ο πελάτης (εφαρμογή κινητού, SPA, διακομιστής) για την ταυτοποίηση αιτημάτων HTTP σε προστατευμένα τελικά σημεία API. Το token εκδίδεται από τον διακομιστή εξουσιοδότησης αφού ο χρήστης επιβεβαιώσει την ταυτότητά του και παραχωρήσει τις κατάλληλες άδειες (scope) στην εφαρμογή.

Το access token είναι το κεντρικό στοιχείο του πρωτοκόλλου OAuth 2.0 και όλων των συστημάτων που βασίζονται σε αυτό — OpenID Connect, Firebase Authentication, Auth0, Keycloak. Χωρίς access token, κανένα αίτημα σε προστατευμένο API δεν θα υποβληθεί σε επεξεργασία: ο διακομιστής επιστρέφει HTTP 401 Unauthorized. Το token δεν ταυτοποιεί άμεσα τον χρήστη — επιβεβαιώνει ότι ο πελάτης έχει το δικαίωμα να εκτελέσει μια συγκεκριμένη ενέργεια εκ μέρους του χρήστη (εξουσιοδότηση), όχι ποιος είναι ο χρήστης (ταυτοποίηση).

Σύμφωνα με δεδομένα της Okta, 2025, πάνω από το 80% των δημόσιων API χρησιμοποιούν το σχήμα Bearer με access token στην κεφαλίδα Authorization, εκτοπίζοντας τις παλαιωμένες μεθόδους ταυτοποίησης — Basic Auth και API Key. Το access token είναι επίσης η βάση για την delegated authorization — το μοντέλο στο οποίο ο χρήστης παρέχει στην εφαρμογή περιορισμένη πρόσβαση στα δεδομένα του σε μια άλλη υπηρεσία. Για παράδειγμα, όταν μια εφαρμογή κινητού για επεξεργασία φωτογραφιών ζητά πρόσβαση στο Google Drive μέσω OAuth 2.0, ο χρήστης βλέπει μια οθόνη συγκατάθεσης με συγκεκριμένα scope και μετά την επιβεβαίωση λαμβάνει ένα access token με αυτά τα δικαιώματα.

Πώς λειτουργεί το Access Token

Ο μηχανισμός λειτουργίας του access token βασίζεται στο σχήμα Bearer: ο πελάτης προσθέτει την κεφαλίδα Authorization: Bearer <token> σε κάθε αίτημα HTTP. Ο διακομιστής πόρων (API) λαμβάνει το token, ελέγχει την εγκυρότητά του και καθορίζει ποιοι πόροι είναι διαθέσιμοι. Ο έλεγχος μπορεί να γίνει με δύο τρόπους: τοπικά (για JWT) ή μέσω introspection endpoint (για opaque token).

Σχήμα Bearer Token

Bearer token σημαίνει ότι οποιοσδήποτε παρουσιάσει το token (bearer — κάτοχος) αποκτά την αντίστοιχη πρόσβαση. Αυτό θέτει υψηλές απαιτήσεις για την προστασία του token κατά τη μετάδοση και αποθήκευση. Το σχήμα Bearer δεν απαιτεί από τον πελάτη να αποδείξει κρυπτογραφικά την κατοχή του token — αρκεί απλώς να το μεταδώσει. Γι' αυτό το HTTPS είναι υποχρεωτικό: χωρίς κρυπτογράφηση της κίνησης, ένας εισβολέας μπορεί να υποκλέψει το token και να το χρησιμοποιήσει αμέσως.

Σύμφωνα με δεδομένα της Cloudflare, 2025, η υποκλοπή Bearer token μέσω μη ασφαλούς σύνδεσης HTTP συμβαίνει κατά μέσο όρο εντός 12 δευτερολέπτων μετά την αποστολή του αιτήματος. Η χρήση HTTPS και σύντομου TTL access token (15–30 λεπτά) μειώνει τον κίνδυνο σχεδόν στο μηδέν. Πρόσθετη προστασία σε επίπεδο εφαρμογής — έλεγχος προέλευσης αιτήματος μέσω OAuth 2.0 Token Binding (RFC 8471): ο πελάτης αποδεικνύει την κατοχή κλειδιού TLS που συνδέεται με το token, καθιστώντας άχρηστη την κλοπή token μέσω υποκλοπής.

Τύποι Access Token

Access token υπάρχει σε δύο μορφές: opaque (αδιαφανές) και JWT (αυτοδύναμο). Η επιλογή μεταξύ τους είναι μία από τις βασικές αρχιτεκτονικές αποφάσεις κατά τον σχεδιασμό συστήματος ταυτοποίησης.

Opaque vs JWT

Opaque token προτιμάται για συστήματα όπου απαιτείται άμεση ανάκληση πρόσβασης και συγκεντρωτικός έλεγχος δικαιωμάτων. JWT — για αρχιτεκτονική μικρουπηρεσιών, όπου η απόδοση και η ελαχιστοποίηση κλήσεων δικτύου είναι σημαντικές. Πολλοί πάροχοι (Auth0, Keycloak) υποστηρίζουν και τις δύο μορφές και επιτρέπουν τη ρύθμιση του τύπου token για κάθε πελάτη. Η επιλογή μεταξύ opaque και JWT είναι ένας συμβιβασμός μεταξύ ελέγχου και απόδοσης: το opaque δίνει πλήρη έλεγχο στον διακομιστή, το JWT — ελάχιστη καθυστέρηση.

Κύκλος ζωής Access Token

Ο κύκλος ζωής του access token αποτελείται από τέσσερις φάσεις: έκδοση (issuance), μετάδοση, χρήση και λήξη. Κάθε φάση έχει τις δικές της απαιτήσεις ασφαλείας και περιορισμούς πρωτοκόλλου.

Λήξη και ανανέωση

Access token έχει περιορισμένη διάρκεια ζωής — συνήθως 15–60 λεπτά. Η τιμή expires_in αναφέρεται στην απόκριση του διακομιστή εξουσιοδότησης κατά την έκδοση του token. Μετά τη λήξη αυτού του χρόνου, το token καθίσταται άκυρο και ο πελάτης πρέπει να αποκτήσει ένα νέο μέσω του μηχανισμού 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 ώρες) αυξάνει το παράθυρο επίθεσης σε περίπτωση διαρροής token — ένας εισβολέας μπορεί να χρησιμοποιεί το παραβιασμένο token για ώρες προτού η πρόσβαση αποκλειστεί αυτόματα.

Ασφάλεια Access Token

Η ασφάλεια του access token πρέπει να διασφαλίζεται σε όλα τα στάδια: κατά την αποθήκευση στη συσκευή, κατά τη μετάδοση μέσω δικτύου και κατά την επεξεργασία στον διακομιστή. Βασική σύσταση — ποτέ μην αποθηκεύετε access token σε μέρη προσβάσιμα από άλλες εφαρμογές ή διεργασίες.

Προστασία κατά την αποθήκευση και μετάδοση

Σε κινητές συσκευές το access token αποθηκεύεται: σε iOS — στο Keychain με το χαρακτηριστικό kSecAttrAccessibleAfterFirstUnlock (το token είναι διαθέσιμο μετά το πρώτο ξεκλείδωμα, ακόμα κι αν η συσκευή είναι κλειδωμένη — για ενημερώσεις παρασκηνίου); σε 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, η λανθασμένη αποθήκευση token στη συσκευή (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? {
        // Ανάγνωση από 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 για αυτόματη διαχείριση token και άμεση αποστολή μέσω HttpURLConnection. Το OkHttp Interceptor είναι προτιμότερο — συγκεντρώνει τη λογική προσθήκης και ανανέωσης του token, εξαλείφοντας την επανάληψη κώδικα σε κάθε αίτημα. Όλα τα αιτήματα περνούν από έναν ενιαίο interceptor που ελέγχει την κατάσταση απόκρισης και, αν χρειαστεί, ανανεώνει το token χωρίς τη συμμετοχή του προγραμματιστή.