OpenID Connect
Most important commands to remember
curl --fail --silent --show-error— fetch the provider’s discovery document.jq— inspect issuer, endpoints, and supported protocol features.
Commands and flags
| Command or option | Meaning |
|---|---|
--fail |
Make HTTP errors return a failure status. |
--silent --show-error |
Hide progress while displaying failures. |
--max-time 10 |
Allow at most ten seconds for the transfer. |
jq '{…}' |
Select named fields from the JSON response. |
| |
Pass the response body into jq. |
The URL selects a known provider’s public configuration. No user identity or session is sent in this example.
The concepts that matter
1. OIDC supplies an authentication result
OpenID Connect, or OIDC, builds an identity layer on OAuth 2.0. An application asks an identity provider to authenticate a person and receives a defined identity result. Requesting the openid scope distinguishes an OIDC request from an ordinary OAuth authorization request.
This lets an application delegate sign-in while retaining responsibility for its own permissions. Being authenticated by the provider does not automatically make someone an administrator of your application.
2. An ID token is for the client
The ID token is a JWT describing an authentication result for the client. The client validates it using its configured provider, audience, time constraints, and the protocol’s applicable checks. An access token serves a different purpose: access to a protected resource.
Do not interchange the two just because both happen to look like JWTs. An API should not accept an ID token as its access token, and a client should not infer a login contract from arbitrary access-token contents.
3. Discovery connects configuration to trusted keys
A discovery document advertises the issuer, authorization endpoint, token endpoint, and often a JWKS URI for public signing keys. Clients can use this metadata instead of manually guessing service URLs.
Trust starts with the provider you intentionally configured. Fetching metadata from an arbitrary URL supplied by an untrusted token would let the token choose its own authority. Key rotation is normal, so maintained OIDC libraries handle trusted metadata and key refresh according to policy.
4. A login must belong to the right request and person
A client must bind the returning result to its own login transaction, following the chosen flow’s protections. A nonce, when sent, must match the ID token; authorization-code flows also use protections such as PKCE and appropriate request-state handling.
For account identity, use the issuer and subject identifier together. A display name is not unique, and an email address can change. After validation, the application usually creates its own session; that session has a lifecycle separate from the provider’s token.
One small example
Optional: inspect Google’s public OIDC discovery document. This is a configuration exercise and does not require a Google account or registered client.
curl --fail --silent --show-error --max-time 10 https://accounts.google.com/.well-known/openid-configuration | jq '{issuer, authorization_endpoint, token_endpoint, jwks_uri, scopes_supported, response_types_supported}'Find issuer, then compare the browser-facing authorization endpoint with the token endpoint. jwks_uri identifies the public key set location; it is not a private signing key. Look for openid among the supported scopes.
The returned capability lists describe the provider, not a recommendation to use every advertised flow. A successful request proves neither user authentication nor ID-token validity. Completing sign-in additionally needs a registered client, exact redirect configuration, and a library that validates the response and creates the local session.
Keep this idea: OIDC tells a client who authenticated under a trusted issuer; the application still decides what that identity may do.