Proxy recipes, one per identity provider

searchcode never talks to your identity provider. In auth.mode: proxy an authenticating proxy does that, and searchcode reads the identity headers the proxy sends. The release ships one oauth2-proxy configuration per common provider, each with the searchcode.yaml fragment that goes with it, under proxy-recipes/ in the tarball.

Provider	Groups	How people get access	Status
Google Workspace	none sent	`users:` and `adminUsers`, by address	unverified
Microsoft Entra ID	a group claim	groups, with `adminUsers` as the break-glass second admin	unverified
Okta	a group claim	groups, with `adminUsers` as the break-glass second admin	unverified
Keycloak	a group mapper	groups, with `adminUsers` as the break-glass second admin	unverified

Unverified means nobody has completed a real sign-in through that recipe yet. Each is built from the shipped systemd/oauth2-proxy.cfg, which has been run, plus the provider's documentation. Treat an unverified recipe as a careful starting point and check each setting against your provider.

What makes the email trustworthy

users: entries and authz.adminUsers match the address the proxy sends in X-Forwarded-Email. A grant by name is only as good as the provider's guarantee that the address belongs to the person signing in.

Provider	What makes the address trustworthy
Google Workspace	Google asserts only verified addresses for Workspace accounts. Set `email_domains` to your Workspace domains.
Microsoft Entra ID	A single-tenant app registration and the tenant-specific issuer, `https://login.microsoftonline.com/<tenant-id>/v2.0`. Never the `common` or `organizations` issuer: a multi-tenant issuer accepts an email claim another tenant set.
Okta	Okta asserts `email_verified` for the organisation's own users, and oauth2-proxy refuses an unverified address by default.
Keycloak	Two realm settings: "Verify email" on, and users unable to change their own email without verifying it again.

On every provider, leave oauth2-proxy's insecure_oidc_allow_unverified_email at its default of false. Turning it on to make a sign-in work is what lets an unverified address reach a grant.

Google Workspace sends no groups

Google has no groups scope. Asking for one fails the whole sign-in with Error 400: invalid_scope. So the Google recipe asks for openid email profile and grants access in searchcode.yaml:

authz:
  defaultAccess: deny
  adminUsers: [first.admin@example.com, second.admin@example.com]
  bindings:
    - name: Everyone in the Workspace reads the estate
      groups: ["*"]
      repoGroups: [engineering]
      role: viewer
    - name: The engagement team reads the client's repositories
      users: [a.person@example.com, b.person@example.com]
      repoGroups: [client-work]
      role: viewer

groups: ["*"] means anyone the proxy admitted, which email_domains limits to your Workspace. See who sees what for how users: is matched.

Two settings that have gone wrong before

trusted_proxy_ips, never trusted_ips. trusted_proxy_ips names the front end whose X-Forwarded-For the proxy believes. trusted_ips is a list of addresses allowed to skip authentication entirely. No shipped file sets it.
Each identity header is written once, by the proxy. Nothing in front of it should add or rewrite an X-Forwarded-* header. Before people could be named in searchcode.yaml, a provider with no groups needed a reverse proxy to invent a group header per address. That arrangement put the access policy in a file searchcode cannot validate or explain, and it broke in several ways that were hard to see.

The rest of the proxy's settings, including how oauth2-proxy can add searchcode's shared secret itself, are explained in the shipped systemd/oauth2-proxy.cfg and in the systemd install.