Loading

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.