Supported providers: Google, Facebook, GitHub and Microsoft, alongside password, magic-link and email-code sign-in.
Each provider offers two shapes. Redirect flows suit web apps; token exchange suits native apps that have already completed sign-in with the platform SDK.
/profile/googleNo auth/profile/google/redirectNo auth/profile/customer/google/tokenNo authThe token endpoint takes a Google ID token from a native sign-in and returns an AppEngine customer session — no browser round trip.
/profile/facebook/urlNo auth/profile/facebookNo auth/profile/facebook/redirectNo auth/profile/facebook/tokenNo auth/facebook/url returns the authorization URL to open, for clients that want to control the redirect themselves rather than being bounced through the API.
GitHub
/profile/github/urlNo auth/profile/githubNo auth/profile/github/redirectNo auth/profile/github/redirectNo auth/profile/github/tokenNo authThe callback accepts both GET and POST.
Generic customer social login
/profile/customer/social-loginNo authValidates a provider token and issues a customer session — the single entry point when the client already knows which provider it used.
After a successful flow
/profile/auth/successNo authWhere redirect flows land. From here the client picks up the session.
OAuth for integrations
Provider connections for integrations — as opposed to sign-in — are handled by ConnectModule:
/connect/oauth2callback/:providerNo authThese callbacks arrive without an orgid, so the middleware falls back to SHARED_ORG. Webhooks under /connect/webhook/* instead carry the org in the URL path, which the middleware parses out.
See Integrations.
Every provider needs its callback registered in the provider's own console. Redirect URIs are environment-specific — a localhost callback registered for development will not work in production, and the failure surfaces at the provider, not in AppEngine's logs.