OpenID Connect: τι είναι, πρωτόκολλο αυθεντικοποίησης και εξουσιοδότησης

Τι είναι το OpenID Connect;

OpenID Connect (OIDC) — είναι ένα ανοιχτό πρωτόκολλο αυθεντικοποίησης χτισμένο ως επίπεδο πάνω από το OAuth 2.0. Τυποποιεί αυτό που έλειπε από το OAuth 2.0: την επαλήθευση ταυτότητας του χρήστη. Εάν το OAuth 2.0 απαντά στην ερώτηση “ποια εφαρμογή έχει πρόσβαση;”, τότε το OIDC απαντά στην ερώτηση “ποιος ακριβώς είναι αυτός ο χρήστης;”.

Το πρωτόκολλο χρησιμοποιεί ID Token — JSON Web Token (JWT), το οποίο περιέχει ένα σύνολο claims: μοναδικό αναγνωριστικό υποκειμένου, email, όνομα, avatar, χρονικές σημάνσεις έκδοσης και λήξης. Η εφαρμογή-πελάτης μπορεί να επαληθεύσει κρυπτογραφικά το ID Token — ο διακομιστής υπογράφει το token με RS256 ή ES256, και ο πελάτης ελέγχει την υπογραφή με το δημόσιο κλειδί που λαμβάνεται μέσω του JWKS endpoint.

Σύμφωνα με τα δεδομένα της Auth0, 2025, πάνω από το 78% των εφαρμογών κινητών που χρησιμοποιούν αυθεντικοποίηση τρίτων εφαρμόζουν OIDC μέσω Google Sign-In ή Sign in with Apple. Αυτό καθιστά το πρωτόκολλο de facto πρότυπο για social login και εταιρική αυθεντικοποίηση.

Πώς λειτουργεί το OpenID Connect

OpenID Connect ορίζει πολλαπλές ροές (flows) ανάλογα με τον τύπο πελάτη. Για εφαρμογές κινητών, το πρότυπο είναι το Authorisation Code Flow με Proof Key for Code Exchange (PKCE) — παρέχει προστασία ακόμη και χωρίς client secret στη συσκευή.

Identity Provider και ο ρόλος του

Identity Provider (IdP) — είναι ο διακομιστής που εκτελεί την αυθεντικοποίηση του χρήστη και εκδίδει tokens. Στο οικοσύστημα OIDC, το IdP παρέχει δύο βασικά endpoints: Authorisation Endpoint για τη σύνδεση του χρήστη και Token Endpoint για την ανταλλαγή κωδικού με tokens. Ο πελάτης μαθαίνει τις διευθύνσεις αυτών των endpoints μέσω του Discovery URL — της τυπικής διαδρομής /.well-known/openid-configuration, η οποία επιστρέφει ένα έγγραφο JSON με όλη τη διαμόρφωση του παρόχου.

Κάθε IdP δημοσιεύει το δικό του JWKS (JSON Web Key Set) — σύνολο δημόσιων κλειδιών για την επαλήθευση της υπογραφής του ID Token. Ο πελάτης αποθηκεύει προσωρινά αυτά τα κλειδιά και τα χρησιμοποιεί για την επαλήθευση κάθε ληφθέντος token χωρίς να επικοινωνεί με τον διακομιστή.

Authorisation Code Flow με PKCE

Authorisation Code Flow — είναι μια διαδικασία τριών βημάτων. Πρώτα, η εφαρμογή κινητού δημιουργεί ένα code verifier (τυχαία συμβολοσειρά μήκους 43–128 χαρακτήρων) και το hash του — code challenge. Η εφαρμογή ανοίγει ένα πρόγραμμα περιήγησης ή WebView με μια διεύθυνση URL που περιέχει client_id, redirect_uri, scope (openid profile email) και code challenge. Ο χρήστης εισάγει τα διαπιστευτήριά του στη σελίδα IdP και επιβεβαιώνει τη συγκατάθεση. Το IdP ανακατευθύνει το πρόγραμμα περιήγησης πίσω στην εφαρμογή με ένα authorisation code.

Στο δεύτερο βήμα, η εφαρμογή στέλνει το authorisation code, code verifier και client_id στο Token Endpoint του διακομιστή. Ο διακομιστής ελέγχει το code verifier έναντι του αποθηκευμένου code challenge και επιστρέφει ID Token, Access Token και προαιρετικά Refresh Token. Στο τρίτο βήμα, η εφαρμογή επαληθεύει το ID Token: επικυρώνει την υπογραφή μέσω JWKS, ελέγχει τα issuer (iss), audience (aud) και χρόνο λήξης (exp). Εάν η επαλήθευση είναι επιτυχής — ο χρήστης θεωρείται αυθεντικοποιημένος.

Το PKCE (Proof Key for Code Exchange) εξαλείφει την ευπάθεια που είναι εγγενής στο τυπικό Authorisation Code Flow σε δημόσιους πελάτες. Δεδομένου ότι η εφαρμογή κινητού δεν μπορεί να αποθηκεύσει με ασφάλεια το client secret, ένας εισβολέας που υποκλέπτει το authorisation code θα μπορούσε να το ανταλλάξει με tokens. Το Code verifier λύνει αυτό το πρόβλημα: ακόμη κι αν ο κωδικός υποκλαπεί, χωρίς το αρχικό code verifier η ανταλλαγή είναι αδύνατη. Το OAuth Security Best Practices (RFC 9700) απαιτεί PKCE για όλους τους δημόσιους πελάτες, συμπεριλαμβανομένων των εφαρμογών κινητών.

ID Token και Access Token

Το OpenID Connect επιστρέφει δύο θεμελιωδώς διαφορετικά tokens: ID Token και Access Token. ID Token — είναι πάντα JWT που ο πελάτης μπορεί να διαβάσει και να επαληθεύσει ανεξάρτητα. Περιέχει πληροφορίες για τον χρήστη και χρησιμοποιείται για αυθεντικοποίηση, όχι για πρόσβαση σε API.

Δομή του ID Token

ID Token αποτελείται από header, payload και signature, κωδικοποιημένα σε Base64 και χωρισμένα με τελείες. Το header περιέχει alg (αλγόριθμο υπογραφής) και kid (αναγνωριστικό κλειδιού). Το payload περιλαμβάνει υποχρεωτικά claims: iss (issuer — εκδότης του token), sub (subject — μοναδικό ID του χρήστη), aud (audience — αναγνωριστικό πελάτη), exp (expiration), iat (issued at). Προαιρετικά — name, email, picture, locale.

Παράδειγμα αποκωδικοποιημένου payload ID Token από την Google:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ιβάν Πετρόφ",
  "email": "ivan@example.com"
}

Access Token — είναι ένα αδιαφανές token (αυθαίρετη συμβολοσειρά) ή JWT που ο πελάτης μεταφέρει σε αιτήματα API. Σε αντίθεση με το ID Token, το access token δεν προορίζεται για ανάγνωση από τον πελάτη — η μορφή και το περιεχόμενό του είναι γνωστά μόνο στον διακομιστή πόρων και στον διακομιστή εξουσιοδότησης. Το Access Token έχει scope — περιορισμό δικαιωμάτων πρόσβασης — και σύντομη διάρκεια ζωής, συνήθως 15–60 λεπτά.

Διαφορές μεταξύ OpenID Connect και OAuth 2.0

OAuth 2.0 — είναι ένα πλαίσιο εξουσιοδότησης που ορίζει πώς μια εφαρμογή αποκτά πρόσβαση στους πόρους του χρήστη. OpenID Connect — είναι ένα επίπεδο που προσθέτει αυθεντικοποίηση σε αυτή τη διαδικασία. Η βασική διαφορά: το OAuth 2.0 δεν ορίζει τη μορφή token και δεν δίνει στην εφαρμογή τρόπο να μάθει ποιος ακριβώς έκανε το αίτημα.

Πότε να επιλέξετε OpenID Connect

Το OpenID Connect είναι απαραίτητο όταν η εφαρμογή πρέπει να αναγνωρίσει τον χρήστη, όχι απλώς να αποκτήσει πρόσβαση στα δεδομένα του. Εάν χρησιμοποιείτε “Σύνδεση με Google” ή “Sign in with Apple” — αυτό είναι OIDC. Εάν η εφαρμογή σας καλεί API τρίτου μέρους εκ μέρους του χρήστη χωρίς να χρειάζεται να γνωρίζει την ταυτότητά του — αρκεί το καθαρό OAuth 2.0. Για εταιρικά συστήματα με Single Sign-On (SSO) η επιλογή είναι σαφής: μόνο OpenID Connect, καθώς παρέχει τυποποιημένη αποσύνδεση και διαχείριση περιόδου σύνδεσης.

Υλοποίηση του OpenID Connect σε εφαρμογές κινητών

Η ενσωμάτωση του OpenID Connect σε μια εφαρμογή κινητού απαιτεί την επιλογή κατάλληλης βιβλιοθήκης και σωστή διαμόρφωση της ροής. Για Android χρησιμοποιείται το credential manager (AndroidX Credentials) ή η βιβλιοθήκη AppAuth. Για iOS — το πλαίσιο AuthenticationServices με ASWebAuthenticationSession.

Παράδειγμα κώδικα σε Kotlin (Android)

Παρακάτω υπάρχει ένα παράδειγμα εκκίνησης του Authorisation Code Flow με τη βιβλιοθήκη AppAuth-Android. Η εφαρμογή δημιουργεί ένα αίτημα εξουσιοδότησης, ανοίγει το πρόγραμμα περιήγησης για σύνδεση του χρήστη και επεξεργάζεται το callback με τα tokens.

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

Παράδειγμα κώδικα σε Swift (iOS)

Το ASWebAuthenticationSession από την Apple παρέχει ενσωματωμένο πρόγραμμα περιήγησης για τη ροή OIDC με υποστήριξη SSO μέσω iCloud Keychain. Η περίοδος σύνδεσης ξεκινά με τη διεύθυνση URL εξουσιοδότησης και το callback επεξεργάζεται μέσω ενός completion handler.

Κατά την επιλογή βιβλιοθήκης για OpenID Connect, λάβετε υπόψη την ενσωματωμένη υποστήριξη PKCE: τα AppAuth-Android και AppAuth-iOS υποστηρίζουν PKCE από προεπιλογή. Το Firebase Authentication χρησιμοποιεί OIDC στο παρασκήνιο για Google Sign-In, Sign in with Apple και Microsoft — ο προγραμματιστής δεν χρειάζεται να υλοποιήσει τη ροή χειροκίνητα. Για εταιρικά συστήματα με δικό τους IdP (π.χ. Keycloak ή Okta), το AppAuth παραμένει η τυπική επιλογή με πλήρη έλεγχο της διαμόρφωσης και διαχείρισης σφαλμάτων.

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()