> ## 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.
# Sign-in protected pages
> Let people open a private status page by signing in with Google, Microsoft, or your own identity provider.
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
| Mode | Who gets in | Choose it when |
| - | - | - |
| [Password](/docs/guides/password-protected-pages) | Anyone with the shared password. | You need a quick gate and can share a secret. |
| IP allowlist | Visitors connecting from listed IP ranges. | Viewers are always on your office network or VPN. |
| **Google / Microsoft sign-in** | People whose verified email or email domain you allow. | Viewers have Google, Microsoft, or company accounts and you want per-person access you can revoke. |
| [JWT (Bearer token)](/docs/guides/jwt-scoped-access) | Requests carrying a token signed by your key. | Your own app issues tokens and links viewers to the page. |
| [Customer-scoped](/docs/guides/customer-scoped-pages) | Holders of a token for a customer with access to the page. | Each customer should see their own view of the page. |
## 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
Open the page in the console, then **Access**. Under **Who can view
this page**, choose **Google / Microsoft sign-in**.
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](#use-your-own-identity-provider).
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.
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
`/.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
In **Access**, tick **Your identity provider (OIDC)**. The **Identity
provider** section shows a **Redirect URI**:
```
https://use.observer/api/page-access/sso/callback
```
Copy it. The redirect URI is the same for every page, including pages
on a [custom domain](/docs/guides/custom-domain).
Create a web application that uses OpenID Connect with the
authorization code flow, and add the redirect URI to it. See
[Provider notes](#provider-notes) for the exact steps in common
providers.
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**.
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**.
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**.
1. In the Microsoft Entra admin center, go to **App registrations** >
**New registration**. Under supported account types, choose
accounts in this organizational directory only (single tenant).
2. Add the Observer redirect URI with the **Web** platform.
3. Under **Certificates & secrets**, create a client secret and copy
its value.
4. Under **Token configuration**, add the optional claim `email` for
the **ID** token type.
5. Copy the **Application (client) ID** into **Client ID**.
6. Set **Issuer URL** to
`https://login.microsoftonline.com//v2.0`, using your
**Directory (tenant) ID**.
Entra ID does not send `email_verified`, so turn on either **Let in
everyone this provider signs in** or **Trust emails that are not
marked verified**. Otherwise sign-in fails with an unverified email
error.
To use **Required group**, add a groups claim under **Token
configuration**. Entra ID sends group object IDs by default, so enter
the group's **Object ID** as the required group.
1. In the Google Cloud console, set the **OAuth consent screen** user
type to **Internal**. This limits sign-in to accounts in your
Workspace.
2. Under **Credentials**, create an **OAuth client ID** of type **Web
application**, and add the Observer redirect URI under
**Authorized redirect URIs**.
3. Copy the client ID and client secret into Observer.
4. Set **Issuer URL** to `https://accounts.google.com`.
With an internal consent screen, **Let in everyone this provider
signs in** admits everyone in your Workspace. Google does not send a
`groups` claim, so **Required group** does not work with Google.
1. In the Auth0 dashboard, go to **Applications** > **Create
Application** and choose **Regular Web Applications**.
2. Add the Observer redirect URI under **Allowed Callback URLs**.
3. Copy the **Client ID** and **Client Secret** into Observer.
4. Set **Issuer URL** to your tenant domain, for example
`https://acme.us.auth0.com/`. The trailing slash is fine.
Auth0 does not send a `groups` claim by default. To use **Required
group**, add one to the ID token with an Action.
## 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](/docs/guides/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.
| Message | Cause | Fix |
| - | - | - |
| *email* doesn't have access to this page. | The verified email is not under **Allowed emails** and its domain is not under **Allowed domains**. | Add the address or the exact domain. Remember that subdomains need their own entry. |
| Your sign-in provider didn't confirm this email address. | The provider did not mark the email verified. With Microsoft work accounts, the email's domain is not verified for that organization. | The person uses an account with a verified email. For your own provider, turn on **Trust emails that are not marked verified** or **Let in everyone this provider signs in**. |
| The sign-in took too long or was interrupted. | The visitor took too long, opened the sign-in in another browser, or the identity provider settings changed during sign-in. | Try again from the sign-in screen. |
| Sign-in was cancelled. | The visitor cancelled, or the provider refused the request. | Try again. For your own provider, check that the redirect URI is registered exactly and the person is assigned to the app. |
| Your account isn't in the group that can view this page. | The ID token's `groups` claim does not contain the **Required group**. | Add the person to the group, and check that the provider sends a `groups` claim in the ID token. |
| Couldn't reach the sign-in provider. | Observer could not reach your identity provider. | Try again in a minute. Click **Test** in **Access** to check the issuer. |
| That sign-in option isn't available for this page. | The provider was turned off on the page. | Use another provider shown on the sign-in screen. |
| Couldn't sign you in. | The token exchange or ID token check failed. | Check the **Client ID** and **Client secret**, and that the issuer matches the provider's configuration. |
For other access problems, see
[SSO not working](/docs/troubleshooting/sso-not-working).
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.