SSOGEN / OpenID Connect Provider

SSOGEN

OpenID Connect Provider

An OpenID Connect provider is the server that signs a person in and tells an application who they are. SSOGEN is one: applications register once and get a discovery document, signing keys and standard endpoints.

Try SSOGEN

An OpenID Connect provider is a server that signs people in and hands applications signed proof of who they are. SSOGEN is a complete OpenID Connect provider:

An application you build or buy uses it for single sign-on.
A back-end service uses it to get tokens for an API.
An AI agent uses it to get short-lived, scoped access.

The spec calls the provider an OpenID Provider (OP) and the application a Relying Party (RP).

In OpenID Connect Core 1.0 the OP is an “OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party”. The RP is an “OAuth 2.0 Client application requiring End-User Authentication and Claims”.

If you want the protocol first, read what OpenID Connect is.

OpenID Connect sign-in with PKCE

The provider, the relying party and where people come from

Your application (the relying party) trusts one provider. The provider decides how each person proves who they are, then returns an ID token. Where people actually sign in is a separate choice, covered below.

Step 1 sends the browser to the provider; step 2 returns the code, which the application redeems for an ID token. Sign-in sources are chosen in the provider.

What the provider publishes

OpenID Connect Discovery 1.0 says an OP that supports discovery must serve a JSON document at the issuer address plus /.well-known/openid-configuration. The document must contain:

the issuer
the authorization endpoint
the token endpoint (unless only the implicit flow is used)
the JWKS address
the response types supported
the subject types supported
the ID token signing algorithms supported

The JWKS holds the public keys a relying party uses to check signatures. It must not contain private or symmetric key values. The UserInfo endpoint returns claims about the person when you call it with an access token.

In SSOGEN, the Integration tab of each registered application lists all of these. For an issuer of https://sso.acme.example:

Item	Value	Used for
Discovery document	`https://sso.acme.example/.well-known/openid-configuration`	Point a library here and it configures itself
Authorization endpoint	`https://sso.acme.example/oauth2/authorize`	Where the browser is sent
Token endpoint	`https://sso.acme.example/oauth2/token`	Where the code is redeemed
JWKS	`https://sso.acme.example/oauth2/jwks`	Keys that verify what SSOGEN signs
UserInfo endpoint	`https://sso.acme.example/oauth2/userinfo`	Claims for an authenticated person
End session endpoint	`https://sso.acme.example/oauth2/logout`	Signs the person out of SSOGEN

Paste a token into the JWT decoder to read its claims, or a key set into the JWKS inspector to check the keys. If an agent presents a DPoP proof, the DPoP proof checker runs the resource server’s checks.

What a relying party registers

The provider knows a relying party by a client ID and a list of redirect URIs.

RFC 9700 (the OAuth 2.0 security best current practice) says authorization servers must compare redirect URIs by exact string match. The one exception is port numbers on localhost redirects of native apps.

SSOGEN applies an even stricter rule:

HTTPS only. Every redirect URI must start with https://, with no wildcards.
Exact match. A trailing slash makes a different address.
Up to 16. You can register up to 16.

To register an application:

In the Admin Console, go to Applications, then OpenID Connect, then Register OpenID Connect app.
Enter a Client ID (lowercase letters, numbers and hyphens, 64 characters at most) and the Redirect URI list.
Pick a sign-in policy, and set what the application learns about the person under Identity sent to app.
Click Run test. It shows the ID token claims and UserInfo claims the application would get.

The full walk-through is in register an OpenID Connect application.

Which flow to use

An OAuth client is either confidential (it can keep a credential secret) or public, per RFC 6749, section 2.1. That, plus whether a person is present, picks the flow.

Client	Flow	Why	Source
Web app with a server	Authorization code, with PKCE	The code is redeemed server to server; RFC 9700 recommends PKCE for confidential clients too	RFC 9700, section 2.1.1
Single-page app	Authorization code with PKCE, no implicit flow	Public clients must use PKCE; clients should not use the implicit grant unless token injection is prevented	RFC 9700, sections 2.1.1 and 2.1.2
Native or mobile app	Authorization code with PKCE	A public client that cannot keep a secret	RFC 9700, section 2.1.1; RFC 6749, section 2.1
Back-end service, no person	Client credentials	The client asks for a token about itself, using its own credentials	RFC 6749, section 4.4

SSOGEN follows this guidance directly. People sign in with the authorization code flow, with PKCE and the S256 method required, and SSOGEN offers no implicit or hybrid flow to misuse.

A new application is a public client (None - PKCE only).

On the Sign-in tokens tab, a server application can pick Private key JWT (recommended) or Client secret instead. The secret is generated, stored only as a hash and shown once.

Service applications use the client credentials flow and cannot use PKCE-only. They ask for a token for a registered audience and never get a refresh token. For how PKCE works, see what PKCE is.

Signing out is not the same as signing in

SSOGEN’s end session endpoint signs the person out of SSOGEN, not only the application.

Without post_logout_redirect_uri. The request ends the session and returns HTTP 204.
With post_logout_redirect_uri. The request gets HTTP 400, because SSOGEN registers no post-logout redirect addresses.

The pattern is simple: end your own application’s session first, then call the endpoint without that parameter and show your own signed-out page.

Other providers differ. Microsoft’s documentation, for example, lets an app pass a post_logout_redirect_uri that matches a registered redirect URI. Test sign-out early.

How provider options compare

Facts below come from each project’s own documentation and the specifications, read 2026-10-11. Last compared 2026-10-11.

Vendors change their products, so check the linked pages before you decide. “Not stated” means the page we read did not say, not that the product lacks it.

	SSOGEN	Keycloak	Microsoft Entra ID	Okta	Auth0
Discovery document	`/.well-known/openid-configuration` on the issuer	`/realms/{realm-name}/.well-known/openid-configuration`	`/.well-known/openid-configuration` under `https://login.microsoftonline.com/{tenant}/v2.0`	Documented as a discovery document of an authorization server; path not stated on the page read	`https://{yourDomain}/.well-known/openid-configuration`
Authorization code flow	Yes; the only flow for people, PKCE S256 required	Documented	Documented (token endpoint redeems codes)	Recommended with PKCE	Recommended for regular web apps; with PKCE for SPAs and native apps
Client credentials	Service applications	Documented for clients acting for themselves	Token endpoint redeems client credentials	Documented for server-side apps with no end user	Documented for machine-to-machine apps
Implicit flow	No implicit or hybrid flow	Documented, with security risks noted	ID tokens for implicit and hybrid flows are an opt-in setting	Described as a legacy flow for SPAs that cannot support PKCE	Not stated
Also documented	Private key JWT or client secret; refresh tokens per application	Device authorization grant	Front-channel logout for single sign-out	Interaction code flow, SAML 2.0 assertion flow	Not stated

Sources for that table: Keycloak OpenID Connect layers, Microsoft Learn, OpenID Connect in Entra ID, Okta OAuth 2.0 and OpenID Connect concepts, Auth0 authentication and authorization flows and Auth0 OIDC discovery. Keycloak, Microsoft Entra ID, Okta and Auth0 are trademarks of their owners; SSOGEN is not affiliated with them.

If your estate is entirely Microsoft cloud, Entra ID is already the provider your employees use. If you want to run and extend an open source server yourself, Keycloak documents a wide set of grants.

SSOGEN is the provider that covers the whole estate. The same OpenID Connect provider protects older web applications through the SSOGEN Web Agent and signs in AI agents, described in AI agent identity.

Relying party side: the Web Agent

SSOGEN sits on the other end of the protocol too. The Web Agent can run as an OpenID Connect client inside Apache or Oracle HTTP Server, against SSOGEN or another provider.

Its standalone OpenID Connect mode in brief:

Protocol steps. It handles discovery, the authorization code flow with PKCE, nonce and ID token validation.
User claim. The default is preferred_username (configurable).
Result. An application with no OpenID Connect library can therefore sit behind any provider that speaks it.

Service applications and AI agents

Registration. A service application registers audiences, optional scopes and an access token lifetime (15 minutes by default, 5 to 60 minutes).
Verification. The API that gets the token fetches the keys from the JWKS address and checks iss, aud and exp.

AI agent identity uses the same standards:

Autonomous agents. They use OAuth 2.0 client credentials.
Delegated agents. They use the authorization code flow with a person’s consent.
Access tokens. They last minutes and can be bound with DPoP (RFC 9449).

Who signs people in is a separate choice

Being the OpenID Connect provider for your applications does not decide where people’s passwords live. SSOGEN accepts four kinds of sign-in source, several at once:

local accounts
a directory (LDAP)
a SAML provider
an OpenID Connect provider such as Microsoft Entra ID, Keycloak, Google Workspace or Okta

Multiple identity providers covers how people are routed. Identity broker covers the pattern where one trust point stands in front of many.

If your applications speak SAML, not OpenID Connect, SSOGEN is also a SAML identity provider. SAML vs OIDC helps you choose per application.

OIDC vs OAuth explains why the provider is also an OAuth authorization server. IdP vs SP gives the vocabulary for the SAML side. For the sign-in features themselves, see SSOGEN authentication.

Questions people ask

What is the OpenID Connect discovery endpoint?

It is a JSON document the provider serves at its issuer address plus /.well-known/openid-configuration. It lists the issuer, authorization endpoint, token endpoint, JWKS address and supported options, so a library can configure itself from one address. In SSOGEN it sits at your SSOGEN address followed by that path.

What is the simplest OIDC provider available?

The simplest one is a provider you already run that supports the authorization code flow with PKCE and publishes a discovery document, because your application then needs only an issuer, a client ID and a redirect URI. Writing your own is rarely simple: discovery alone has seven required fields.

What's the difference between IdP and IAM?

An identity provider authenticates people and issues signed proof of who they are, as tokens or assertions. Identity and access management is the wider practice around it: account lifecycle, permissions, policies and review. An OpenID Connect provider is one part of an IAM program, not the whole of it.

Can I use Cognito as an OIDC provider?

Amazon’s documentation says a Cognito user pool returns ID, access and refresh tokens to your app after an authorization code sign-in, and that the ID token is a standard OIDC token. Your app can therefore treat the user pool as its provider, while the user pool can in turn sign people in through other OIDC providers.

Where to go next

First application. Start with register an OpenID Connect application to connect your first application.
New to the protocol. Read what OpenID Connect is if you are new to the protocol.
Upstream sign-in. To add an upstream provider for sign-in, see Add an OpenID Connect identity provider.

Sources, all read 2026-10-11: OpenID Connect Core 1.0; OpenID Connect Discovery 1.0; RFC 9700, OAuth 2.0 security best current practice; RFC 6749, OAuth 2.0; Amazon Cognito, OIDC user pool IdP authentication flow; the vendor pages linked under the comparison table.