Turning It On

Enabling the provider is quick. The things worth settling first are the ones that are awkward to change once an application depends on them.

Where to find it

Architect Panel → Integration & Connections:

• OpenID Connect Provider — the console — clients, scopes, keys and the log

Architect Panel → Security:

• Certificates — signing material

Architect Panel → Configuration:

• Site Settings — the site address clients will be pointed at

Your address is your identity

To a connected application, you are a URL. It is baked into every client's configuration and into the tokens you issue.

So settle your domain before onboarding anyone. Moving afterwards means reconfiguring every client — and until they are all updated, tokens you issue will not be accepted.

Signing keys

Tokens are signed so a client can verify they came from you and were not altered. Clients fetch your public keys automatically, so rotation does not require telling anybody — provided you rotate properly, publishing the new key alongside the old until tokens signed with the old one have expired.

Removing a key immediately invalidates every token it signed, which is a way of logging everybody out at once. That is occasionally what you want and rarely what you intended.

Discovery does the explaining

The provider publishes a discovery document describing its endpoints and capabilities, and most client libraries read it and configure themselves. In practice, onboarding an integrator is usually: here is our discovery URL, here is your client id and secret.

Point people at it rather than writing your own integration notes — it cannot go stale.

Sort out the boring things first

Clients see your name and, if you set them, your logo, privacy policy and terms. These appear on the consent screen, which is a page your members will look at while deciding whether to trust the connection.

An unbranded consent screen asking somebody to share their profile with an application looks exactly like a phishing page. Fill them in before the first real user sees one.

Decide your default posture

Before the first client, decide what a typical one gets: which scopes, which grant types, what token lifetimes. Having a house standard means each new client is a small decision rather than a fresh argument, and it stops the first integrator's preferences becoming your defaults by accident.

Test with something disposable

Configure a throwaway client and complete a sign-in yourself before onboarding a real application. It confirms the address, the keys, the consent screen and the token contents in one exercise, and it is much easier to change anything while nothing depends on it.

Worked example

An organisation settles its domain, uploads a logo, sets links to its privacy policy and terms, and configures a test client pointing at a local application. Signing in shows a branded consent screen naming the application and the information it wants. Only then is the agency given a discovery URL and credentials.

Recommendations

• Settle your domain first — it is your identity to every client.
• Fill in name, logo and policy links before anybody sees a consent screen.
• Agree a house standard for scopes and lifetimes.
• Prove it with a disposable client.