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

[minemeraj]

Related from the plugin side: I published emdash-better-auth (npm: emdash-better-auth), which wraps Better Auth and adds Google/GitHub OAuth plus email/password to public-facing EmDash sites, with a custom adapter that lands signups directly in the existing users table.

To be clear about scope so this isn't mistaken for a fix for this exact request: it solves the general "sign in with Google/GitHub" surface, not the invite-accept flow you're describing. The invite path (api/auth/invite/complete doing verifyRegistrationResponse + registerPasskey before completeInvite, with no OAuth branch) is core-side, so a plugin can't intercept invite completion or do the invited-email-equals-verified-email match without the core hooks you're proposing.

Where it might reduce the pressure here: once a person exists as a users row, OAuth-by-verified-email login already works — so the plugin covers the "sign in with Google afterwards" half. The missing half is exactly your ask: letting the invite be accepted via OAuth (create + link at completion) instead of passkey-only, which needs the OAuth branch in the invite flow.

Since I'm already building on Better Auth (which ships admin, organization, and invite-style plugins), I'm going to prototype an OAuth-acceptable invite path in my plugin repo and will report back on how much can live in a plugin vs. what genuinely needs the core invite-flow change. +1 on the proposal either way — per-email control preserved is the right framing.