How Do You Put Google or Microsoft Sign-In in Front of a Static HTML Page?

Display is our product. We checked the vendor facts on each vendor's own pages on 16 October 2026. Prices and plan limits change. Check the linked page before you decide.

The five options side by side

The table assumes 50 readers who all have Google or Microsoft accounts.

Your cost can increase in each option when the files, traffic or users grow. Read each vendor's page for those limits.

Option 1: Cloudflare Access in front of Cloudflare Pages

1. Open the Cloudflare dashboard. Go to Zero Trust, Integrations, Identity providers. Add Google. For Google, you create an OAuth client of type Web application. Set the authorized origin to https://<your-team-name>.cloudflareaccess.com. Set the redirect URI to https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback. Paste the client ID and secret into Cloudflare.
2. Go to Access controls, Applications. Select Create new application, then Self-hosted and private. Add the public hostname of your site. The domain must be active on Cloudflare.
3. Add an Allow policy. Use the selector Emails ending in with your company domain, or list single addresses. Cloudflare denies all other people by default.
4. Choose the identity providers that the application accepts.
5. In your Pages project, select Enable access policy under Settings, General. This setting protects preview deployments only. It does not protect your *.pages.dev domain or your custom domain. Use the Access application from step 2 for those domains.

The Cloudflare Access product page lists the Free plan with a limit of 50 users, and $7 per user a month after that, paid annually.

Use this option if you already use Cloudflare Zero Trust. Read our longer Cloudflare Access comparison.

Option 2: oauth2-proxy in front of your own server

oauth2-proxy is an open-source reverse proxy and a CNCF Sandbox project. It does the OAuth sign-in and sends allowed requests to your files. A minimal command:

oauth2-proxy \
  --provider=google \
  --client-id="$CLIENT_ID" \
  --client-secret="$CLIENT_SECRET" \
  --cookie-secret="$COOKIE_SECRET" \
  --email-domain="example.com" \
  --redirect-url="https://docs.example.com/oauth2/callback" \
  --upstream="file:///srv/reports/#/" \
  --http-address="0.0.0.0:4180"

Put TLS in front of it with your web server or load balancer. The project's configuration overview documents all eight flags. A file:// upstream serves static files, and the part after # sets the public path. We did not run this command. Test it before you use it.

For Google, you create an OAuth client in the Google Cloud console. Set the authorized origin to your domain and the redirect to the callback path. The project also has a Microsoft Entra ID provider. Read its provider page for the flags.

You maintain the server, the proxy version, the TLS certificates and the secrets.

Option 3: Azure Static Web Apps with Microsoft Entra ID

Azure Static Web Apps has built-in sign-in for Microsoft Entra ID and GitHub on all plans. Two limits are important for a company page:

• The built-in Entra ID provider lets any Microsoft account sign in. To limit sign-in to one directory, you register a custom Entra ID provider and put your tenant ID in openIdIssuer. Microsoft says that custom authentication is available only on the Standard plan.
• Google also needs a custom registration, so it also needs Standard.

A route rule protects the pages. Put this in staticwebapp.config.json:

{
  "routes": [
    { "route": "/*", "allowedRoles": ["authenticated"] }
  ],
  "responseOverrides": {
    "401": { "redirect": "/.auth/login/aad", "statusCode": 302 }
  }
}

This is the "restrict access to the entire application" pattern from Microsoft's configuration documentation. For custom roles, you create invitations in the Azure portal. An invitation link lasts at most 168 hours (seven days).

The Azure pricing page did not show the Standard price on 16 October 2026. Azure's retail price list gives $9 per app a month in most regions. Read our longer Azure Static Web Apps comparison.

Option 4: S3 with CloudFront and Cognito

Amazon S3 holds the files. CloudFront serves them. Amazon Cognito signs readers in. Cognito does not protect the files by itself. You add code in front of CloudFront that checks the Cognito token on each request, for example in a CloudFront function or a Lambda@Edge function.

1. Create a Cognito user pool and an app client.
2. Add Google as a social provider and Microsoft Entra ID as an OIDC provider.
3. Put the files in a private S3 bucket behind a CloudFront distribution.
4. Write and deploy the check that sends readers without a valid token to the Cognito sign-in page.

The Cognito pricing page lists 10,000 free monthly active users for direct sign-in on the Lite and Essentials tiers. Direct sign-in includes social identity providers. For SAML or OIDC federated sign-in, it lists 50 free users, then $0.015 for each additional user. The CloudFront pricing page lists a Free flat-rate plan at $0 a month with 1 million requests and 100 GB of transfer. S3 storage costs extra.

Read our longer S3 and Cognito comparison.

Option 5: Display, step by step

Display is a hosted service. It stores the file, serves it, and checks the identity of the reader.

1. Turn on sign-in. An Owner opens Settings → Organization → General → Single sign-on. Turn on Google Workspace, Microsoft Entra ID, or both. This needs Pro or Enterprise.
2. Optional: limit Microsoft to one directory. Enter your Azure Tenant ID (Microsoft also calls it a Directory ID) and select Save. Display rejects accounts from other directories when people sign in.
3. Optional: require SSO. Turn on Require SSO for company email domains. People on your company domains then cannot use an email one-time password.
4. Publish. Tell your agent: "Publish report.html to Display for my company." The agent publishes the file with company visibility.
5. Share the URL. A colleague opens it, signs in with Google or Microsoft, and sees the page. To update the file, tell the agent: "Update the page at the same link."

For limits and settings, read Sign-in methods, Company email domains and Sharing and access. For the security model, read Security. Prices are on the pricing page.

Readers outside your company

Tell your agent: "Share this page with partner@example.com." Each guest enters their address and a one-time password that Display sends. They need no Display account. Guests can view. They cannot comment yet. On Pro and Enterprise, an Owner can also restrict outside sharing for the whole organization.

What Display does not do

• Self-serve SAML, for example with Okta, is on the roadmap.
• Custom domains are on the roadmap.
• Display serves one HTML or Markdown file for each artifact. Publishing a directory or a ZIP file is on the roadmap.
• Display does not run server code.

When do-it-yourself is the better choice

• You already use Cloudflare Zero Trust. One more application costs nothing and needs little work.
• The content must stay in your own cloud account. Display stores the files. Use S3, Azure or your own server.
• You protect an application with logic and APIs. Use the sign-in feature of your platform.
• You need custom policies, such as device checks or network rules. Cloudflare Access supports them. Display does not.