Add Google Cloud IAP authentication method

[sa3eed3ed]

Summary

This adds an optional iap authentication method for deployments that run behind Google Cloud Identity-Aware Proxy.

When OpenRelik is deployed behind IAP (a common setup for internal/BeyondCorp-style deployments on GCP), the proxy has already authenticated the user before any request reaches the server, and IAP policy (including Google Groups) already controls who gets through. Today such deployments still have to run a second OAuth flow inside OpenRelik via the google auth method, which means provisioning a separate OAuth client and maintaining a duplicate allowlist.

Trusting a plain identity header from a proxy would be insecure (headers can be spoofed if the backend is ever reachable directly), so this implements GCP's documented approach instead: validating the signed X-Goog-IAP-JWT-Assertion header that IAP attaches to every proxied request (Securing your app with signed headers).

Technical details

• New src/auth/iap.py, closely mirroring the structure of the existing oidc.py:
  • GET /login/iap validates the assertion and issues the standard OpenRelik JWT cookies, then redirects to the UI. Since IAP adds the header to every request, there is no redirect dance — validating the header is the whole login flow.
  • Verification uses google.oauth2.id_token.verify_token (the google-auth dependency already used by google.py) against IAP's public JWK endpoint, checking signature, expiry, audience and issuer.
  • Users are auto-provisioned on first login like the google/oidc methods (auth_method="iap"). IAP assertions carry no profile claims, so the email doubles as display name.
• New [auth.iap] config section (documented in settings_example.toml):
  • audience — the expected assertion audience shown in the IAP console
  • allowlist / public_access — same semantics as the other methods. Note public_access = true here does not expose the server publicly: only identities IAP has authenticated and authorized can carry a valid assertion, so deployments can fully delegate access control to IAP policy.
  • certs_url — override of the verification-key URL, for testing against locally minted assertions
• Conditionally imported/mounted in main.py exactly like the oidc method, so existing deployments are unaffected unless [auth.iap] is configured.
• Adds a pyjwt[crypto] dependency: IAP publishes its verification keys in JWK format, and google-auth delegates JWK-set verification to PyJWT (its x509-PEM path used by the existing google method does not need it). This matches the dependency set in GCP's own signed-header validation samples.
• The login UI needs no changes: setting OPENRELIK_AUTH_METHODS=iap renders a generic login button for the method.

Testing

• Unit tests in src/tests/auth/iap_test.py following the structure of oidc_test.py: assertion validation (valid, invalid signature, wrong issuer), allowlist/public-access authorization, missing header, missing email claim, and user provisioning for new and existing users. Full test suite passes (373 tests).
• Verified end to end against a running stack with simulated IAP: a local proxy that mints ES256-signed assertions (same shape as real IAP, with a JWKS endpoint the server verifies against via certs_url). Confirmed: requests without/with-invalid/with-wrong-audience assertions are rejected with 401, valid assertions log in and provision the user, and the browser flow through the proxy works end to end including cookie-based API access afterwards.
• Additionally validated on GKE behind real Identity-Aware Proxy (GCE ingress, BackendConfig-enabled IAP, backend-service audience): live assertions verify against IAP's published JWK keys and users are provisioned from the asserted identity.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[sa3eed3ed]

@berggren Hello from over there ;)