OpenID Connect: wat is het, authenticatie- en autorisatieprotocol

Wat is OpenID Connect?

OpenID Connect (OIDC) — is een open authenticatieprotocol gebouwd als een laag bovenop OAuth 2.0. Het standaardiseert wat OAuth 2.0 miste: verificatie van de gebruikersidentiteit. Als OAuth 2.0 de vraag “welke app heeft toegang?” beantwoordt, dan beantwoordt OIDC de vraag “wie is deze gebruiker precies?”.

Het protocol gebruikt ID Token — een JSON Web Token (JWT) dat een set claims bevat: unieke identificatie van het subject, email, naam, avatar, tijdstempels van uitgifte en verval. De client-app kan het ID Token cryptografisch verifiëren — de server ondertekent het token met RS256 of ES256, en de client controleert de handtekening met de openbare sleutel verkregen via het JWKS-endpoint.

Volgens Auth0, 2025 gebruikt meer dan 78% van de mobiele apps die externe authenticatie gebruiken OIDC via Google Sign-In of Sign in with Apple. Dit maakt het protocol de de facto standaard voor social login en zakelijke authenticatie.

Hoe werkt OpenID Connect

OpenID Connect definieert meerdere stromen (flows) afhankelijk van het type client. Voor mobiele apps is de standaard de Authorisation Code Flow met Proof Key for Code Exchange (PKCE) — deze biedt bescherming, zelfs zonder client secret op het apparaat.

Identity Provider en zijn rol

Identity Provider (IdP) — is de server die de authenticatie van de gebruiker uitvoert en tokens uitgeeft. In het OIDC-ecosysteem biedt de IdP twee belangrijke endpoints: Authorisation Endpoint voor het inloggen van de gebruiker en Token Endpoint voor het ruilen van code voor tokens. De client vindt de adressen van deze endpoints via de Discovery URL — het standaardpad /.well-known/openid-configuration, dat een JSON-document retourneert met de volledige configuratie van de provider.

Elke IdP publiceert zijn eigen JWKS (JSON Web Key Set) — een set openbare sleutels voor het verifiëren van de ID Token-handtekening. De client cached deze sleutels en gebruikt ze voor verificatie van elk ontvangen token zonder de server te raadplegen.

Authorisation Code Flow met PKCE

Authorisation Code Flow — is een driefasenproces. Eerst genereert de mobiele app een code verifier (willekeurige string van 43–128 tekens) en de hash ervan — code challenge. De app opent een browser of WebView met een URL die client_id, redirect_uri, scope (openid profile email) en code challenge bevat. De gebruiker voert inloggegevens in op de IdP-pagina en bevestigt toestemming. De IdP verwijst de browser terug naar de app met een authorisation code.

In de tweede stap stuurt de app de authorisation code, code verifier en client_id naar het Token Endpoint van de server. De server controleert de code verifier tegen de opgeslagen code challenge en retourneert ID Token, Access Token en optioneel Refresh Token. In de derde stap verifieert de app het ID Token: valideert de handtekening via JWKS, controleert issuer (iss), audience (aud) en vervaltijd (exp). Als de verificatie slaagt — wordt de gebruiker als geauthenticeerd beschouwd.

PKCE (Proof Key for Code Exchange) elimineert de kwetsbaarheid die inherent is aan de standaard Authorisation Code Flow bij publieke clients. Omdat de mobiele app client secret niet veilig kan opslaan, zou een aanvaller die de authorisation code onderschept deze kunnen ruilen voor tokens. Code verifier lost dit probleem op: zelfs als de code wordt onderschept, is ruil zonder de originele code verifier onmogelijk. OAuth Security Best Practices (RFC 9700) vereisen PKCE voor alle publieke clients, inclusief mobiele apps.

ID Token en Access Token

OpenID Connect retourneert twee fundamenteel verschillende tokens: ID Token en Access Token. ID Token — is altijd een JWT dat de client onafhankelijk kan lezen en verifiëren. Het bevat informatie over de gebruiker en wordt gebruikt voor authenticatie, niet voor toegang tot een API.

Structuur van ID Token

ID Token bestaat uit een header, payload en signature, gecodeerd in Base64 en gescheiden door punten. De header bevat alg (handtekeningalgoritme) en kid (sleutelidentificatie). De payload bevat verplichte claims: iss (issuer — uitgever van het token), sub (subject — unieke ID van de gebruiker), aud (audience — identificatie van de client), exp (expiration), iat (issued at). Optioneel — name, email, picture, locale.

Voorbeeld van een gedecodeerde payload van een ID Token van 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 — is een opaque token (willekeurige string) of JWT dat de client meestuurt in API-verzoeken. In tegenstelling tot het ID Token is het access token niet bedoeld om door de client te worden gelezen — het formaat en de inhoud ervan zijn alleen bekend bij de bronserver en de autorisatieserver. Access Token heeft een scope — beperking van toegangsrechten — en een korte levensduur, meestal 15–60 minuten.

Verschillen tussen OpenID Connect en OAuth 2.0

OAuth 2.0 — is een autorisatieframework dat bepaalt hoe een app toegang krijgt tot bronnen van de gebruiker. OpenID Connect — is een laag die authenticatie toevoegt aan dit proces. Het belangrijkste verschil: OAuth 2.0 definieert geen tokenformaat en biedt de app geen manier om te weten wie precies het verzoek heeft gedaan.

Wanneer OpenID Connect kiezen

OpenID Connect is noodzakelijk wanneer de app de gebruiker moet herkennen, niet alleen toegang moet krijgen tot zijn gegevens. Als u “Inloggen met Google” of “Sign in with Apple” gebruikt — is dit OIDC. Als uw app een API van derden aanroept namens de gebruiker zonder zijn identiteit te hoeven weten — is puur OAuth 2.0 voldoende. Voor zakelijke systemen met Single Sign-On (SSO) is de keuze duidelijk: alleen OpenID Connect, omdat het gestandaardiseerde uitlogging en sessiebeheer biedt.

Implementatie van OpenID Connect in mobiele apps

Integratie van OpenID Connect in een mobiele app vereist de juiste bibliotheekkeuze en correcte configuratie van de stroom. Voor Android wordt credential manager (AndroidX Credentials) of de AppAuth-bibliotheek gebruikt. Voor iOS — het AuthenticationServices-framework met ASWebAuthenticationSession.

Voorbeeldcode in Kotlin (Android)

Hieronder staat een voorbeeld van het starten van de Authorisation Code Flow met de AppAuth-Android-bibliotheek. De app maakt een autorisatieverzoek aan, opent een browser voor gebruikerslogin en verwerkt de callback met 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)
        }
    }
}

Voorbeeldcode in Swift (iOS)

ASWebAuthenticationSession van Apple biedt een ingebouwde browser voor de OIDC-stroom met SSO-ondersteuning via iCloud Keychain. De sessie wordt gestart met de autorisatie-URL en de callback wordt verwerkt via een completion handler.

Houd bij het kiezen van een bibliotheek voor OpenID Connect rekening met PKCE-ondersteuning uit de doos: AppAuth-Android en AppAuth-iOS ondersteunen PKCE standaard. Firebase Authentication gebruikt OIDC onder de motorkap voor Google Sign-In, Sign in with Apple en Microsoft — de ontwikkelaar hoeft de stroom niet handmatig te implementeren. Voor zakelijke systemen met een eigen IdP (bijv. Keycloak of Okta) blijft AppAuth de standaardkeuze met volledige controle over configuratie en foutafhandeling.

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