OAuth-acceptable invites: let an invited user accept via Google/GitHub instead of passkey-only

[afonsojramos]

Summary

Today an invite can only be accepted by registering a passkey. There is no way to invite a specific person by email and have them accept (and later sign in) with OAuth (Google/GitHub). For teams whose members prefer social login, the only workarounds are opening a whole email domain via allowed_domains, or hand-inserting a users row into D1. Neither is per-email and UI-driven.

I would like to propose OAuth-acceptable invites: if an invitee follows their invite link and signs in with a provider whose verified email matches the invited address, complete the invite (create the user, link the OAuth account) instead of requiring a passkey.

Current behavior (v0.25.1, Cloudflare Workers)

• Invites are passkey-only. api/auth/invite/complete calls verifyRegistrationResponse + registerPasskey, and only then does completeInvite(...) create the user. There is no OAuth branch anywhere in the invite flow (accept / register-options / complete).
• The invite does not pre-create a user. The user row is created at completion (accept returns user_exists: 409 if one already exists), so an invited-but-not-completed person is not yet a users row.
• OAuth only logs in existing users. The OAuth callback links a provider to an existing user by verified-email match (no domain check); for a brand-new email it falls through to canSelfSignup, which checks the allowed_domains table.
• No admin API to create a user. api/admin/users is GET-only; users/[id] is GET/PUT; enable / disable / send-recovery are POSTs that all operate on existing users. There is no supported way to pre-create a user by email + role short of a direct D1 INSERT.

Net result: to let one specific person sign in with Google, you must either enable their whole email domain for self-signup, or write a users row by hand.

Why it matters

• Passkeys are a friction point (and unfamiliar) for some non-technical team members; "Sign in with Google" is what they expect.
• Domain-wide allowed_domains is too coarse when you want one person from a shared company domain (for example a single contractor at @company.com) but not the whole company.
• Editing D1 directly to onboard a teammate is error-prone and not something you want non-admins doing.

Proposed behavior

On the invite-accept page, alongside "Register a passkey", offer the site's configured OAuth providers. If the invitee authenticates and the provider-verified email equals the invited email, complete the invite: create the user with the invited role and link the OAuth account. Optionally, let the inviter restrict which auth methods a given invite allows.

This keeps per-email control (it is still an explicit invite); it only widens how the invite can be accepted.

Alternatives considered

• allowed_domains self-signup: works, but is domain-wide and cannot scope to a single address.
• Manual users INSERT in D1: works (an existing row plus a matching verified OAuth email signs in fine), but needs database access, has no UI or API, and is easy to get wrong.
• TOTP as a passkey alternative (Add TOTP (authenticator app) as an alternative to passkeys for setup and login #432): helps the "not everyone can or wants passkeys" angle, but still is not OAuth.

Contributing

Happy to open a PR for this if the direction sounds right. My read is it would live in the invite accept flow plus the OAuth callback, gated on the provider-verified email matching the invited email, so per-email control is preserved.

Environment

• emdash 0.25.1, Cloudflare Workers (D1 + R2)
• authMode: passkey, with authProviders: [google(), github()] configured