Articles on: Schools & enterprise plans

Troubleshoot OpenID Connect (OIDC) sign-in

Troubleshoot OpenID Connect (OIDC) sign-in


If members can't sign in through your organization's OpenID Connect (OIDC) connection, this guide shows you where SimplyPrint records what went wrong and how to fix the most common errors. The fastest path is almost always the built-in debug panel, which captures the last error and the last claims your identity provider (IdP) sent.


OIDC single sign-on is part of the Enterprise plan and the School plan. Legacy Print Farm subscribers from before 2026-05-15 keep access. Only an account admin with the user registration permission can open and change the settings.


Start with the debug panel

Every failed sign-in is recorded against your provider, so you don't have to ask the member for screenshots or guess. To see it:

  1. Open your organization settings and expand User registration & SSO.
  2. Click Configure OIDC single sign-on to open the configuration.
  3. Scroll to the bottom of the modal. You'll find two collapsible debug cards.


The two cards are:

  • Last sign-in error (debug) - the most recent error message from a failed attempt, with a timestamp. This is the single most useful piece of information for fixing a connection.
  • Last received claims (debug) - the latest set of claims your IdP actually sent, so you can confirm whether the email, name and other fields are arriving and what they're named.


Email addresses in the debug panel are masked for privacy (for example a*****@simplyprint.io), so you can troubleshoot safely without exposing full member emails. A successful sign-in automatically clears the last error.


Reproduce the problem safely with Test sign-in

Before and after every change, use Test sign-in instead of asking a real member to try again. It's in the configuration modal under the Test sign-in heading.

  1. Save your settings first (the button is disabled until you do).
  2. Click Test sign-in. A new tab opens and runs the real OIDC flow against your IdP.
  3. Sign in there. SimplyPrint reports back the claims it received and flags any required claims that are missing - but it never logs anyone in or creates an account.


This is the recommended way to verify a connection because it exercises the exact same code path as a real sign-in, surfaces the same errors, and is completely safe to repeat.


Common errors and how to fix them

Match the message in the Last sign-in error card (or the failure you see during Test sign-in) to the rows below.


Error you see

What it means

How to fix it

id_token issuer mismatch: expected ..., got ...

The issuer URL you saved doesn't match what your IdP actually sends.

Correct the Issuer URL. On the Microsoft Entra tab, fix the Tenant ID (the issuer is built as https://login.microsoftonline.com/{tenantId}/v2.0). Then click Check to confirm discovery resolves.

Could not validate the discovery document (shown on Check)

SimplyPrint couldn't read /.well-known/openid-configuration at that issuer.

Re-check the issuer URL for typos. If your provider doesn't publish a discovery document, open Advanced and fill in the endpoint overrides manually.

Token exchange failed: ...

Usually a wrong or expired client secret, or a client ID that doesn't match the IdP app.

Re-enter the Client secret (it shows Unchanged once saved, so type a fresh one to replace it) and confirm the Client ID. Generate a new secret at the IdP if needed.

redirect_uri / reply URL error shown at the IdP before returning

The redirect URI registered at your IdP doesn't exactly match SimplyPrint's.

Copy the exact Redirect URI shown under "What you need from us" in the modal and register that exact value at your IdP. It must match character for character.

id_token nonce is missing or does not match, id_token was issued in the future, id_token validation failed

A one-off nonce, clock-skew or token timing problem, often a stale browser tab.

Have the member close the tab and start a fresh sign-in. If it persists, check that your IdP server clock is accurate.

id_token signed with a key unknown to the provider's JWKS / id_token uses a disallowed signing algorithm

The signing key or algorithm doesn't match the issuer's published keys.

Confirm the issuer URL points at the same tenant/app that signs the tokens. Use a standard algorithm (RS256); SimplyPrint rejects none and HMAC algorithms by design.

The identity provider did not return a sub claim / Mapped claims missing from id_token: ...

A claim you mapped (or a required one) isn't in the token.

Check Last received claims to see what arrived. Adjust your Claim mappings, or add the matching scope (for example profile or email) under Scopes so the IdP includes it.

Account couldn't be created: "Your identity provider did not confirm your email address..."

A brand-new member's email isn't trusted, so just-in-time account creation was blocked.

See the next section.

Email domain '...' is not in the allowed list

The member's email domain isn't in your allowed-domains restriction.

Open Advanced and add their domain to Allowed email domains, or clear the field to allow any domain.


"A new account could not be created" (email not verified)

When a member signs in for the very first time, SimplyPrint only auto-creates their account if their email is trustworthy. If it isn't, the member sees a message asking them to contact their administrator, and the debug panel records something like JIT provisioning refused: email_verified missing/false and the email domain is not DNS-verified.


An email is considered trustworthy when any one of these is true:

  • The IdP marked the email as verified (sends email_verified: true).
  • The email's domain is one your account has verified by DNS.
  • The admin turned off Require verified email in Advanced.


Microsoft Entra ID does not send an email-verified signal at all, so for Entra connections the correct fix is to verify your email domain (recommended) or turn off Require verified email. The same applies to any provider that doesn't assert verified emails. See verifying your email domains for the DNS step.


"Email domain is not allowed"

If you've set Allowed email domains under Advanced, only members whose email is on one of those domains can sign in. A blocked attempt records Email domain '...' is not in the allowed list. For Google Workspace, the same restriction also checks the workspace's hd (hosted domain) claim.


To fix it, either add the missing domain to the comma-separated list, or clear the field entirely to allow any domain. Remember this is a hard gate that's separate from just-in-time account creation - a member can be on a verified domain and still be blocked here if their exact email domain isn't listed.


When a claim is missing or named differently

If sign-in fails because the email, first name, last name or group is missing, the problem is almost always a claim-mapping or scope mismatch:

  1. Run Test sign-in (or check Last received claims) to see exactly which claims your IdP sends and what they're called.
  2. In Claim mappings, point each SimplyPrint user field at the claim name your provider actually uses. Defaults are email to email, given_name to first name, and family_name to last name; Okta, Keycloak and Authentik also map groups to user groups.
  3. If a claim isn't arriving at all, add the scope that releases it under Scopes (the default is openid profile email). For Okta group mapping, add the groups scope.


Use the Apply defaults button on the relevant provider tab to fill in the common claim names for that provider, then adjust from there. For how group-to-user-group mapping works, the SAML group mapping guide explains the same concept.


Sign-in works but logout doesn't end the IdP session

RP-initiated logout (signing the member out of the IdP as well as SimplyPrint) only works when your provider advertises a logout endpoint in its discovery document. Google Workspace does not, so for Google connections logout only ends the SimplyPrint session - the member stays signed in to Google. This is expected behavior, not a misconfiguration.


Still stuck after the debug panel

If the debug panel shows a clean sign-in but the member still can't get in, the issue is usually account-level rather than the connection itself:

  • The member may already have an email/password account they need to link first. See linking your existing account to SSO.
  • Confirm they're using the right organization login entry point. See signing in with SSO.
  • Remember an account runs one SSO method at a time. If you recently switched from SAML to OIDC, make sure OIDC is the active method.



Updated on: 13/06/2026

Was this article helpful?

Share your feedback

Cancel

Thank you!