Skip to main content
The Google / Microsoft sign-in access mode keeps a status page private and lets people in by signing in. A visitor picks a provider, signs in, and Observer checks their verified email against the people and domains you allow. Everyone else is turned away. Use it for internal status pages, or pages shared with a few partner companies, when you want each viewer to use their own account instead of a shared password.

​
Choose an access mode

​
Plans

  • Sign in with Google and Microsoft: Business and Enterprise plans.
  • Sign in with your own identity provider (OIDC): Enterprise plan.

​
Set up Google and Microsoft sign-in

1

Switch the page to sign-in mode

Open the page in the console, then Access. Under Who can view this page, choose Google / Microsoft sign-in.
2

Pick the sign-in providers

Under Sign-in providers, tick the options visitors can use:
  • Google: Google accounts and Google Workspace.
  • Microsoft: Microsoft 365 and Entra ID work accounts, and personal Microsoft accounts.
  • Your identity provider (OIDC): see Use your own identity provider.
3

List who can view the page

Fill in one or both lists, one entry per line:
  • Allowed domains: anyone whose verified email is on the domain can view the page, for example acme.com. Matching is exact: acme.com does not include eu.acme.com, so list each domain you need. Up to 50 domains.
  • Allowed emails: individual people, such as contractors or anyone with an address on a public email provider. Up to 500 addresses.
Public email domains such as gmail.com, outlook.com, yahoo.com, icloud.com, and proton.me are rejected under Allowed domains, because they would let anyone in. Add those people under Allowed emails instead.
4

Save

Save the page. Visitors who are not signed in now land on the sign-in screen.

​
Verified emails only

Observer only accepts an email address the provider has confirmed:
  • Google: the account’s email must be marked verified.
  • Microsoft: work and school accounts are accepted only when Microsoft confirms the email’s domain is verified for that organization. Personal Microsoft accounts are accepted.
A visitor whose email is not confirmed sees an error and cannot open the page.

​
Use your own identity provider

With the Your identity provider (OIDC) option, visitors sign in through your company’s identity provider, such as Okta, Microsoft Entra ID, Auth0, Keycloak, Google Workspace, or any other OpenID Connect provider. It can be used on its own or next to the Google and Microsoft buttons.

​
Requirements

Your provider must:
  • Publish its OpenID configuration at <issuer>/.well-known/openid-configuration on a public https:// address.
  • Sign ID tokens with an asymmetric algorithm (for example RS256 or ES256). Providers that only sign with a shared secret are not accepted.
  • Accept a client secret at its token endpoint.
Observer requests the openid email profile scopes and uses the authorization code flow with PKCE.

​
Connect the provider

1

Copy the redirect URI

In Access, tick Your identity provider (OIDC). The Identity provider section shows a Redirect URI:
Copy it. The redirect URI is the same for every page, including pages on a custom domain.
2

Create an app in your identity provider

Create a web application that uses OpenID Connect with the authorization code flow, and add the redirect URI to it. See Provider notes for the exact steps in common providers.
3

Enter the provider details

Back in Access, fill in:
  • Issuer URL: your provider’s issuer, for example https://acme.okta.com. Click Test to check that Observer can read the provider’s OpenID configuration.
  • Client ID: from the app you created.
  • Client secret: from the app you created. The secret is stored encrypted and is never shown again. To keep the saved secret when you edit other settings, leave the field blank.
  • Button name (optional): the name on the sign-in button, for example Okta to show Continue with Okta.
4

Decide who gets in

Choose how Observer admits people who sign in through your provider:
  • Let in everyone this provider signs in: skips Allowed domains and Allowed emails for this provider. Use it when your provider already controls who can use the app, for example through app assignments.
  • Trust emails that are not marked verified: accepts the email claim even when the provider does not mark it verified. Some providers, such as Entra ID, leave out email_verified. Only turn this on for a provider your company controls.
  • Required group (optional): only people whose ID token groups claim contains this value can sign in. Your provider must be set up to send a groups claim in the ID token.
Without Let in everyone this provider signs in, people signing in through your provider must also match Allowed domains or Allowed emails.
5

Save

Save the page. Observer checks the provider’s OpenID configuration again on save and shows an error if it cannot be read.
Changing the Issuer URL or Client ID signs out everyone who signed in through your provider. They sign in again on their next visit.

​
Provider notes

  1. In the Okta admin console, go to Applications > Create App Integration. Choose OIDC - OpenID Connect, then Web Application.
  2. Add the Observer redirect URI under Sign-in redirect URIs.
  3. Assign the people or groups who should see the page.
  4. Copy the Client ID and Client secret into Observer.
  5. Use your Okta domain as the Issuer URL, for example https://acme.okta.com. If you use a custom authorization server, use its issuer instead, for example https://acme.okta.com/oauth2/default.
Okta only signs in people assigned to the app, so Let in everyone this provider signs in is a common choice. To use Required group, add a groups claim to the ID token in the app’s Sign On settings. If your Okta setup leaves out email_verified, turn on Trust emails that are not marked verified.

​
What viewers see

A visitor who is not signed in is sent to the page’s /unlock path. The sign-in screen shows one button per provider you enabled: Continue with Google, Continue with Microsoft, and Continue with your Button name for your own provider. After signing in, the visitor returns to the page they asked for. Sign-in works the same way on a custom domain. Restricted pages are always hidden from search engines. An embed of a sign-in protected page shows a locked notice instead of status.

​
Sessions and removing access

  • A sign-in lasts 12 hours. After that, the visitor signs in again.
  • Removing an email or domain from the lists, or turning a provider off, takes effect on the visitor’s next page load.
  • Changing the Issuer URL or Client ID of your own provider signs out everyone who used it.
  • With Let in everyone this provider signs in, removing someone in your identity provider stops them from signing in again. A session they already have lasts until it expires.
  • To sign out, open /api/page-access/sso/signout on the page’s address.

​
Troubleshooting

These are the errors a visitor can see on the sign-in screen. For other access problems, see SSO not working.