What AussieAuth is

AussieAuth is an authentication server built on Convex and Better Auth. It offers fifteen sign-in methods and, unlike a hosted auth provider, it has no consent screen of its own.

You can use the deployment behind aussieauth.com and be signing users in three commands from now, or fork the repo and run the whole thing yourself. Those are the two ways, and they differ in one line of config.

Why there's no second consent screen

An app that uses AussieAuth talks to the Convex deployment straight from its own origin. There is no redirect to an AussieAuth-hosted page in the middle, so signing in with Google shows Google's consent screen and nothing else.

This is the whole design. Hosted auth providers typically put you through two approvals — the identity provider's, then the auth provider's, on behalf of the app you were actually trying to use. AussieAuth removes the middle one by never being a page you visit.

The fifteen methods

Each is registered only when its credentials are present, so a deployment offers exactly the methods it's configured for. The sign-in card badges the rest as "needs setup" rather than letting them fail on click.

Two ways to use it

There are exactly two, and the only thing that separates them is whose deployment mints the session. Everything downstream of that — the card, the provider, ctx.auth.getUserIdentity() — is identical, which is what makes moving between them a one-line change rather than a migration.

Way 1 — lazy

aussieauth.com mints the session; your Convex deployment verifies it. No auth code in your repo, no auth tables in your schema, no secrets to collect.

bun add @aussieljk/auth
bunx aussieauth
bunx convex dev

Nothing in there needs a credential, a dashboard or a human: development origins and app schemes register without a secret, and bunx aussieauth doctor checks the result. Start here. → Way 1 — lazy

Way 2 — self-hosted

Your deployment mints it, because you forked the repo into one of your own. Your database, your provider credentials, your domain.

gh repo fork aussieljk/aussieauth --clone
# …then, in your app:
bunx aussieauth init --self-hosted

Go here when you want a method the hosted deployment doesn't offer, an OAuth consent screen with your own name on it, or users in a database you can query. → Way 2 — self-hosted

Everything else is reference: Using it from another app (app registration and origins, which both ways use), Setting up Google and Apple (the two that need a third-party console, and only for self-hosting), Native apps, Deploying, Method notes and Architecture.

Questions

Is AussieAuth a hosted service? It can be either, and that's the two ways above. aussieauth.com is a real deployment you can point an app at in three commands (lazy); it is also a repo you can run yourself (self-hosted), which is the one where you own the database the sessions live in. There's no AussieAuth account, no tenant and no per-user pricing on either.

Do users see an AussieAuth branded screen? Never, unless you send them to one. Apps embed the sign-in card at their own origin and talk to the deployment over HTTP.

What is it an alternative to? Clerk, WorkOS AuthKit, Auth0 — and specifically to their redirect-to-our-domain model. The closest thing in spirit is running Better Auth yourself, which is roughly what this is, with the Convex-shaped parts filled in.

Does it work with a non-Convex frontend? Yes. Nothing under src/auth/ imports Convex; the card talks to the auth server over HTTP like any other client. The backend does need Convex.