OpenID Connect Provider

Becoming an Identity Provider

Elsewhere the platform consumes identity — you sign in with Microsoft or a SAML provider. This is the opposite: other applications sign their users in with their ActiveManage account.

Where to find it

Architect Panel → Integration & Connections:

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

Architect Panel → Security:

• Authentication Methods — consuming identity, which is the other direction
• Permissions — the groups a client can be restricted to

When you want this

• You run a portal, a mobile app or a satellite system, and its users are already your users.
• A partner has built something for your members and you would rather not create a second set of accounts.
• You want one place to disable somebody, and have that take effect everywhere.

The argument for it

Every additional account store is a set of passwords to protect, a leaver process to remember and a place somebody's access outlives their relationship with you. Being the identity provider collapses those into one.

Disabling an account here signs them out of everything that trusts you — which is the property you actually wanted when you started worrying about a satellite application's account list.

What it is not

It is not a way to give an application access to your data. That is the API, and it is a separate decision with separate credentials. A connected application learns who somebody is; it does not thereby gain the ability to read your datastores.

Keeping that distinction clear saves a lot of confusion when somebody asks for "access" and means one of two quite different things.

What it costs you

You become infrastructure. If your platform is unavailable, nobody can sign in to anything that depends on it — a failure that is now wider than your own application.

That is manageable and worth knowing in advance. It argues for treating this as a production dependency: monitor it, and think about your signing keys and certificates before they expire rather than after.

The pieces

• Clients — the applications allowed to ask.
• Scopes — what a client may learn about the person.
• Grant types — how a client is allowed to obtain a token.
• Lifetimes and keys — how long tokens last and what signs them.
• Logs — what was issued and what was refused.

It is a standard

OpenID Connect is widely implemented, so most application frameworks already have a library. You are configuring something an integrator will recognise rather than explaining a bespoke arrangement — which makes onboarding a partner much easier than it sounds.

Worked example

A membership organisation runs its member records here and a separate events site built by an agency. Rather than the agency holding member passwords, the events site becomes a client. Members sign in with the account they already have, the agency never sees a credential, and a lapsed member loses access to both at once.

Recommendations

• Use it to collapse account stores, which is where the value is.
• Keep it distinct from API access in your own conversations.
• Treat it as production infrastructure once anything depends on it.
• Expect integrators to know the standard — you are not inventing anything.

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.

Connecting an Application

Each application that may sign users in is registered as a client with its own identifier, credentials and rules.

Where to find it

Architect Panel → Integration & Connections:

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

Architect Panel → Security:

• Permissions — groups, which a client can be restricted to

What a client holds

• An identifier and, where appropriate, a secret with its own creation and expiry dates.
• Name, description, logo and links to its site, privacy policy and terms — all shown on the consent screen.
• A type, distinguishing an application that can keep a secret from one that cannot.
• Redirect URIs, post-logout redirects and allowed origins.
• Four grant type switches.
• PKCE required, and a trusted flag.
• Allowed and default scopes.
• Token lifetimes, and optionally allowed groups.

Confidential or public

A server-side application can keep a secret. A single-page application or a mobile app cannot — whatever you give it ships to the user's device and can be extracted.

Set the type honestly. Treating a public client as confidential does not make its secret secret; it just means you believe something untrue about your own security.

Redirect URIs are a security control

They are the exact addresses you will send a user back to after signing in, and they are matched exactly.

This is what stops an attacker starting a sign-in and having the result delivered to them. Never add a wildcard, never add a host you do not control, and remove development addresses before the client goes live — a local address left registered on a production client is a real hole.

The four grant types

• Authorisation code — the normal one. A person signs in and is redirected back. Use this.
• Refresh — lets a client keep a session alive without asking again. Convenient, and it extends how long access survives.
• Client credentials — no user at all; the application acts as itself. Only for machine-to-machine, and note it is not really identity — nobody is being signed in.
• Device — for things with no browser, where a code is entered elsewhere.

Enable only what the application uses. Each is a route to a token, and one nobody needs is surface area for nothing.

Require PKCE

It closes a class of attack where an intercepted authorisation code is exchanged by somebody else. It is mandatory for public clients and harmless for confidential ones.

Turn it on for everything. Modern libraries support it, and an integrator who objects is telling you something about how current their library is.

The trusted flag skips consent

Reasonable for your own first-party applications, where asking a member to consent to sharing their profile with your own portal is noise.

Never set it on a third party's application. The consent screen is the user's only visibility into what is being shared, and removing it on somebody else's behalf is a decision that is not yours to take.

Restrict by group where it fits

A client can be limited to members of particular groups, so signing in succeeds only for people who should use that application. That is cleaner than letting everybody authenticate and having the application decide.

Secrets expire

They carry creation and expiry dates. Diary the renewal — an expired secret breaks the integration completely, on a date you knew in advance.

Worked example

An events site is registered as a confidential client with one exact redirect URI, authorisation code and refresh grants only, PKCE required, not trusted, restricted to the Members group, and a secret expiring in a year with a calendar reminder at ten months.

Recommendations

• Exact redirect URIs only, and remove development ones before go-live.
• Require PKCE everywhere.
• Never mark a third party trusted.
• Diary every secret expiry.

Scopes

A scope is a unit of disclosure. A client may request only what it is allowed, and the user sees what is being asked for.

Where to find it

Architect Panel → Integration & Connections:

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

Architect Panel → Integration & Connections:

• AI Tool Access (MCP) — what the mcp scopes reach
• Agent Access (A2A) — what the a2a scopes reach

The identity scopes

• openid — sign the person in. Required for any sign-in.
• profile — their basic profile.
• email — their e-mail address.
• phone — their phone number.
• groups — their security groups.
• offline_access — stay signed in, by issuing a refresh token.

Groups discloses more than it looks

It tells the application which security groups somebody belongs to — which is your internal structure, and sometimes sensitive in itself. Group names such as "Safeguarding Team" or "Redundancy Consultation" reveal something about the person.

Grant it when an application genuinely needs to make decisions from group membership, not as a matter of routine.

offline_access is a duration decision

It is what lets an application keep somebody signed in for weeks without asking again. Convenient, and it means access persists well beyond the last time they proved who they were. Consider whether that suits the application before enabling it.

The AI scopes are different

Six more exist, and they are not identity at all — they let a connected AI assistant or agent act:

• mcp:read — an AI assistant may read data through the platform's tools.
• mcp:write — adds creating and changing records.
• mcp:admin — reserved for administrative tools.
• a2a:read — another agent may ask this system to carry out read tasks.
• a2a:write — lets another agent delegate work that creates or changes things.
• a2a:admin — reserved.

Scrutinise those much harder

The identity scopes disclose facts about a person. These grant the ability to do things in your system on their behalf, at their permission level.

Read and write are a meaningful step apart, and the admin ones are reserved — nothing today requires them, so there is no reason to grant one now.

Allowed and default

A client's allowed scopes are the most it may ever ask for; its defaults are what it gets without asking. Keep defaults minimal — usually just enough to sign in — and let the client request more when it has a reason the user can see.

Grant the least that works

Start a new client with openid and whatever single scope its purpose requires, and add on evidence. It is far easier to add a scope than to explain why one was granted, and every scope appears on a consent screen your users read.

Review them

Scopes get added during commissioning to make something work and are never taken away. A periodic look at what each client may request — against what it actually does — usually finds one that has more than it needs.

Worked example

An events site is allowed openid, profile and email, with openid and profile as defaults. It requests email at sign-in, which the consent screen shows. It is not allowed groups, because it has no need to know, and none of the AI scopes.

Recommendations

• Minimal defaults — usually just sign-in.
• Treat groups as disclosure of your internal structure.
• Hold the AI scopes to a much higher bar — they grant action, not information.
• Review allowed scopes against what clients actually use.

The Sign-In Flow

Understanding the sequence makes both configuration and troubleshooting much easier, and it is short.

Where to find it

Architect Panel → Integration & Connections:

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

Architect Panel → Activity:

• Activity Log — the sign-in itself

The sequence

1. The user clicks something like "Sign in with your account" on the application.
2. The application sends them to you, naming itself, what it wants, and where to send them back.
3. They sign in here — with whatever authentication you require, including any second factor.
4. They see a consent screen, unless the client is trusted.
5. They are redirected back to the application with a short-lived code.
6. The application exchanges that code for tokens, server to server.
7. It now knows who they are.

Authentication happens here, and that is the point

The application never sees a password, never handles a second factor, and cannot weaken either. Your rules apply to every connected application automatically — enable passkeys and every one of them benefits without being touched.

The code is not the token

Step 5 delivers a short-lived, single-use code through the browser; step 6 exchanges it out of band. This is why an intercepted redirect is not enough on its own, and why PKCE — which binds the exchange to the client that started it — closes the remaining gap.

What the application receives

• An identity token — signed, containing who the user is and which scopes were granted.
• An access token — presented when calling anything that accepts it.
• A refresh token, if offline access was granted.

Signing out is two things

Signing out of the application ends its own session. Signing out of you is separate, and a user who does the first is often still signed in here — so clicking "sign in" again completes instantly and looks like the sign-out failed.

Set post-logout redirects and be clear in the application's wording about which session is ending. This is the single most common user-facing confusion with connected applications.

Common failures, in order of likelihood

• Redirect URI mismatch — the commonest by a distance, and usually a trailing slash, http against https, or a development address. The failure happens before sign-in and is refused deliberately.
• Expired client secret — sign-in appears to work and the token exchange fails.
• Scope not allowed — the client asked for something it may not have.
• Group restriction — the person authenticated correctly and is not permitted to use that application.
• Clock skew — tokens are time-bound, so a badly wrong clock at either end causes rejections that look random.

The log tells you which

Refusals are recorded with a reason. Read that before asking an integrator to change anything — most of the failures above are configuration on one side and are identifiable in seconds.

Worked example

An agency reports sign-in failing on their staging site. The log shows redirect URI mismatches: staging had been added as https://staging.example.org/callback and the application was sending https://staging.example.org/callback/. One trailing slash, thirty seconds to fix once the log was read.

Recommendations

• Read the log first — it names the reason.
• Check redirect URIs character by character.
• Explain the two sign-outs in the application's wording.
• Keep clocks synchronised at both ends.

Lifetimes, Keys and Revocation

Tokens expire, keys rotate, and access is revoked. These are the settings that decide how quickly a decision here takes effect out there.

Where to find it

Architect Panel → Integration & Connections:

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

Architect Panel → Security:

• Disabled User Accounts — the fastest way to cut somebody off
• Certificates — signing material

Four lifetimes

• Access token — how long a token is accepted. Short.
• Identity token — how long the identity assertion is valid.
• Refresh idle — how long a refresh token survives without being used.
• Refresh absolute — the hard ceiling, however often it is used.

Short access, bounded refresh

Keep access tokens short — minutes to an hour. Their length is the window in which a leaked one is useful, and a refresh token exists precisely so a short access token is not inconvenient.

Then bound the refresh. The idle timeout drops abandoned sessions; the absolute one forces a fresh sign-in eventually regardless. Without an absolute ceiling, a refresh token used weekly lasts for ever, and "signed in since 2024" is not a session anybody decided to grant.

Rotating signing keys

Clients fetch your public keys automatically, so rotation needs no coordination — if you do it in the right order:

1. Publish the new key alongside the old.
2. Start signing with the new one.
3. Wait for every token signed with the old key to expire.
4. Remove the old key.

Removing it at step 2 invalidates every outstanding token at once. That is a way to sign everybody out immediately — occasionally useful, rarely intended.

What revocation actually does

The important thing to be clear about: revoking a token stops future use of it. It does not reach into an application and end a session that application is maintaining from an access token it already holds.

So the practical answer to "cut this person off now" is:

1. Disable the account. This is the effective control — nothing further can be issued, and refresh stops working.
2. Revoke their outstanding tokens.
3. Accept a short residual window equal to your access token lifetime.

That window is exactly why access tokens should be short. If yours are a day long, "immediately" means tomorrow.

Removing a client

Disabling a client stops it obtaining anything new. Users who had signed in may continue until their tokens lapse, for the same reason.

Test revocation before you need it

Disable a test account, then see how long it takes for a connected application to notice. That number is your real answer to "how quickly can we cut somebody off", and it is better known in advance than discovered during an incident.

Worked example

An organisation sets access tokens to fifteen minutes, refresh idle to fourteen days and refresh absolute to ninety. When a member's access is withdrawn, their account is disabled; the connected events site stops working within fifteen minutes without anybody contacting the agency.

Recommendations

• Short access tokens — they define your revocation window.
• Always set an absolute refresh ceiling.
• Rotate keys by overlapping, never by replacing.
• Disable the account to cut someone off, and test how long it takes.

Monitoring and Troubleshooting

The provider records what it issued and what it refused. Both matter, and the refusals matter more.

Where to find it

Architect Panel → Integration & Connections:

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

Architect Panel → Integration & Connections:

• OAuth Tokens — tokens currently issued

Architect Panel → Activity:

• Error Log — technical failures around the provider

Architect Panel → Security:

• Blocked IP Addresses — where repeated abuse surfaces

What is recorded

• A log of provider activity.
• A separate record of failures.
• Issued tokens and refresh tokens.
• Outstanding authorisation codes and device codes.
• Grants — what each user has consented to for each client.

Failures are kept separately for a reason

A successful sign-in is routine. A refusal is either a misconfiguration or somebody trying something, and separating them means you can look at the interesting set without filtering.

Look at failures first, always. They carry the reason, and most integration problems are one repeated reason.

Reading a run of refusals

• All one client, all one reason, starting at a moment — something changed at their end. A deployment, a secret rotation, a new environment.
• One user, repeatedly — usually a group restriction, and they cannot tell why they are being turned away.
• Many clients at once — something changed here. Keys, address, or an expired certificate.
• Unfamiliar client identifiers — somebody probing. Not dangerous on its own, since an unregistered client cannot obtain anything, but worth noticing.

Grants are a user-facing record

They record what each person consented to for each client. That is the answer to "which applications can see my information", which members do ask — and being able to answer it, and remove a grant, is part of running this properly.

Watch outstanding tokens

A client accumulating far more than its user base suggests it is not reusing tokens properly — requesting a new one per request rather than holding one until it expires. It works, and it is wasteful and makes your logs much harder to read.

Working with an integrator

Ask for the exact time of a failure and the client identifier. With those you can find the specific refusal and its reason, which turns a vague report into a one-line answer.

Send them the reason, not a screenshot of the log — it may contain other clients' activity.

Check after your own changes

Anything touching keys, certificates, your address or authentication affects every connected application. Look at the failure log after such a change rather than waiting to be told, because integrators often assume a problem is their own and spend a day on it first.

Worked example

A partner reports intermittent sign-in failures. The failure record shows refusals clustered in one minute every hour, all from their client, all clock-skew related. Their scheduled task was running on a host whose time had drifted by several minutes. Nothing on either side needed reconfiguring once the cause was named.

Recommendations

• Read failures before anything else.
• Ask for a timestamp and client id when a partner reports a problem.
• Check the failure log after your own changes.
• Be able to answer "which applications can see my data" from the grants.