> ## Documentation Index > Fetch the complete documentation index at: https://docs.use.observer/llms.txt > Use this file to discover all available pages before exploring further. # SSO not working > Diagnose sign-in on protected status pages, JWT-based access on customer-scoped pages, and console sign-in. 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](https://docs.use.observer/docs/guides/sign-in-protected-pages.md#troubleshooting). ### 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](https://docs.use.observer/docs/guides/sign-in-protected-pages.md#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. > [!NOTE] > > **Test path** > > The fastest verification is to decode the customer's failing JWT > at [jwt.io](https://jwt.io), inspect the claims, and compare > against the page's access config field-by-field. The JWT itself > is the signed source of truth for what the customer claims. ## 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. > [!WARNING] > > **Privileged users locked out** > > If every administrator on an organisation has lost access (for > example, MFA hardware reset across a team), contact Observer > support. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.