OpenID Connect (OIDC)

OpenID Connect is the protocol behind "Sign in with Google", and with Facebook, Microsoft, Apple, and thousands of other "Sign in with X" buttons you've clicked. It answers one specific question: how does a website prove who you are, using an account you already have somewhere else, without that website ever seeing your password?

Under the hood, OIDC is a thin identity layer built on top of OAuth 2.0 (see that entry), which by itself only handles authorization, "let this app access my data", not identity. OIDC adds a standard, signed proof of who logged in: the ID Token, a JSON Web Token (see JWT) containing claims like "this is user 12345, authenticated at this time, by this provider." A website that trusts the provider's signature can treat that as a login, without running its own password database or ever seeing your credentials.

The three parties in every OIDC flow have standard names: the OpenID Provider (OP), the service that authenticates you and issues the token (Google, in the "Sign in with Google" example); the Relying Party (RP). The website or app that wants to know who you are; and you, the End-User. A standard metadata document, published at a predictable URL (/.well-known/openid-configuration), tells any RP exactly where the OP's authorization, token, userinfo, and public-key endpoints live, no manual configuration required.

Where it comes from

OpenID Connect 1.0 was finalized in 2014 by the OpenID Foundation's OpenID Connect Working Group. Its principal authors, Nat Sakimura, John Bradley, Michael B. Jones, Breno de Medeiros, and Edmund Jay, are, almost to a person, the same small group behind JWT, JWKS, and PKCE. That's not a coincidence worth glossing over: OIDC doesn't introduce much new cryptography or wire format of its own. Its real contribution is standardizing the login flow, which parameters mean what, which claims are mandatory, how discovery works, so that any OIDC client can talk to any OIDC provider without custom integration work. Solidus wrote none of this specification.

Solidus today

auth.solidus.network is Solidus's own OpenID Provider, live, answering the standard discovery endpoint, issuing EdDSA-signed ID Tokens and DPoP-bound Solid-OIDC access tokens (see DPoP, Solid-OIDC), and exposing authorization, token, userinfo, introspection, and revocation endpoints that match the spec's shapes. It authenticates against did:solidus DIDs, Solidus's own decentralized identifiers, rather than a username and password database, which is the actual point: an OIDC login backed by a DID you control, instead of an account a platform owns. All of it runs on Solidus's public testnet today; there is no mainnet identity yet, and no independent OpenID Foundation certification has been sought.

See also

OAuth 2.0 is the authorization framework OIDC extends. JWT is the token format the ID Token and access tokens use. JWKS is how a relying party gets the public key to verify them. Solid-OIDC is the specific OIDC profile that powers login for Solidus's Pod product.