OAuth 2.0: τι είναι, πώς λειτουργεί το πρωτόκολλο εξουσιοδότησης

Τι είναι το OAuth 2.0;

OAuth 2.0 — είναι ένα πρωτόκολλο εξουσιοδότησης, που ορίζεται στο IETF RFC 6749, το οποίο επιτρέπει σε εφαρμογές τρίτων να αποκτούν περιορισμένη πρόσβαση σε πόρους χρήστη χωρίς αποκάλυψη του ονόματος χρήστη και κωδικού πρόσβασης. Το πρωτόκολλο λύνει το θεμελιώδες πρόβλημα του μοντέλου κωδικού πρόσβασης: η εφαρμογή στην οποία εμπιστευτήκατε τον κωδικό σας αποκτά απεριόριστη πρόσβαση σε όλα τα δεδομένα του λογαριασμού. Το OAuth 2.0 αντικαθιστά αυτή την προσέγγιση με την έκδοση ενός προσωρινού διακριτικού με ρητά περιορισμένο πεδίο πρόσβασης (scope).

Η αρχιτεκτονική του OAuth 2.0 είναι η εκχωρημένη εξουσιοδότηση. Ο χρήστης (Resource Owner) εξουσιοδοτεί την εφαρμογή (Client) για πρόσβαση στα δεδομένα του που βρίσκονται στον διακομιστή πόρων (Resource Server), μέσω ενός ενδιάμεσου — του διακομιστή εξουσιοδότησης (Authorization Server). Ο διακομιστής εξουσιοδότησης εκδίδει ένα Access Token — μια κρυπτογραφική συμβολοσειρά που η εφαρμογή παρουσιάζει στον διακομιστή πόρων για πρόσβαση στα δεδομένα. Μια σημαντική διαφορά του OAuth 2.0 από τα SAML και OpenID Connect: το OAuth 2.0 επιλύει το ζήτημα της εξουσιοδότησης (τι επιτρέπεται) και όχι της ταυτοποίησης (ποιος είναι ο χρήστης). Για ταυτοποίηση, πάνω από το OAuth 2.0 χτίζεται το πρωτόκολλο OpenID Connect (OIDC).

Το πρωτόκολλο υποστηρίζεται από όλες τις μεγάλες πλατφόρμες. Η Google χρησιμοποιεί OAuth 2.0 για πρόσβαση στα Google APIs (Gmail, Drive, Calendar), το Facebook — για το Graph API, η Apple — για το Sign in with Apple (ASAuthorizationAppleIDProvider), το GitHub — για πρόσβαση σε αποθετήρια. Στο πλαίσιο της ανάπτυξης κινητών εφαρμογών, το OAuth 2.0 είναι ο τυπικός μηχανισμός ενσωμάτωσης υπηρεσιών τρίτων: σύνδεση μέσω κοινωνικών δικτύων, πρόσβαση σε αποθηκευτικά νέφους, δημοσίευση περιεχομένου εκ μέρους του χρήστη.

Ρόλοι και στοιχεία του OAuth 2.0

Το πρωτόκολλο OAuth 2.0 ορίζει τέσσερις ρόλους, η αλληλεπίδραση των οποίων αποτελεί τον πλήρη κύκλο εξουσιοδότησης. Η κατανόηση κάθε ρόλου είναι απαραίτητη για τη σωστή υλοποίηση του πρωτοκόλλου σε μια κινητή εφαρμογή.

Τέσσερις ρόλοι του πρωτοκόλλου

Οι βασικές οντότητες του πρωτοκόλλου είναι το Access Token, το Refresh Token και το Authorization Code. Το Access Token είναι ένα βραχύβιο διακριτικό (συνήθως 15–60 λεπτά) που παρουσιάζεται στον διακομιστή πόρων σε κάθε αίτημα δεδομένων. Το Refresh Token είναι ένα μακρόβιο διακριτικό (ημέρες ή εβδομάδες) που χρησιμοποιείται για λήψη νέου Access Token χωρίς εκ νέου σύνδεση του χρήστη. Το Authorization Code είναι ένας προσωρινός κωδικός που εκδίδεται μετά την εξουσιοδότηση του χρήστη και ανταλλάσσεται με Access Token και Refresh Token.

Grant Types: σενάρια εξουσιοδότησης

Το OAuth 2.0 ορίζει διάφορους Grant Types — σενάρια λήψης διακριτικού, καθένα από τα οποία προορίζεται για συγκεκριμένο τύπο πελάτη και περιβάλλον ασφαλείας. Η επιλογή του σωστού Grant Type είναι μια κρίσιμη αρχιτεκτονική απόφαση κατά τον σχεδιασμό της εξουσιοδότησης σε μια κινητή εφαρμογή.

Οι κύριοι Grant Types: Authorization Code (ο ασφαλέστερος για κινητές και διαδικτυακές εφαρμογές με διακομιστή), Authorization Code με PKCE (Proof Key for Code Exchange — για κινητές και SPA εφαρμογές χωρίς διακομιστή), Client Credentials (για αυθεντικοποίηση server-to-server χωρίς συμμετοχή χρήστη), Resource Owner Password Credentials (παλαιωμένο — απευθείας μεταβίβαση κωδικού πρόσβασης). Το PKCE είναι υποχρεωτική επέκταση για δημόσιους πελάτες (κινητές εφαρμογές, SPA) σύμφωνα με τις συστάσεις OAuth Security BCP (RFC 9700).

Κύριοι Grant Types

• Authorization Code + PKCE — ο συνιστώμενος Grant Type για εγγενείς κινητές εφαρμογές. Ο πελάτης δημιουργεί έναν κρυπτογραφικό code_verifier, υπολογίζει το code_challenge (SHA-256 hash), και ο διακομιστής ελέγχει την αντιστοιχία κατά την ανταλλαγή κωδικού για διακριτικό. Αυτό αποτρέπει την υποκλοπή του authorization code μεταξύ εφαρμογής και διακομιστή
• Client Credentials — χρησιμοποιείται για εξουσιοδότηση machine-to-machine, όπου ο πελάτης είναι γνωστός και ταυτοποιημένος. Η εφαρμογή λαμβάνει διακριτικό χρησιμοποιώντας το client_id και το client_secret της. Δεν απαιτεί συμμετοχή χρήστη. Τυπικό σενάριο: μια εφαρμογή διακομιστή καλεί ένα API για μαζική επεξεργασία δεδομένων
• Device Authorization Grant — για συσκευές χωρίς πρόγραμμα περιήγησης (Smart TV, IoT). Ο χρήστης μεταβαίνει σε έναν σύνδεσμο σε άλλη συσκευή και εισάγει έναν κωδικό. Χρησιμοποιείται, για παράδειγμα, κατά την εξουσιοδότηση Netflix σε τηλεόραση μέσω smartphone
• Resource Owner Password Credentials — παλαιωμένος Grant Type, απαγορευμένος από το OAuth Security BCP. Ο κωδικός πρόσβασης μεταβιβάζεται απευθείας στον πελάτη, παραβιάζοντας την αρχή της αυθεντικοποίησης μηδενικής γνώσης. Χρησιμοποιείται μόνο για μετεγκατάσταση από παλαιωμένα συστήματα

Authorization Code Flow με PKCE για κινητές εφαρμογές

Authorization Code Flow με PKCE — είναι η συνιστώμενη διαμόρφωση OAuth 2.0 για εγγενείς κινητές εφαρμογές. Το PKCE (Proof Key for Code Exchange) προσθέτει ένα επιπλέον επίπεδο προστασίας, αποτρέποντας την επίθεση υποκλοπής authorization code (authorization code interception attack). Το πρωτόκολλο περιγράφεται στο IETF RFC 7636.

Βήμα προς βήμα ακολουθία PKCE

Ακολουθία βημάτων: (1) ο πελάτης δημιουργεί έναν τυχαίο code_verifier (συμβολοσειρά 43–128 χαρακτήρων, only unreserved characters), (2) ο πελάτης υπολογίζει code_challenge = SHA-256(code_verifier), (3) ο πελάτης ανοίγει το πρόγραμμα περιήγησης για εξουσιοδότηση χρήστη στον Authorization Server, μεταβιβάζοντας το code_challenge, (4) μετά από επιτυχή εξουσιοδότηση, ο διακομιστής επιστρέφει authorization code στην εφαρμογή μέσω μιας προσαρμοσμένης URI scheme (app deep link), (5) ο πελάτης στέλνει στον διακομιστή το authorization code + code_verifier, (6) ο διακομιστής ελέγχει SHA-256(code_verifier) === code_challenge και εκδίδει Access Token + Refresh Token.

Το πλεονέκτημα του PKCE — ακόμα κι αν ένας εισβολέας υποκλέψει το authorization code στην URI-σχήμα, δεν μπορεί να το ανταλλάξει για διακριτικό χωρίς το code_verifier, το οποίο είναι γνωστό μόνο στον νόμιμο πελάτη. Σε κινητές εφαρμογές για το άνοιγμα του προγράμματος περιήγησης θα πρέπει να χρησιμοποιούνται Chrome Custom Tabs (Android) ή ASWebAuthenticationSession (iOS) — αυτό εγγυάται ότι το πρόγραμμα περιήγησης συστήματος δεν έχει πρόσβαση στο code_verifier από τη μνήμη της εφαρμογής.

Υλοποίηση OAuth 2.0 σε Android μέσω AppAuth

AppAuth — είναι μια πρότυπη υλοποίηση OAuth 2.0 και OpenID Connect για εγγενείς εφαρμογές, συνιστώμενη από την IETF. Η βιβλιοθήκη υποστηρίζει PKCE, Chrome Custom Tabs, προσαρμοσμένα URI-σχήματα για επιστροφή authorization code και αυτόματη ανανέωση διακριτικών. Το AppAuth για Android είναι διαθέσιμο μέσω της dependency `net.openid:appauth:0.11.1`.

val serviceConfig = AuthorizationServiceConfiguration.fromUrl(
    Uri.parse("https://accounts.google.com/.well-known/openid-configuration")
)

val request = AuthorizationRequest.Builder(
    serviceConfig,
    "CLIENT_ID.apps.googleusercontent.com",
    ResponseTypeValues.CODE,
    Uri.parse("com.example.app:/oauth2callback")
)
.setScope("openid profile email")
.setCodeVerifier(
    CodeVerifierUtil.generateRandomCodeVerifier()
)
.build()

val authService = AuthorizationService(context)
val intent = authService.getAuthorizationRequestIntent(request)

// Εκκίνηση Chrome Custom Tab για εξουσιοδότηση
startActivityForResult(intent, REQUEST_CODE_AUTH)

Μετά τη λήψη του authorization code (onActivityResult), η εφαρμογή το ανταλλάσσει για Access Token και Refresh Token μέσω TokenRequest. Τα διακριτικά αποθηκεύονται σε SharedPreferences με κρυπτογράφηση μέσω EncryptedSharedPreferences (Android Security Crypto). Το Refresh Token πρέπει να αποθηκεύεται στο KeyStore — το υλικό αποθετήριο κλειδιών, μη προσβάσιμο για ανάγνωση από άλλες εφαρμογές. Κάθε φορά που το Access Token λήγει, η εφαρμογή χρησιμοποιεί το Refresh Token για να λάβει ένα νέο — ο χρήστης δεν χρειάζεται να συνδεθεί ξανά.

// Ανταλλαγή authorization code για tokens
val data = intent?.data ?: return
val resp = AuthorizationResponse.fromIntent(data)
val exchangeReq = resp?.createTokenExchangeRequest()
    ?: return

authService.performTokenRequest(
    exchangeReq,
    ClientAuthentication.none()
) { tokenResp, ex ->
    if (tokenResp != null) {
        // Access Token και Refresh Token ελήφθησαν
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // Αποθήκευση σε EncryptedSharedPreferences
        saveTokens(accessToken, refreshToken)
    }
}

Ο παραπάνω κώδικας δείχνει τον πλήρη κύκλο OAuth 2.0 με PKCE: δημιουργία διαμόρφωσης διακομιστή μέσω OpenID Connect Discovery, δημιουργία αιτήματος εξουσιοδότησης με code_verifier, εκκίνηση Chrome Custom Tab, λήψη authorization code μέσω προσαρμοσμένου URI-σχήματος και ανταλλαγή κωδικού για διακριτικά μέσω Token Request. Είναι σημαντικό να διαχειρίζεστε τη λήξη του Access Token: όταν λαμβάνετε HTTP απάντηση 401 από τον Resource Server, η εφαρμογή πρέπει να χρησιμοποιεί το Refresh Token για να λάβει νέο Access Token και να εκτελέσει ξανά το αίτημα.

Ασφάλεια OAuth 2.0: τυπικές επιθέσεις και προστασία

OAuth 2.0 — ένα σύνθετο πρωτόκολλο με πολλαπλά σημεία επίθεσης. Το IETF Security BCP (RFC 9700) περιγράφει περισσότερες από 20 κατηγορίες τρωτών σημείων του OAuth 2.0. Για κινητές εφαρμογές, τα πιο κρίσιμα είναι: υποκλοπή authorization code μέσω προσαρμοσμένων URI-σχημάτων, επιθέσεις CSRF στα callback endpoints, κλοπή Refresh Token από μη ασφαλή αποθηκευτικά μέσα και υποκατάσταση πελάτη μέσω υποκλοπής intent.

Η προστασία από αυτές τις επιθέσεις περιλαμβάνει υποχρεωτικά μέτρα: (1) PKCE με S256 code_challenge — αποτρέπει την υποκλοπή authorization code ακόμα και σε περίπτωση υποκλοπής URI-σχήματος· (2) χρήση nonce ή state parameter για αποτροπή CSRF — ο διακομιστής ελέγχει ότι το authorization code αντιστοιχεί στο αρχικό αίτημα· (3) αποθήκευση Refresh Token μόνο σε KeyStore (Android) ή Keychain (iOS) — ούτε σε SharedPreferences, ούτε σε UserDefaults· (4) χρήση TLS με Certificate Pinning για προστασία MITM σε επίπεδο μεταφοράς· (5) έλεγχος redirect_uri — ο διακομιστής εξουσιοδότησης πρέπει να επικυρώνει αυστηρά την αντιστοιχία με το καταχωρημένο URI.

Επιπρόσθετες συστάσεις από την IETF: οι κινητές εφαρμογές θα πρέπει να χρησιμοποιούν AppAuth ή παρόμοιες βιβλιοθήκες που έχουν υποβληθεί σε έλεγχο ασφαλείας· να μη βασίζονται στο WebView για OAuth (το WebView δεν απομονώνει δεδομένα από την κύρια εφαρμογή)· να υλοποιούν αυτόματη εναλλαγή Refresh Token (ένα Refresh Token μπορεί να χρησιμοποιηθεί μόνο μία φορά)· να προσθέτουν Certificate Pinning μέσω TrustManager για Android και URLSession για iOS. Το OpenID Connect Discovery (well-known endpoint) βοηθά στον αυτόματο προσδιορισμό των σωστών endpoints του διακομιστή εξουσιοδότησης και στην αποφυγή ανακατευθύνσεων σε σελίδες phishing.