Your credentials & env vars (for dummies)

When you create an app in AuthRobo, you get three values. That's the whole config. This page explains what each one is, in plain English, and the single rule that keeps you safe.

The three values

Think of your app as needing to phone AuthRobo. To do that it needs to know who to call, who it is, and a password to prove it.

A good analogy: the issuer URL is the building address, the client ID is your name badge (fine for anyone to see), and the client secret is your keycard. You'd hand out your name badge all day — you would never photocopy your keycard and tape it to the front door.

The one golden rule

Why it matters: the secret is what AuthRobo uses to trust that a token-exchange request is genuinely your backend. Anyone who has it can impersonate your app.

Your .env file

Name them exactly like this — AuthRobo's SDK and your server code read these literal names:

AUTHROBO_ISSUER_URL=https://authrobo.com
AUTHROBO_CLIENT_ID=arc_your_client_id
AUTHROBO_CLIENT_SECRET=ars_your_client_secret

In local development, point the issuer at your local AuthRobo instead: AUTHROBO_ISSUER_URL=http://localhost:3000.

The mistake that trips everyone up: NEXT_PUBLIC_

This one is Next.js-specific and it's the big one. In Next.js, any environment variable whose name starts with NEXT_PUBLIC_ is copied into the JavaScript that ships to every visitor's browser. That's a feature — it's how you expose safe values to client code. It is not an AuthRobo setting and AuthRobo doesn't look for those names.

So:

• NEXT_PUBLIC_AUTHROBO_CLIENT_ID — harmless (the client ID is public anyway), but usually unnecessary — see below.
• NEXT_PUBLIC_AUTHROBO_CLIENT_SECRET — never do this. It bakes your secret into the browser bundle for anyone to copy. If you've ever built or deployed with this, treat the secret as compromised and rotate it in the dashboard.

Rule of thumb: the secret never gets a `NEXT_PUBLIC_` prefix. Ever.

"But do I even need NEXT_PUBLIC for the client ID?"

Usually no. The cleanest pattern is to read the values on the server and pass the public ones down to your client components as props:

// A Server Component reads plain (server-only) env vars…
<AuthButton
  clientId={process.env.AUTHROBO_CLIENT_ID}
  issuerUrl={process.env.AUTHROBO_ISSUER_URL}
/>

Your browser code gets the client ID it needs (via props), and you never had to expose anything through NEXT_PUBLIC_. The secret, meanwhile, stays in server-only files (your token-exchange route, e.g. @authrobo/sdk's exchange).

Wait — which client secret? (AuthRobo's vs Google's)

A common source of confusion: there are two different "client id / client secret" pairs in play, and they belong to different layers.

• Your AuthRobo credentials (this page) — issued by AuthRobo, identify *your app* to *AuthRobo*.
• A provider's credentials (e.g. a Google client_id/client_secret) — issued by Google, identify a provider app to *Google*. You only deal with these if you bring your own provider app so the Google consent screen shows your brand instead of "AuthRobo".

They're never interchangeable. When a doc says "client secret" with no qualifier, it means your AuthRobo secret.

Quick troubleshooting

• Both Google and email/password sign-in fail → almost always a config problem, not a code bug. Check the env var names match exactly and AUTHROBO_ISSUER_URL points at the right instance (dev vs prod).
• "invalid client" / 401 on exchange → wrong or missing AUTHROBO_CLIENT_SECRET on the server.
• Secret shows up in browser dev-tools / network → you exposed it (likely a NEXT_PUBLIC_ prefix or a secret read from client code). Rotate it and move the read to the server.

Next steps

• How AuthRobo works — the broker model
• Get your credentials and make the first call
• Why does Google say "AuthRobo"? — bring your own provider app