Session Token στην ανάπτυξη εφαρμογών — τι είναι, αρχή λειτουργίας και διαφορές από το JWT

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

Session Token (αναγνωριστικό συνεδρίας) — είναι μια μοναδική συμβολοσειρά που δημιουργεί ο διακομιστής και συνδέει με τα δεδομένα συνεδρίας μετά την ταυτοποίηση του χρήστη. Το token δεν περιέχει καμία πληροφορία για τον χρήστη — είναι απλώς ένα κλειδί για τα δεδομένα που αποθηκεύονται στον διακομιστή. Αυτή η προσέγγιση ονομάζεται stateful ταυτοποίηση: ο διακομιστής αποθηκεύει την κατάσταση κάθε ενεργής συνεδρίας και την ελέγχει σε κάθε αίτημα.

Τα δεδομένα συνεδρίας περιλαμβάνουν: αναγνωριστικό χρήστη, ώρα εισόδου, διεύθυνση IP, user-agent, λίστα δικαιωμάτων (permissions), ώρα τελευταίας δραστηριότητας. Όταν ο πελάτης στέλνει ένα αίτημα με session token, ο διακομιστής βρίσκει την αντίστοιχη εγγραφή στην αποθήκη συνεδριών, ελέγχει την εγκυρότητά της και εξάγει τα δεδομένα για την επεξεργασία του αιτήματος. Εάν η εγγραφή συνεδρίας λείπει ή έχει λήξει, ο διακομιστής επιστρέφει σφάλμα ταυτοποίησης και απαιτεί εκ νέου σύνδεση.

Σύμφωνα με δεδομένα του OWASP, 2025, το session token παραμένει το πρότυπο για εφαρμογές που απαιτούν άμεση ανάκληση πρόσβασης — για παράδειγμα, σε τραπεζικά συστήματα και εταιρικές πύλες, όπου ο διαχειριστής πρέπει να είναι σε θέση να τερματίσει άμεσα τη συνεδρία ενός χρήστη. Σε τέτοια συστήματα, το session token παρέχει πλήρη έλεγχο πρόσβασης, ανέφικτο για stateless tokens χωρίς πρόσθετους μηχανισμούς αποκλεισμού.

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

Η διαδικασία λειτουργίας ξεκινά όταν ο πελάτης στέλνει διαπιστευτήρια στον διακομιστή ταυτοποίησης. Ο διακομιστής ελέγχει το όνομα χρήστη και τον κωδικό πρόσβασης, δημιουργεί μια εγγραφή συνεδρίας στην αποθήκη (συνήθως Redis ή βάση δεδομένων) και επιστρέφει στον πελάτη ένα μοναδικό session token. Ο πελάτης αποθηκεύει το token και το μεταδίδει με κάθε επόμενο αίτημα, και ο διακομιστής ελέγχει κάθε φορά την ύπαρξη και εγκυρότητα της συνεδρίας.

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

Redis — η πιο δημοφιλής αποθήκη συνεδριών χάρη στην αποθήκευση στη μνήμη και την υποστήριξη TTL (time-to-live). Κάθε συνεδρία αποθηκεύεται ως ζεύγος κλειδιού-τιμής, όπου το κλειδί είναι το session token και η τιμή είναι ένα αντικείμενο JSON με δεδομένα συνεδρίας. Το TTL διαγράφει αυτόματα τις ληγμένες συνεδρίες. Εναλλακτικές: Memcached (μόνο μνήμη, χωρίς αποθήκευση σε δίσκο), PostgreSQL/MySQL (μονιμότητα, αλλά πιο αργό) και DynamoDB (για υποδομή AWS).

Παράδειγμα δομής συνεδρίας σε Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Ο διακομιστής ενημερώνει το lastAccess σε κάθε αίτημα, επιτρέποντας την εφαρμογή χρονικού ορίου αδράνειας — αυτόματο τερματισμό της συνεδρίας μετά από περίοδο αδράνειας.

Cookie vs Header

Session Token μπορεί να μεταδοθεί με δύο τρόπους: μέσω HTTP cookie ή μέσω κεφαλίδας HTTP Authorization. Cookie — παραδοσιακός τρόπος για διαδικτυακές εφαρμογές: ο διακομιστής ορίζει ένα cookie με σημαίες HttpOnly (μη προσβάσιμο από JavaScript), Secure (μόνο HTTPS) και SameSite (προστασία από CSRF). Για κινητές εφαρμογές χρησιμοποιείται συχνότερα η κεφαλίδα Authorization: Bearer <session_token>, καθώς ο μηχανισμός cookie δεν είναι πάντα βολικός σε native πελάτες.

Κύκλος ζωής του Session Token

Ο κύκλος ζωής του session token περιλαμβάνει τρία στάδια: δημιουργία, διατήρηση ενεργής συνεδρίας και τερματισμό. Κάθε στάδιο απαιτεί σωστή διαμόρφωση ασφαλείας για την αποτροπή διαρροής ή υποκλοπής του token.

Δημιουργία, αποθήκευση και διαγραφή

Δημιουργία — ο διακομιστής δημιουργεί μια κρυπτογραφικά ασφαλή τυχαία συμβολοσειρά μήκους 128–256 bit (π.χ. μέσω SecureRandom σε Java ή os.urandom σε Python). Το token πρέπει να είναι απρόβλεπτο — η χρήση UUID ή χρονικής σήμανσης χωρίς εντροπία δεν επιτρέπεται. Αποθήκευση στον πελάτη: σε iOS — Keychain, σε Android — EncryptedSharedPreferences, στον ιστό — HttpOnly cookie. Διαγραφή πραγματοποιείται κατά την αποσύνδεση: ο πελάτης διαγράφει το token από την αποθήκη, ο διακομιστής διαγράφει την εγγραφή συνεδρίας από το Redis. Μετά την αποσύνδεση, το session token καθίσταται άχρηστο — ο διακομιστής δεν θα βρει την αντίστοιχη εγγραφή.

Σύμφωνα με δεδομένα του SANS Institute, 2025, η σωστή υλοποίηση τερματισμού συνεδρίας (αποσύνδεση με εκκαθάριση στον διακομιστή) αποτρέπει έως και το 70% των επιθέσεων με κλεμμένα tokens. Είναι ζωτικής σημασίας όχι μόνο να διαγράφετε το token στον πελάτη, αλλά και να ακυρώνετε τη συνεδρία στον διακομιστή.

Session Token vs JWT

Session Token και JWT αντιπροσωπεύουν δύο διαφορετικές προσεγγίσεις στην ταυτοποίηση. Session Token — stateful (ο διακομιστής αποθηκεύει την κατάσταση), JWT — stateless (δεδομένα εντός του token). Η επιλογή μεταξύ τους εξαρτάται από την αρχιτεκτονική της εφαρμογής και τις απαιτήσεις ασφαλείας.

Πότε να επιλέξετε Session Token

Session Token είναι προτιμότερο όταν: απαιτείται άμεση ανάκληση συνεδριών (τραπεζικές εργασίες, πίνακες διαχείρισης), η εφαρμογή λειτουργεί σε έναν ή περισσότερους διακομιστές με κοινόχρηστο Redis, τα δεδομένα συνεδρίας είναι μεγάλα και δεν χωρούν στο JWT, ή όταν η ομάδα θέλει να ελαχιστοποιήσει τον κίνδυνο διαρροής δεδομένων μέσω αποκωδικοποίησης του token. Σε τέτοια σενάρια, το session token παρέχει άμεσο αποκλεισμό πρόσβασης σε ύποπτη δραστηριότητα — αρκεί να διαγράψετε μία εγγραφή από το Redis και όλες οι συνεδρίες του χρήστη καθίστανται άκυρες.

Σύμφωνα με δεδομένα του Redis, 2025, η χρήση TTL σε επίπεδο κλειδιών συνεδρίας (εντολή EXPIRE) καθαρίζει αυτόματα τις ληγμένες συνεδρίες χωρίς πρόσθετο κόστος για εργασίες παρασκηνίου. Για συνεδρίες με TTL 1 ώρας και φορτίο 10.000 ταυτόχρονων χρηστών με μέγεθος συνεδρίας 1 KB, το Redis καταναλώνει περίπου 1 GB RAM, καθιστώντας το οικονομικά αποδοτικό για τις περισσότερες εφαρμογές.

Ασφάλεια του Session Token

Η ασφάλεια του session token βασίζεται σε δύο αρχές: το token πρέπει να είναι απρόβλεπτο και προστατευμένο κατά τη μετάδοση και αποθήκευση. Οι κύριες απειλές — υποκλοπή του token (man-in-the-middle, XSS), πρόβλεψή του (αδύναμη δημιουργία) και καθήλωση συνεδρίας (session fixation).

Προστασία από κλοπή token

Η προστασία περιλαμβάνει: χρήση HTTPS για όλα τα αιτήματα με token, ορισμό σύντομου TTL συνεδρίας (15–60 λεπτά αδράνειας), σύνδεση της συνεδρίας με IP και user-agent (πρόσθετος έλεγχος σε κάθε αίτημα), χρήση σημαιών Secure και HttpOnly για cookie, τακτική εναλλαγή του session token μετά από ευαίσθητες λειτουργίες (αλλαγή κωδικού πρόσβασης, αναβάθμιση δικαιωμάτων). Το OWASP συνιστά επίσης την εφαρμογή Διαχείρισης συνεδριών με ακύρωση της παλιάς συνεδρίας κατά τη δημιουργία νέας μετά τη σύνδεση — αυτό αποτρέπει την καθήλωση συνεδρίας.

Σύμφωνα με δεδομένα του OWASP ASVS, 2025, η συνεδρία πρέπει να συνδέεται με τουλάχιστον δύο παράγοντες: το ίδιο το token (τι έχει ο πελάτης) και IP/user-agent (τι γνωρίζει ο διακομιστής). Σε περίπτωση ασυμφωνίας αυτών των παραγόντων, ο διακομιστής πρέπει να τερματίσει τη συνεδρία και να ζητήσει εκ νέου ταυτοποίηση.

Παράδειγμα υλοποίησης σε Kotlin

Παρακάτω δίνεται ένα παράδειγμα υλοποίησης session token σε Kotlin με χρήση Spring Boot και Redis. Ο διακομιστής δημιουργεί ένα κρυπτογραφικά ασφαλές token μέσω SecureRandom, αποθηκεύει τη συνεδρία στο Redis με TTL και την ελέγχει σε κάθε αίτημα. Ο κώδικας παρουσιάζει τρεις βασικές λειτουργίες: δημιουργία συνεδρίας, επικύρωση και ακύρωση.

data class Session(
    val userId: Long,
    val role: String,
    val createdAt: Long,
    val lastAccess: Long
)

object SessionManager {
    private val redis = JedisPool("localhost", 6379)

    fun createSession(userId: Long, role: String): String {
        val token = generateSecureToken()
        val session = Session(userId, role, now(), now())
        redis.resource.use { conn ->
            conn.setex("session:$token", 3600, toJson(session))
        }
        return token
    }

    fun validateSession(token: String): Session? {
        redis.resource.use { conn ->
            val json = conn.get("session:$token") ?: return null
            return fromJson(json)
        }
    }

    fun invalidateSession(token: String) {
        redis.resource.use { it.del("session:$token") }
    }

    private fun generateSecureToken(): String {
        val bytes = ByteArray(32)
        SecureRandom().nextBytes(bytes)
        return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)
    }
}

Αυτή η υλοποίηση χρησιμοποιεί JedisPool για ασφαλή σύνδεση με το Redis σε περιβάλλον πολλαπλών νημάτων. Η μέθοδος createSession ορίζει TTL 1 ώρας (3600 δευτερόλεπτα) — μετά από αυτό το διάστημα, το Redis θα διαγράψει αυτόματα την εγγραφή. Η μέθοδος validateSession επιστρέφει null για ανύπαρκτες ή ληγμένες συνεδρίες, επιτρέποντας στον διακομιστή να επεξεργαστεί σωστά ένα αίτημα με άκυρο token και να επιστρέψει HTTP 401.