OpenID Connect: What It Is, Authentication and Authorization Protocol

What is OpenID Connect?

OpenID Connect (OIDC) is an open authentication protocol built as an extension on top of OAuth 2.0. It standardizes what OAuth 2.0 was missing: user identity verification. If OAuth 2.0 answers the question “which application has access?”, then OIDC answers “who exactly is this user?”.

The protocol uses an ID Token — a JSON Web Token (JWT) that contains a set of claims: a unique subject identifier, email, name, avatar, issue and expiration timestamps. The client application can cryptographically verify the ID Token — the server signs the token using RS256 or ES256, and the client checks the signature against the public key obtained through the JWKS endpoint.

According to Auth0, 2025, over 78% of mobile applications using third-party authentication employ OIDC through Google Sign-In or Sign in with Apple. This makes the protocol the de facto standard for social login and enterprise authentication.

How OpenID Connect Works

OpenID Connect defines several flows depending on the client type. For mobile applications, the standard is the Authorization Code Flow with Proof Key for Code Exchange (PKCE) — it provides security even without a client secret on the device.

Identity Provider and Its Role

An Identity Provider (IdP) is a server that authenticates users and issues tokens. In the OIDC ecosystem, the IdP provides two key endpoints: the Authorization Endpoint for user login and the Token Endpoint for exchanging the code for tokens. The client discovers these endpoint addresses through the Discovery URL — the standard path /.well-known/openid-configuration, which returns a JSON document with the full provider configuration.

Each IdP publishes its JWKS (JSON Web Key Set) — a set of public keys for verifying the ID Token signature. The client caches these keys and uses them to verify each received token without contacting the server.

Authorization Code Flow with PKCE

The Authorization Code Flow is a three-step process. First, the mobile application generates a code verifier (a random string of 43–128 characters) and its hash — the code challenge. The application opens a browser or WebView with a URL containing the client_id, redirect_uri, scope (openid profile email) and code challenge. The user enters credentials on the IdP page and confirms consent. The IdP redirects the browser back to the application with an authorization code.

In the second step, the application sends the authorization code, code verifier and client_id to the server's Token Endpoint. The server verifies the code verifier against the stored code challenge and returns an ID Token, Access Token and optionally a Refresh Token. In the third step, the application verifies the ID Token: validates the signature against JWKS, checks the issuer (iss), audience (aud) and expiration time (exp). If the verification passes, the user is considered authenticated.

PKCE (Proof Key for Code Exchange) eliminates a vulnerability inherent in the standard Authorization Code Flow for public clients. Since a mobile application cannot securely store a client secret, an attacker who intercepts the authorization code could exchange it for tokens. The code verifier solves this problem: even if the code is intercepted, without the original code verifier the exchange is impossible. OAuth Security Best Practices (RFC 9700) require PKCE for all public clients, including mobile applications.

ID Token and Access Token

OpenID Connect returns two fundamentally different tokens: the ID Token and the Access Token. The ID Token is always a JWT that the client can read and verify on its own. It contains user information and is used for authentication, not for API access.

ID Token Structure

The ID Token consists of a header, payload and signature, encoded in Base64 and separated by dots. The header contains alg (signing algorithm) and kid (key identifier). The payload includes required claims: iss (issuer), sub (subject — unique user ID), aud (audience — client identifier), exp (expiration), iat (issued at). Optional claims include name, email, picture, locale.

Example of a decoded ID Token payload from 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"
}

The Access Token is an opaque token (arbitrary string) or JWT that the client passes in API requests. Unlike the ID Token, the access token is not intended to be read by the client — its format and contents are only known to the resource server and the authorization server. The Access Token has a scope — a permission restriction — and a short lifespan, typically 15–60 minutes.

Differences Between OpenID Connect and OAuth 2.0

OAuth 2.0 is an authorization framework that defines how an application obtains access to user resources. OpenID Connect is an extension that adds authentication to this process. The key difference: OAuth 2.0 does not define a token format and does not give the application a way to know who exactly made the request.

When to Choose OpenID Connect

OpenID Connect is necessary when the application needs to identify the user, not just gain access to their data. If you use “Sign in with Google” or “Sign in with Apple” — that is OIDC. If your application calls a third-party API on behalf of the user without needing to know their identity — plain OAuth 2.0 is sufficient. For enterprise systems with Single Sign-On (SSO), the choice is clear: only OpenID Connect, as it provides standardized logout and session management.

Implementing OpenID Connect in Mobile Applications

Integrating OpenID Connect into a mobile application requires choosing the right library and correctly configuring the flow. For Android, use the credential manager (AndroidX Credentials) or the AppAuth library. For iOS, use the AuthenticationServices framework with ASWebAuthenticationSession.

Kotlin Code Example (Android)

Below is an example of starting the Authorization Code Flow using the AppAuth-Android library. The application creates an authorization request, opens a browser for user login, and processes the callback with 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 Code Example (iOS)

Apple's ASWebAuthenticationSession provides a built-in browser for the OIDC flow with SSO support through iCloud Keychain. The session starts with the authorization URL, and the callback is handled through a completion handler.

When choosing a library for OpenID Connect, consider built-in PKCE support: AppAuth-Android and AppAuth-iOS support PKCE by default. Firebase Authentication uses OIDC under the hood for Google Sign-In, Sign in with Apple and Microsoft — the developer does not need to implement the flow manually. For enterprise systems with a custom IdP (e.g., Keycloak or Okta), AppAuth remains the standard choice with full control over configuration and error handling.

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