ExamWizardzExamWizardz
Start free
Security

What is OpenID Connect?

OpenID Connect (OIDC) is an identity layer on OAuth 2.0 that issues a signed JWT ID token so an app can confirm who the user is for single sign-on.

What is OpenID Connect?

OpenID Connect (OIDC) is an authentication protocol built on top of OAuth 2.0. OAuth by itself lets an application get an access token to call an API on a user's behalf, but that token is not designed to tell the application who the user is. OIDC fills that gap by adding an ID token, a signed JSON Web Token (JWT) stating which user authenticated, at which provider, for which application and when. The OpenID Foundation published OpenID Connect Core 1.0 in 2014, and many "Sign in with" buttons on websites and mobile apps use it today, as do many enterprise identity platforms.

OIDC uses its own role names. The identity provider is the OpenID Provider (OP), and the application that relies on its word is the relying party (RP).

How an OpenID Connect login works

The recommended pattern is the authorization code flow with PKCE:

  1. The user clicks Sign in, and the app redirects the browser to the OpenID Provider with a request that includes scope=openid (often plus profile and email), the app's client ID, a redirect URI, a random state value and a nonce.
  2. The provider authenticates the user and, if needed, asks for consent.
  3. The provider redirects the browser back to the app with a short-lived authorization code.
  4. The app exchanges the code at the provider's token endpoint, proving with PKCE that it is the same client that started the flow, and receives an ID token, usually with an access token as well.
  5. The app validates the ID token and creates its own session.

The openid scope is what turns an ordinary OAuth request into an OIDC request.

Example: the claims inside an ID token

Decoded, the payload of an ID token looks like this:

{"iss":"https://login.example.com","sub":"248289761001","aud":"crm-web-app","exp":1792500000,"iat":1792496400,"nonce":"n-0S6WzA2Mj","email":"mlopez@example.com"}

Each claim has a job. iss names the provider that issued it, sub is the user's stable identifier at that provider, aud names the one app the token is meant for, exp and iat set the expiry and issue time, and nonce ties the token to the login request the app started. The app must check the signature against the provider's published keys and confirm each of these values before trusting the token. Skipping the audience check, for example, could let a token issued to a different app sign a user in.

OpenID Connect vs. OAuth vs. SAML

  • OAuth 2.0 is delegated authorization. Its access token tells an API what the app may do, such as read a calendar. It is not proof of identity to the app.
  • OpenID Connect adds authentication to OAuth. Its ID token tells the app who the user is.
  • SAML 2.0 also provides authentication for single sign-on, but with signed XML assertions, and it was designed for browser-based enterprise web apps. OIDC's JSON tokens and REST endpoints suit mobile apps, single-page apps and APIs better.

OpenID Connect is a different protocol from the older OpenID 2.0, which it replaced.

Securing OpenID Connect

  • Use the authorization code flow with PKCE. The implicit flow, which returned tokens in the browser's address bar, is no longer recommended.
  • Validate the ID token's signature, issuer, audience, expiry and nonce on every login.
  • Register exact redirect URIs so the provider never sends codes to an attacker's site.
  • Treat refresh tokens and session cookies as credentials: store them securely and revoke them when access should end.

OpenID Connect on the CompTIA Security+ exam

OpenID Connect is tested under objective 4.5 on SY0-801, alongside federation, single sign-on, SAML and OAuth. A scenario about letting users sign in to a website or mobile app with an existing cloud or social account, or one that mentions an ID token or a JWT carrying identity claims, points to OIDC. The classic trap is OAuth: if the stem stresses proving who the user is, OAuth alone is the wrong answer, because it handles authorization while OIDC adds authentication. If the stem describes XML assertions or enterprise web SSO with a partner, SAML fits better. A quick rule: OAuth answers what an app may do, OIDC answers who the user is, and SAML answers who the user is in XML.

Studying for CompTIA (Security)?

ExamWizardz turns the official objectives into a guided study plan — with practice tests, realistic PBQs, and a readiness score. Start free.

Start studying free

Related terms

federated identity

Federated identity is a system that allows users to securely access multiple applications and services using a single set of credentials across organizational boundaries.

identity provider

An identity provider (IdP) is a service that authenticates users and sends signed assertions or tokens to the apps that trust it, enabling single sign-on.

OAuth

OAuth is an open standard for authorization that allows users to grant limited access to their resources on one site, to another site, without sharing their credentials.

SAML

SAML (Security Assertion Markup Language) is an XML standard that lets an identity provider send signed assertions to an app for federated single sign-on.

SSO

Single Sign-On (SSO) is an authentication method that allows users to securely access multiple applications and systems with a single set of login credentials.

Token-Based Authentication

Token-based authentication is a security mechanism where users are granted access to a system or application by presenting a unique, tamper-resistant token, instead of providing traditional credentials like a username and password.

← Back to the full CompTIA glossary