What is OIDC (OpenID Connect)?
OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0, published by the OpenID Foundation. An application redirects the user to an identity provider, which authenticates them and returns a signed ID token in JSON Web Token format. The token carries claims such as the user identifier, email and name, which the application verifies before sign-in.
How Personal Academy handles it
Personal Academy offers OIDC single sign-on configured in-app per organisation, where an administrator enters the issuer, client id, client secret and claim names, on every paid plan.
A worked example
Suppose a 300-person design agency already signs in to most tools with its cloud identity provider. An administrator registers the learning platform as an application in the provider, copies the issuer address, client identifier and secret into the platform single sign-on settings, and confirms which claim holds the email address. From then on, staff choose the company sign-in button and arrive in their courses without a separate password.
OAuth 2.0 was designed for delegated authorisation, letting one application act on a user behalf in another. It did not say how to tell who the user was. OpenID Connect, finalised in 2014, added that missing piece, and it is now the default sign-in protocol for many cloud identity providers and consumer sign-in buttons.
The most common flow is the authorisation code flow. The application sends the browser to the provider authorisation endpoint with its client identifier, the scopes it wants (openid, email, profile), a redirect address and a random state value. After the user signs in, the provider redirects back with a short-lived code. The application exchanges the code at the token endpoint, using its client secret or a signed assertion, and receives an ID token and usually an access token. PKCE adds protection for the exchange.
The ID token is a signed JWT. The application checks the signature using the keys the provider publishes, then checks the issuer, audience, expiry and nonce. Claims inside the token identify the user. Providers differ in which claims they send and what they call them, which is why many products let administrators map claim names.
Discovery makes setup simpler: a provider publishes a well-known configuration document listing its endpoints and keys, so an application only needs the issuer address to find the rest.
Compared with SAML, OIDC uses JSON and REST rather than XML, suits mobile and single-page applications, and is often quicker to configure. Like SAML, it handles sign-in only; account creation and removal are usually handled by SCIM.