# Google sign-in for the shared Hub

The shared Hub uses Google OpenID Connect as the first authentication factor.
Google Authenticator remains mandatory before access to connections, S3, text
and media tools. Secret creation, replacement, metadata access, authorization,
revocation and deletion require a fresh, action-bound authenticator approval.

## Operator setup

Create a Web application OAuth client in the project's Google Auth Platform.
The deployed client registers exactly
`https://daedro.hub.rokenshi.com/auth/google/callback`. The previous localhost
callback was replaced during the domain cutover. For a different installation,
use its exact HTTPS origin followed by `/auth/google/callback`. HTTP is permitted only
for `localhost`; changing origin also changes the passkey relying-party context.
The Hub requests only `openid` and `email`. It does not request Drive, Gmail,
Cloud administration or offline access.

Store a JSON configuration file outside Git, readable only by the Hub service
account, with mode `0600`:

```json
{
  "client_id": "YOUR_GOOGLE_WEB_CLIENT_ID",
  "client_secret": "YOUR_GOOGLE_WEB_CLIENT_SECRET",
  "allowed_emails": ["invited-member@example.com"]
}
```

Set `DAEDRO_GOOGLE_CONFIG_FILE` to its absolute path in the Hub service environment.
An absent variable leaves Google disabled; an invalid configuration prevents
startup. Keep the existing passkey option available during rollout. Restarting
the Hub expires browser sessions and in-progress authentication flows but does
not delete saved connections or authenticator enrollment.

## Identity and enrollment

The invitation list admits only Google-verified email addresses. On first login,
the Hub creates a new random account identifier and permanently binds it to the
verified Google issuer and subject. Email is an invitation check, not an account
merge key. A different Google subject cannot take over an already-bound invitation.
Existing passkey accounts and their connections remain separate. Matching names
or email addresses do not move secrets between accounts.

A new Google account enrolls Google Authenticator in the browser. A returning
account verifies its existing factor. Google success alone grants no access to
protected tool APIs. Sessions last at most fifteen minutes and never outlive the
verified Google ID token.

## Operational limits

This remains an invited private pilot. Google OAuth configuration and the user's
Google consent are external setup steps, not simulated by the application.
Factor recovery and account linking require their own reviewed implementation;
there is no bypass for a lost authenticator. The operator must test recovery,
backups, public HTTPS and availability before admitting public customers.

Do not log callback query strings, OAuth codes, tokens, QR contents or provider
credentials. Do not send the client secret to browser JavaScript. To remove a
Google invitation, edit the private configuration and restart the Hub; restart
invalidates its in-memory sessions.

## Pilot validation on 2026-11-05

The Web OAuth client and owner invitation were configured for the private pilot.
The client configuration is installed on the VM with mode `0600`; the temporary
local staging copy was removed.

In Chrome, the real Google account chooser and email consent returned through
`/auth/google/callback` to `/workspace#account`. The Hub displayed **Connect Google
Authenticator** and its enrollment QR. This confirms the Google callback reached
the required enrollment stage. Authenticator enrollment and code verification
were awaiting the owner's action at this checkpoint. Authenticated tool use
through the owner's Google account has not yet been verified.

Separately, the deployed Hub passed live protected Text stats checks in both
profiles using test authentication, including MFA and guest/signed-out denial.
Those checks validate the protected tool path; they do not complete the owner's
Google enrollment. Keep the running Hub session available during enrollment;
a restart expires the pending browser session.