SSO not working

Two distinct authentication paths exist in Observer. The console uses Observer's hosted authentication for operators. Customer-scoped pages verify JWTs that customers' identity providers issue. The two paths fail for different reasons; this page covers both.

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). If it is set to anything else, the JWT header is ignored.

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 access config specifies which JWT claim resolves to a customer (typically sub, customer_id, or a custom claim). The token must carry that claim, and the value must match a customer in the organisation's list AND that customer must be bound 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 with the value the JWT carries.
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 403.

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 > Members > Invite. 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. Provider availability is determined by the cloud's configuration; if the social button the operator expects is missing, the provider is not enabled on this deployment. Contact the cloud operator.