Skip to main content

Single Sign-On (OIDC)

Once an organisation grows past a handful of users, every login becomes a friction point. New hires need accounts. Departing employees need them disabled. Passwords get reset. People forget which platforms they have accounts on. Big organisations solve this by centralising identity in one place — usually Okta, Microsoft Entra (Azure AD), Google Workspace, or another identity provider (IdP).

Single Sign-On (SSO) is the protocol that lets a user with a corporate identity sign in to Dashify without a separate Dashify password — and lets the IT team manage their access in one place.

The metaphor​

Think of an SSO-enabled organisation as a country with a single ID system. The country issues you a passport. Every airport, every hotel, every car rental in the country accepts the passport. They do not each maintain their own database of who is allowed to fly or drive — they trust the issuing authority.

Dashify, with SSO enabled for your tenant, is one of those airports. The passport is your corporate identity. The issuing authority is your IdP.

What OIDC is​

There are two SSO protocols you will hear about: SAML (older, XML-based, common in enterprise) and OIDC (newer, JSON-based, built on OAuth 2.0, common everywhere modern). Dashify uses OIDC.

OIDC stands for OpenID Connect. It is an identity layer built on top of OAuth 2.0. The big idea: when a user wants to sign in, the application redirects them to their IdP. The IdP authenticates them however it likes (corporate password, multi-factor, hardware key, whatever the company has set up). On success, the IdP redirects the user back to the application along with a signed token saying "this is them."

The application verifies the token, creates a local session, and the user is signed in.

Per-tenant configuration​

Every Dashify tenant can configure its own IdP. The Acme org connects to Acme's Okta tenant. The Globex org connects to Globex's Microsoft Entra. Two organisations using Dashify might use entirely different identity stacks.

The Org Admin sets up SSO for their tenant from /organization/sso. They paste in the four values the IdP gives them:

  • Issuer URL — the IdP's identity. Example: https://acme.okta.com/oauth2/default.
  • Client ID — the application id the IdP gave Dashify when the integration was registered.
  • Client Secret — the corresponding secret.
  • Allowed email domains — acme.com, acme.co.uk — only emails on these domains will be routed through this IdP.

Dashify validates the configuration, displays the callback URL the admin needs to configure on the IdP side (https://your-dashify.example.com/auth/sso/callback), and offers a "test connection" button.

Once enabled, users with email addresses in the allowed domains see a "Continue with SSO" button on the login page. Users outside the allowed domains continue to use password + 2FA — useful for service accounts or contractors who do not have corporate identities.

PKCE — the security upgrade for public clients​

The login flow above includes "PKCE" in a few places. PKCE (pronounced "pixie") stands for Proof Key for Code Exchange. It is a security upgrade to OAuth 2.0 that closes a class of attacks where a malicious app intercepts the authorization code on the way back from the IdP.

Without PKCE, anyone who steals the authorization code from the redirect URL can exchange it for a token. With PKCE, the original requester generated a random secret (the code verifier) and only sent its hash (the code challenge) to the IdP. The IdP returns a code that can only be exchanged when the original verifier is presented.

Dashify uses PKCE on every SSO flow. The library openid-client handles it automatically.

State and nonce — replay protection​

Two more cryptographic randoms protect the flow.

State is a random string the API generates and stores in a cookie before redirecting to the IdP. When the IdP redirects back, the state must match. This stops an attacker from triggering an SSO flow on a victim's behalf.

Nonce is a random string included in the original request and required to appear in the returned ID token. This stops an attacker from replaying an old ID token.

Both are mandatory in Dashify's implementation. Both are checked before the API will trust anything in the returned token.

Just-in-time provisioning​

When a user signs in via SSO for the first time, they may not yet exist in Dashify's user collection. JIT (just-in-time) provisioning solves this: the API auto-creates the user record from the claims in the ID token (email, name, optionally a role).

The Org Admin can configure JIT behaviour:

  • Off — Users must be pre-created (perhaps via SCIM, the next page) before they can sign in.
  • On, default role — New users get a default role like "User."
  • On, role from claim — Map an IdP group/role claim to a Dashify role. Members of the IdP group dashify-admins become Org Admins.

Combined with SCIM, this gives organisations a fully automated user lifecycle: a new hire is added to the directory, propagates to Dashify automatically (SCIM), can sign in immediately (SSO), and gets the right role from day one (claim mapping).

Logout​

When the user signs out of Dashify, by default the local session is terminated and the user is sent to the login page. They are not automatically signed out of the IdP — that would log them out of every other corporate app too.

Some organisations require single logout (SLO), where signing out of one app signs out of all. Dashify supports the OIDC end_session_endpoint if the IdP advertises it; the Org Admin can enable a "log me out everywhere" option.

Security gotchas avoided​

A few traps in OIDC implementations that Dashify avoids:

  • Open redirect. The post-login redirect target is validated against an allowlist; an attacker cannot use SSO as a way to redirect users to arbitrary sites.
  • Mixed-domain bind. A user authenticated via SSO is bound to the tenant whose SSO config matches their email domain — they cannot accidentally end up signed into a different tenant's account.
  • Trusting the userinfo endpoint instead of the ID token. The userinfo endpoint can be spoofed in some flows; the ID token signature is the authoritative source.
  • Skipping signature verification. Every ID token signature is verified against the IdP's published keys (fetched from the JWKS endpoint, cached briefly).

Key takeaways​

  • SSO lets users sign in to Dashify with their corporate identity, no Dashify password needed.
  • Dashify uses OIDC with PKCE, state, and nonce for replay protection.
  • Each tenant configures its own IdP — Acme uses Okta, Globex uses Microsoft Entra, etc.
  • Just-in-time provisioning auto-creates users on first SSO login.
  • Combined with SCIM (next page), the user lifecycle is fully automated.