SSO not working

Three distinct authentication paths exist in Observer. Sign-in protected pages let viewers sign in with Google, Microsoft, or your own identity provider. Customer-scoped pages verify JWTs that customers’ identity providers issue. The console uses Observer’s hosted authentication for operators. Each path fails for different reasons; this page covers all three.

​

Sign-in protected pages: viewers cannot get in

A viewer signs in on the page’s sign-in screen and is turned away, or the sign-in does not complete.

​

Step 1: read the message on the sign-in screen

The sign-in screen names the problem: the email is not on the list, the email is not verified, the person is not in the required group, the sign-in expired or was cancelled, or the provider could not be reached. Match it against the troubleshooting table.

​

Step 2: check the allowed domains and emails

Open the page’s Access settings. Domains match exactly: acme.com does not include eu.acme.com. Addresses on public email providers such as gmail.com must be listed one by one under Allowed emails.

​

Step 3: check your own identity provider

If the viewer used your own identity provider (OIDC):

• Click Test next to Issuer URL to check that Observer can read the provider’s OpenID configuration.
• Confirm the app in your provider lists the Redirect URI shown in Access exactly.
• If the provider leaves out email_verified (Entra ID does), turn on Trust emails that are not marked verified or Let in everyone this provider signs in.
• If Required group is set, confirm the provider sends a groups claim in the ID token and that the value matches.

See Use your own identity provider for provider-specific setup.

​

Customer-scoped pages: JWT verification fails

A customer reaches a customer-scoped page and is denied access even with what they believe is a valid token. Walk:

​

Step 1: confirm the page is in customer-scoped mode

Open the page’s Access tab. The mode must be Customer-scoped (JWT + grant). If it is set to anything else, the customer check does not apply.

​

Step 2: confirm the issuer keys match

The page’s access config holds either a static public key or a JWKS endpoint. The token must be signed by a key the page can verify.

• Static keys: confirm the key the customer’s IdP is using matches the value pasted into the access config. Re-paste from the IdP on a fresh copy.
• JWKS endpoint: confirm the URL is reachable from Observer Cloud and returns valid JWKS JSON. Cache invalidation can cause stale keys; the configured cache TTL determines refresh frequency.

​

Step 3: confirm the claim mapping

The token’s sub claim must equal a customer’s external ID, and that customer must have access to this page. A token whose claim does not resolve to a bound customer returns 403 even when the signature is valid. Open Customers and verify both:

1. A customer record exists whose external ID equals the token’s sub.
2. That customer is on the page’s customer-binding list.

​

Step 4: confirm the token has not expired

The exp claim in the JWT is enforced. Tokens past expiry are rejected. The customer’s IdP integration is responsible for issuing fresh tokens.

​

Step 5: confirm the audience and issuer

If the access config sets audience or issuer constraints, the token must carry matching aud and iss claims. A token issued for a different audience returns 401.

​

Console SSO: operators cannot sign in

Observer Cloud’s console authentication is hosted. If an operator cannot sign in:

​

Step 1: confirm the email and organisation

The operator must be a member of the organisation. Sign-in fails silently in some browsers if the email matches no account or if the account exists but has no organisation membership. The organisation owner can re-invite the operator from Settings > Organization, then invite them under Invite a teammate. The invitation arrives by email; following the link binds the account to the organisation.

​

Step 2: confirm the email provider is reachable

If invitations do not arrive:

1. Check spam folders. First-time invitations from a new domain often filter aggressively.
2. Confirm the recipient’s email provider accepts mail from Observer’s sender domain. Corporate gateways occasionally block transactional senders by default.
3. Resend the invitation; each invitation has a distinct confirmation token.

​

Step 3: confirm MFA is configured

If the operator authenticates but is rejected at the MFA step:

1. Confirm the MFA enrolment is bound to the same account they are signing in to.
2. If a recovery code was used, advise the operator to re-enrol their second factor immediately; the recovery code only grants one-time access.

​

Step 4: SAML or social provider integrations

Observer’s hosted authentication supports email + password and a configurable set of social providers. If a sign-in option you expect is missing, contact Observer support.