OpenID Connect: ce este, protocol de autentificare și autorizare

Ce este OpenID Connect?

OpenID Connect (OIDC) — este un protocol deschis de autentificare construit ca un strat peste OAuth 2.0. Standardizează ceea ce lipsea în OAuth 2.0: verificarea identității utilizatorului. Dacă OAuth 2.0 răspunde la întrebarea „care aplicație are acces?„, atunci OIDC răspunde la întrebarea „cine este exact acest utilizator?„.

Protocolul folosește ID Token — JSON Web Token (JWT), care conține un set de claims: identificatorul unic al subiectului, email, nume, avatar, timestamp-uri de emitere și expirare. Aplicația client poate verifica ID Token criptografic — serverul semnează tokenul cu RS256 sau ES256, iar clientul verifică semnătura cu cheia publică obținută prin JWKS endpoint.

Conform datelor Auth0, 2025, peste 78% din aplicațiile mobile care folosesc autentificare terță parte utilizează OIDC prin Google Sign-In sau Sign in with Apple. Aceasta face protocolul un standard de facto pentru social login și autentificare corporativă.

Cum funcționează OpenID Connect

OpenID Connect definește mai multe fluxuri (flows) în funcție de tipul clientului. Pentru aplicații mobile, standardul este Authorisation Code Flow cu Proof Key for Code Exchange (PKCE) — oferă protecție chiar și fără client secret pe dispozitiv.

Identity Provider și rolul său

Identity Provider (IdP) — este serverul care efectuează autentificarea utilizatorului și emite tokeni. În ecosistemul OIDC, IdP oferă două endpoint-uri cheie: Authorisation Endpoint pentru autentificarea utilizatorului și Token Endpoint pentru schimbul codului pe tokeni. Clientul află adresele acestor endpoint-uri prin Discovery URL — calea standard /.well-known/openid-configuration, care returnează un document JSON cu toată configurația furnizorului.

Fiecare IdP publică propriul JWKS (JSON Web Key Set) — set de chei publice pentru verificarea semnăturii ID Token. Clientul stochează aceste chei și le folosește pentru verificarea fiecărui token primit fără a apela serverul.

Authorisation Code Flow cu PKCE

Authorisation Code Flow — este un proces în trei pași. Mai întâi, aplicația mobilă generează un code verifier (șir aleator de 43–128 de caractere) și hash-ul său — code challenge. Aplicația deschide un browser sau WebView cu URL-ul care conține client_id, redirect_uri, scope (openid profile email) și code challenge. Utilizatorul introduce datele de autentificare pe pagina IdP și confirmă consimțământul. IdP redirecționează browserul înapoi la aplicație cu un authorisation code.

În al doilea pas, aplicația trimite authorisation code, code verifier și client_id la Token Endpoint-ul serverului. Serverul verifică code verifier-ul împotriva code challenge-ului salvat și returnează ID Token, Access Token și opțional Refresh Token. În al treilea pas, aplicația verifică ID Token: validează semnătura prin JWKS, verifică issuer (iss), audience (aud) și timpul de expirare (exp). Dacă verificarea reușește — utilizatorul este considerat autentificat.

PKCE (Proof Key for Code Exchange) elimină vulnerabilitatea inerentă a Authorisation Code Flow standard în clienții publici. Deoarece aplicația mobilă nu poate stoca în siguranță client secret, un atacator care a interceptat authorisation code ar putea să-l schimbe pe tokeni. Code verifier rezolvă această problemă: chiar dacă codul este interceptat, fără code verifier-ul original schimbul este imposibil. OAuth Security Best Practices (RFC 9700) impun PKCE pentru toți clienții publici, inclusiv aplicațiile mobile.

ID Token și Access Token

OpenID Connect returnează doi tokeni fundamental diferiți: ID Token și Access Token. ID Token — este întotdeauna un JWT pe care clientul îl poate citi și verifica independent. Conține informații despre utilizator și este utilizat pentru autentificare, nu pentru acces la API.

Structura ID Token

ID Token constă din header, payload și signature, codificate în Base64 și separate prin puncte. Header-ul conține alg (algoritmul de semnare) și kid (identificatorul cheii). Payload-ul include claims obligatorii: iss (issuer — emitentul tokenului), sub (subject — ID-ul unic al utilizatorului), aud (audience — identificatorul clientului), exp (expiration), iat (issued at). Opțional — name, email, picture, locale.

Exemplu de payload decodat al ID Token de la Google:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ivan Petrov",
  "email": "ivan@example.com"
}

Access Token — este un token opac (șir arbitrar) sau JWT pe care clientul îl transmite în cererile API. Spre deosebire de ID Token, access token nu este destinat citirii de către client — formatul și conținutul său sunt cunoscute doar de serverul de resurse și serverul de autorizare. Access Token are scope — limitarea drepturilor de acces — și o durată de viață scurtă, de obicei 15–60 de minute.

Diferențele dintre OpenID Connect și OAuth 2.0

OAuth 2.0 — este un cadru de autorizare care definește modul în care o aplicație obține acces la resursele utilizatorului. OpenID Connect — este un strat care adaugă autentificare la acest proces. Diferența cheie: OAuth 2.0 nu definește formatul tokenului și nu oferă aplicației o modalitate de a afla cine a făcut exact cererea.

Când să alegeți OpenID Connect

OpenID Connect este necesar atunci când aplicația trebuie să recunoască utilizatorul, nu doar să obțină acces la datele sale. Dacă utilizați „Autentificare cu Google„ sau „Sign in with Apple„ — acesta este OIDC. Dacă aplicația dvs. apelează o API terță parte în numele utilizatorului fără a fi nevoie să-i cunoască identitatea — este suficient OAuth 2.0 pur. Pentru sistemele corporative cu Single Sign-On (SSO) alegerea este clară: doar OpenID Connect, deoarece oferă deconectare standardizată și gestionare a sesiunilor.

Implementarea OpenID Connect în aplicații mobile

Integrarea OpenID Connect într-o aplicație mobilă necesită alegerea bibliotecii potrivite și configurarea corectă a fluxului. Pentru Android se utilizează credential manager (AndroidX Credentials) sau biblioteca AppAuth. Pentru iOS — framework-ul AuthenticationServices cu ASWebAuthenticationSession.

Exemplu de cod în Kotlin (Android)

Mai jos este un exemplu de lansare a Authorisation Code Flow cu ajutorul bibliotecii AppAuth-Android. Aplicația creează o cerere de autorizare, deschide browserul pentru autentificarea utilizatorului și procesează callback-ul cu tokeni.

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

Exemplu de cod în Swift (iOS)

ASWebAuthenticationSession de la Apple oferă un browser încorporat pentru fluxul OIDC cu suport SSO prin iCloud Keychain. Sesiunea este pornită cu URL-ul de autorizare, iar callback-ul este procesat prin completion handler.

La alegerea bibliotecii pentru OpenID Connect luați în considerare suportul PKCE din cutie: AppAuth-Android și AppAuth-iOS suportă PKCE implicit. Firebase Authentication folosește OIDC sub capotă pentru Google Sign-In, Sign in with Apple și Microsoft — dezvoltatorul nu trebuie să implementeze manual fluxul. Pentru sistemele corporative cu IdP propriu (de exemplu, Keycloak sau Okta) AppAuth rămâne alegerea standard cu control complet asupra configurației și gestionării erorilor.

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()