Daedro / Handbook
Chapters
HandbookChapterRead Markdown ↗

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:

{
  "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.