OIDC endpoints

Each directory is an OpenID Provider (OpenID Connect Core 1.0, OAuth 2.0) with its own issuer, https://<alias>.sso.ezgh.app, its own signing keys and its own clients. These endpoints are defined by the standards, so they aren’t part of the management API reference. They never accept EZGH Cloud API keys, logins or console sessions.

Discovery, JWKS, token, userinfo, introspection and revocation answer CORS requests from any origin, without credentials, so single-page apps can call them.

Discovery

GET /.well-known/openid-configuration (also at /.well-known/oauth-authorization-server, the same document) describes the provider:

JWKS

GET /jwks is the directory’s public signing keys: an RSA key (RS256) and a P-256 key (ES256), each with a kid. Keys rotate every 90 days; a new key appears 7 days before it signs, and an old key stays 7 days after it stops. Fetch keys by kid when you see one you don’t have.

Authorization

/oauth2/authorize starts a sign-in. Parameters:

Not supported: request and request_uri (request_not_supported, request_uri_not_supported), the claims parameter, other response types and modes.

• Every authorization response, including errors, carries iss (RFC 9207). Check it.
• There’s no consent screen for your applications: assigning a user is your consent.
• Without a session the person signs in at the portal first, under the directory’s policy, and comes back.
• A person who isn’t assigned sees an error page; with prompt=none the app gets access_denied. An unknown client or an unregistered redirect URI shows an error page too, and never redirects.

Token

POST /oauth2/token, form-encoded. Grants: authorization_code (with code, redirect_uri, and code_verifier when PKCE was used) and refresh_token (with refresh_token, and optionally a narrower scope).

Client authentication, by the application’s tokenEndpointAuthMethod: HTTP Basic with the client ID and secret (client_secret_basic), client_id and client_secret in the form (client_secret_post; a secret client may use either), a client_assertion JWT (private_key_jwt), or client_id alone (public clients).

The answer has access_token, token_type (Bearer), expires_in, scope, id_token (with openid) and refresh_token (with offline_access). Errors are OAuth’s: invalid_grant for a used, expired or revoked code or refresh token, or a user who is no longer active or assigned; invalid_client for failed client authentication.

Userinfo

GET or POST /oauth2/userinfo with Authorization: Bearer <access token> returns the claims the token’s scopes grant (see Scopes and claims). A token that isn’t active is 401 with WWW-Authenticate: Bearer error="invalid_token"; a token without openid is 403.

Introspection

POST /oauth2/introspect (RFC 7662), with token, for confidential (web) applications, authenticated as at the token endpoint. An application can introspect its own refresh tokens, and access tokens issued to it or for it: an API registered as its own application, named in the token’s aud through the issuing application’s accessTokenAudience. The answer is { "active": false } for anything revoked, expired, belonging to a suspended or deleted user, or not the caller’s.

Revocation

POST /oauth2/revoke (RFC 7009), with token, authenticated as at the token endpoint (public clients send client_id). Revoking a refresh token ends its whole grant; revoking an access token ends that token.

Logout

/oauth2/logout (OpenID Connect RP-Initiated Logout 1.0) ends the person’s portal session.

Applications with a backchannelLogoutUri are told through back-channel logout.

Registration

POST /oauth2/register (RFC 7591) registers a public client for EZGH resource tokens, the way MCP clients sign in to EZGH products. Clients registered here can’t sign in to your applications and get no ID tokens. See EZGH apps and MCP clients.