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.