OAuth and Session
Where OAuth entry points, sessions, me, and logout sit in the downcity flow of @downcity/services.
The accounts service owns the shared account tables, better-auth runtime, OAuth callback, sessions, profiles, and City user_token issuance. Concrete login methods are provider-driven.
How to think about the OAuth entry points
There are usually two phases:
providersoauth/startoauth/result
In a typical downcity flow, providers tells the frontend which login methods are actually enabled on the current City, oauth/start begins the OAuth flow, and oauth/result confirms or polls for the result.
GET /v1/accounts/providers is a client-facing enabled list. Providers that are mounted in code but missing required env or runtime configuration are not returned. Use the Federation env catalog or admin workspace to discover what still needs to be configured.
The official accounts service can expose email, GitHub, Google, and WeChat Website App login depending on mounted providers and server-side configuration. The frontend should always trust providers instead of hardcoding login buttons.
If you want to actually wire up Google login next, continue with Google Login Setup.
If you want to actually wire up WeChat website login next, continue with WeChat Login Setup.
me and logout
These already belong to logged-in user context, not guest access.
const me = await user.service("accounts").get("me");
await user.service("accounts").action("logout").invoke();Why session still matters here
Even if the downcity mainly uses user_token to call City later, the account system still needs:
- better-auth auth tables
- a session table
- login-state facts
- downcity-facing profile data
That is why the service is not just "a few routes," but a minimal account infrastructure layer.
Mounting AccountsService does not make every login method available. Email login requires an email provider with a verification-email sender. OAuth login requires the matching OAuth provider and its client credentials.
What me returns now
GET /v1/accounts/me no longer returns only the runtime user. It also returns:
profile: downcity-facing display data such as display name and avatar
That keeps product clients and admin tools from reconstructing user state directly from auth rows.