Auth · OAuth
Signing in with a provider, and configuring the providers a deployment offers.
Signing in with a provider. google is the provider implemented today; the routes are written against a
provider list, so the others are configuration away rather than a rewrite.
Render only what will work
GET /api/auth/oauth returns the providers with a client configured, and leaves the rest out entirely.
A sign-in page that renders from it shows exactly the buttons that will succeed, rather than a row of options that
fail on click.
The flow
Navigate the browser to /api/auth/oauth/:provider — do not fetch it. The provider takes over, and sends
the person back to /api/auth/oauth/:provider/exchange, which trades the code for a session and sets the
cookies.
Configuration
The config routes are admin-guarded and hold the client credentials. config/validity is
worth calling after any change: it reports whether the stored configuration would actually work, which is the
difference between "credentials are set" and "credentials are right" — a difference that otherwise only surfaces
when somebody tries to sign in.