feat(access): add App-user identity and OIDC sign-in for deployed Apps

[Yevanchen]

Area

API / Web app

Problem

Builders need a simple way to identify App users without shipping a separate account system for every Mosoo-deployed or third-party App.

Today Google OAuth and Email OTP authenticate Mosoo Builders. CLI OAuth ends by issuing the Builder a Personal Access Token. Neither surface makes Mosoo an OAuth/OIDC provider for App users, and App Deployment explicitly does not provide App-user authentication. Builders therefore still need to own login, user storage, and identity mapping.

User story

As an App Owner, I want to enable Access for one App so users can choose Continue with Mosoo or Continue with Google, and the App can receive a stable App-scoped identity through standard OIDC without granting those users Mosoo Console access.

Proposal

Add an opt-in, App-scoped Access surface:

• One owner-managed OIDC client per App with an exact redirect-URI allowlist.
• OAuth 2.1 Authorization Code flow with PKCE.
• OIDC discovery, JWKS, authorization, token, and userinfo endpoints.
• MVP scopes limited to openid profile email.
• Mosoo Account and Google are upstream sign-in methods that resolve to a separate, stable, App-scoped sub.
• First-use consent plus owner/user revocation.
• Short-lived tokens; the App maintains its own session after code exchange.

This is an inbound identity-provider boundary. It must remain separate from MCP OAuth, CLI device authorization, and owner Personal Access Tokens.

Acceptance criteria

• A Builder can enable Access for an App, create its OIDC client, and configure exact redirect URIs.
• A standard OIDC client can complete Authorization Code + PKCE through both Mosoo Account and Google sign-in paths.
• ID tokens are verifiable through JWKS and contain stable sub, iss, aud, exp, verified email, and approved profile claims.
• The same identity has a stable sub within one App but cannot be correlated across Apps.
• A Google-only App user is not created as a Builder or Organization/App owner and receives no Console permissions.
• Unregistered or wildcard redirect URIs, expired/replayed authorization codes, and missing/incorrect PKCE are rejected.
• Example and integration clients validate state, nonce, iss, aud, and exp.
• Disabling Access, deleting the Deployment, or revoking the client prevents new authorization; issued tokens expire on a documented short TTL.
• Existing Console login, CLI device login, MCP OAuth, and Public API token behavior remain unchanged.

Out of scope for MVP

• App roles or RBAC
• Enterprise SSO, SAML, SCIM, and custom identity providers
• Dynamic client registration, M2M grants, and custom scopes
• Refresh tokens
• Password login and password recovery
• Custom branding beyond App name and icon

Alternatives considered

• Integrate Google separately in every App: fragments identity and excludes Mosoo Account users.
• Ship an auth database/library in every App: duplicates security-sensitive work and raises deployment cost.
• Reuse PATs: rejected because PATs represent the App owner, not an App user.

Compatibility and product boundary

This is additive and opt-in, but it changes the current canonical boundary that Mosoo Account is not an End User identity. Access must introduce a separate App-user principal; it must not reuse Builder, Organization, or App authorization subjects.

Contribution

I can provide product feedback and validate the user flow.

Checklist

• I searched existing open and closed issues before opening this request.
• I described the problem before the proposed solution.
• I kept this request focused on one improvement.