Course Preview

OpenID Connect

OpenID Connect is an authentication protocol built on OAuth 2.0. It lets an application rely on an identity provider for sign-in and receive a verifiable identity result without handling the user's password.

itIdentity, access, and cryptography | OpenSkills.info

OpenID Connect

OpenID Connect, commonly shortened to OIDC, is an authentication protocol built on the OAuth 2.0 framework. OAuth 2.0 delegates access to protected resources. OIDC adds a standard identity layer so an application can verify that a user authenticated and receive claims about that user.

The protocol separates the application from the system that performs authentication. The application is the Relying Party, or RP. The authentication service is the OpenID Provider, or OP. The person signing in is the End-User. The RP redirects the user's browser to the OP, receives a short-lived response, and validates an ID Token before creating its own application session.

This separation supports single sign-on and external identity. A web application, native application, or browser-based application can accept an established provider without collecting the user's provider password. The RP still owns its local account mapping, application session, and authorization decisions.

The protocol path

OIDC uses OAuth endpoints and adds identity-specific messages and validation rules. A common authorization code flow follows this path:

The RP discovers or configures the OP's issuer, authorization endpoint, token endpoint, and signing-key location.
The RP registers a client identifier, redirect URI, and other client metadata with the OP.
The RP creates an authentication request. The request includes scope=openid, the client identifier, redirect URI, response type, and request-correlation values.
The browser goes to the OP's authorization endpoint. The OP authenticates the user and may request consent.
The OP redirects the browser to the RP's exact registered redirect URI with an authorization code and the returned state value.
The RP checks state, then exchanges the code at the token endpoint. PKCE adds a verifier that binds this exchange to the client that started it.
The OP returns an ID Token and, when requested, an access token. A refresh token may also be returned.
The RP validates the ID Token before treating the result as authentication.
The RP maps the issuer and subject to a local account, then creates its own session and applies local authorization policy.

The authorization code keeps tokens out of the browser redirect. Current OAuth security guidance recommends the code flow and PKCE for browser-based and native clients. Native applications use an external user agent, normally the system browser, instead of an embedded login view.

Discovery and registration

Continue the course

This section is part of the paid course.

See pricing to subscribe, or log in if you already have access.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Backend Engineersupporting

Sources