How AuthRobo works

AuthRobo sits between your app and the things that prove who a user is — passwords, Google, LinkedIn, GitHub, Apple — and hands your app a single, uniform result: a signed token and a user record.

The broker model

You never integrate LinkedIn, Google, or Apple directly. Your app talks to one system (AuthRobo), and AuthRobo talks to the providers. That means one integration, one set of tokens, and one user table — no matter how many sign-in methods you turn on.

your users → your app → AuthRobo → { password | Google | LinkedIn | GitHub | Apple }
                          ↓
                 signed token + user record

What your app deals with

• A hosted login/register page you send users to (https://authrobo.com/login?client_id=…), or the drop-in @authrobo/react UI.
• A one-time code AuthRobo returns to your redirect_uri after the user authenticates.
• An `exchange` call (server-side, with your client_secret) that turns that code into an access_token + refresh_token.
• A user record from GET /users/me, including plan and subscription_status synced from Stripe.

What AuthRobo deals with

• Talking to each provider over OAuth/OIDC, holding the provider secrets.
• Normalising every provider's profile into one shape (id, email, name, image).
• Minting and signing your tokens (RS256), and publishing the JWKS to verify them.
• Storing users per app and keeping billing state in sync.

Next steps

• Get your credentials and make the first call
• Turn on social sign-in
• Understand redirect URIs — the one thing people most often get wrong