# AuthRobo Knowledge Base Guides and concepts for AuthRobo, an authentication + Stripe-billing platform. Rendered pages: https://authrobo.com/kb/. 9 articles. ## Getting started --- # How AuthRobo works Slug: how-authrobo-works | Category: Getting started | Updated: 2026-07-02 URL: https://authrobo.com/kb/how-authrobo-works The mental model: AuthRobo is an identity broker between your app, your users, and providers like Google and LinkedIn. 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](https://www.npmjs.com/package/@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](/docs#verify) to verify them. - Storing users per app and keeping billing state in sync. ## Next steps - [Get your credentials and make the first call](/docs#quickstart) - [Turn on social sign-in](/kb/shared-vs-bring-your-own) - [Understand redirect URIs](/kb/redirect-uris) — the one thing people most often get wrong --- # Delete an app (and clean up your client) Slug: delete-an-app | Category: Getting started | Updated: 2026-07-03 URL: https://authrobo.com/kb/delete-an-app What happens when you delete an app in AuthRobo, and the checklist to tidy up your own codebase and providers afterward. Deleting an app is permanent and immediate. Open the app in the dashboard, scroll to **Danger zone**, and choose **Delete app** — you'll be asked to confirm. ## What AuthRobo removes Deleting the app cascades to everything AuthRobo stores for it: - The app itself (its `client_id` / `client_secret`). - Every end-user under the app, and their linked social/password identities. - All active sessions and refresh tokens (so existing logins stop working). - Enabled sign-in methods and any provider credentials you saved. - The app's billing links (subscription rows). Tokens already issued keep verifying until they expire (they're signed JWTs), but no new ones can be minted and `/users/me` lookups will 404. ## What AuthRobo does NOT touch - **Your client codebase** — that's yours; see the checklist below. - **Your Stripe account** — if you used Stripe Connect, only the link is forgotten; your Stripe account and its data remain. - **Your provider apps** — your Google/LinkedIn/GitHub OAuth apps stay as they are. ## Client-side cleanup checklist Once the app is deleted, tidy up the consuming app so it doesn't call a client that no longer exists: 1. **Remove the env vars** — `AUTHROBO_ISSUER_URL`, `AUTHROBO_CLIENT_ID`, and `AUTHROBO_CLIENT_SECRET` (and any `NEXT_PUBLIC_AUTHROBO_CLIENT_ID`). 2. **Remove the UI** — delete `@authrobo/react` buttons/components (`AuthRoboButton`, `AuthRoboAuth`) and the provider if you wrapped your app in `AuthRoboProvider`. 3. **Remove the SDK calls** — any `@authrobo/sdk` usage (`exchange`, `verify`, `getUser`, billing helpers). Uninstall the packages if nothing else uses them: `npm rm @authrobo/react @authrobo/sdk`. 4. **Remove the callback route** — the `redirect_uri` handler you added just for AuthRobo (e.g. `/auth/callback`). 5. **Invalidate stored tokens** — clear any AuthRobo access/refresh tokens you cached in your own sessions or database. 6. **Provider redirect URLs** — if a Google/LinkedIn/GitHub app was used only for this integration, remove AuthRobo's callback from its authorized redirect URLs (or delete the provider app). 7. **Custom domain** — if you'd set up a [white-label auth domain](/kb/redirect-uris), remove its DNS `CNAME` record. That's it — nothing else phones home to AuthRobo. --- # Your credentials & env vars (for dummies) Slug: credentials-and-env-vars | Category: Getting started | Updated: 2026-07-04 URL: https://authrobo.com/kb/credentials-and-env-vars Plain-English guide to the three values AuthRobo gives you, which one is a secret, and the one mistake that leaks it into the browser. 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**. | Value | Plain English | Looks like | Secret? | |---|---|---|---| | `AUTHROBO_ISSUER_URL` | *Who to call* — the address of your AuthRobo | `https://authrobo.com` (or `http://localhost:3000` in dev) | No — public | | `AUTHROBO_CLIENT_ID` | *Who you are* — your app's public name tag | `arc_2f9a…` | No — public | | `AUTHROBO_CLIENT_SECRET` | *Your password* — proves the request is really from your server | `ars_8c1d…` | **YES — keep hidden** | 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 > **The client secret must never reach the browser.** It lives only on your server. The issuer URL and client ID are safe to expose; the secret is not. 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… ``` 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](/kb/shared-vs-bring-your-own) 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](/kb/how-authrobo-works) — the broker model - [Get your credentials](/docs#credentials) and [make the first call](/docs#quickstart) - [Why does Google say "AuthRobo"?](/kb/google-setup) — bring your own provider app ## Concepts --- # Redirect URIs: the two callbacks Slug: redirect-uris | Category: Concepts | Updated: 2026-07-02 URL: https://authrobo.com/kb/redirect-uris There are two different callback URLs in a social sign-in. Mixing them up is the #1 setup mistake. Here's exactly which is which. A brokered social sign-in has **two** redirect hops, and therefore two callback URLs registered in two different places. Almost every setup problem comes from confusing them. ## The flow, step by step ``` 1. user clicks "Sign in with LinkedIn" in your app 2. → AuthRobo (start) 3. → LinkedIn (user approves) 4. → AuthRobo /api/v1/auth/linkedin/callback ← callback #1 5. → your app https://yourapp.com/auth/callback ← callback #2 (+ AuthRobo code) 6. your app calls exchange() → tokens ``` ## Callback #1 — provider → AuthRobo Registered **inside your LinkedIn/Google/GitHub app**. It must be AuthRobo's endpoint: ``` https://authrobo.com/api/v1/auth//callback ``` This is where the provider hands its code to AuthRobo, which holds the secret and does the token exchange. It is the same value whether you use a shared or bring-your-own app. ## Callback #2 — AuthRobo → your app Registered **in the AuthRobo dashboard**, in your app's allowed redirect URIs. This is *your* URL: ``` https://yourapp.com/auth/callback ``` This is where AuthRobo sends its own one-time code after the provider dance finishes. Your backend exchanges that code for tokens. ## Side by side | | Callback #1 | Callback #2 | |---|---|---| | Registered in | Your provider app (LinkedIn, …) | AuthRobo dashboard | | Value | `https://authrobo.com/api/v1/auth//callback` | `https://yourapp.com/…` | | Who receives the code | AuthRobo | Your app | | Which secret exchanges it | Provider secret (AuthRobo holds) | Your `client_secret` | ## Worked example: MYCV You're adding LinkedIn to MYCV with your **own** LinkedIn credentials: - In the **LinkedIn app**, set the authorized redirect URL to `https://authrobo.com/api/v1/auth/linkedin/callback` (callback #1). Not a MYCV URL. - In the **AuthRobo dashboard**, add `https://mycv.com/auth/callback` to MYCV's allowed redirect URIs (callback #2). If you instead point the LinkedIn app at `https://mycv.com/…`, LinkedIn hands its code straight to MYCV, AuthRobo is bypassed, and none of the broker's benefits (uniform tokens, user records, Stripe linkage) apply. > Want a MYCV-branded callback #1? That requires a white-label auth domain (e.g. `auth.mycv.com` as a CNAME to AuthRobo). The code is still served by AuthRobo — only the hostname changes. --- # Access tokens and verifying them Slug: access-tokens | Category: Concepts | Updated: 2026-07-02 URL: https://authrobo.com/kb/access-tokens What AuthRobo tokens contain, how to verify them offline against the JWKS, and how refresh works. After a successful sign-in your app holds an `access_token` and a `refresh_token`. Here's what they are and how to use them safely. ## Access tokens are RS256 JWTs You can verify them **offline** against AuthRobo's published [JWKS](/docs#verify) — no network call per request after the keys are cached. Always check: - `iss` equals your issuer (`https://authrobo.com`) - `aud` equals your `client_id` - `exp` has not passed - `sub` is the user id ```ts import { jwtVerify, createRemoteJWKSet } from "jose"; const JWKS = createRemoteJWKSet(new URL("https://authrobo.com/api/v1/jwks")); const { payload } = await jwtVerify(token, JWKS, { issuer: "https://authrobo.com", audience: process.env.AUTHROBO_CLIENT_ID, }); // payload.sub = user id ``` The [@authrobo/sdk](https://www.npmjs.com/package/@authrobo/sdk) `verify()` helper does exactly this. ## Refreshing Access tokens are short-lived. When one expires, exchange the `refresh_token` for a fresh pair at `POST /auth/token`. Refresh tokens rotate — always store the new one you get back. ## Keep the secret server-side The `exchange` and admin endpoints use your `client_secret`. It must never ship to a browser. The token *verification* above needs only the public JWKS, so it's safe anywhere. ## The full user record To read profile + billing state (`plan`, `subscription_status`), call [`GET /users/me`](/docs#reference) with the access token. That's a live read from AuthRobo, distinct from offline JWT verification — use verification for per-request auth, and `/users/me` when you need the freshest user data. ## Social sign-in --- # Shared vs bring-your-own provider apps Slug: shared-vs-bring-your-own | Category: Social sign-in | Updated: 2026-07-02 URL: https://authrobo.com/kb/shared-vs-bring-your-own Every social provider runs in one of two modes. Use AuthRobo's shared app to ship in minutes, or bring your own credentials for your own branding. When you enable a social provider (LinkedIn, GitHub, Google), AuthRobo needs OAuth credentials to talk to it. There are two ways to supply them. ## Mode A — Shared (the default) Leave the credential fields blank and just toggle the method **on**. AuthRobo uses its own shared provider app. - **You register nothing with the provider.** No LinkedIn app, no Google project. - Fastest path — it works the moment you flip the toggle. - Trade-off: the provider's consent screen shows **"AuthRobo would like to access…"**, not your brand. Great for prototypes, internal tools, and getting to a working flow before you invest in provider setup. ## Mode B — Bring your own Paste your own `client_id` and `client_secret` (from your own provider app) into that method's config in the dashboard. AuthRobo presents *your* credentials to the provider instead of its shared ones. - The consent screen shows **your** app's name and logo. - You get your own rate limits and provider-side settings. - Required by some providers' terms once you're in production. > Bringing your own credentials changes **which credentials AuthRobo presents** — it does **not** change **where the provider sends users back**. That callback is always AuthRobo. See [Redirect URIs](/kb/redirect-uris). ## Which should I use? | | Shared | Bring your own | |---|---|---| | Setup time | Instant | ~10 min per provider | | Consent screen brand | "AuthRobo" | Your app | | Rate limits | Shared | Yours | | Best for | Prototypes, internal tools | Production, public apps | You can start on Shared and switch to bring-your-own later without changing any of your app's code — it's a dashboard change only. ## The one rule that trips people up In **both** modes, the provider app's registered redirect/callback URL must be **AuthRobo's** callback, e.g.: ``` https://authrobo.com/api/v1/auth/linkedin/callback ``` Never your own app's URL. Your app's URL is a *different* callback, registered with AuthRobo — read [Redirect URIs](/kb/redirect-uris) next. --- # Set up Sign in with LinkedIn Slug: linkedin-setup | Category: Social sign-in | Updated: 2026-07-02 URL: https://authrobo.com/kb/linkedin-setup Bring your own LinkedIn app to AuthRobo, from creating the LinkedIn app to enabling the method in your dashboard. This walks through **bring-your-own** LinkedIn setup (Mode B). For a quick prototype you can skip all of this and just toggle LinkedIn on to use AuthRobo's [shared app](/kb/shared-vs-bring-your-own). ## 1. Create a LinkedIn app 1. Go to the [LinkedIn Developer portal](https://www.linkedin.com/developers/apps) and create an app (you'll need an associated LinkedIn Page). 2. On the **Products** tab, add **Sign In with LinkedIn using OpenID Connect**. 3. On the **Auth** tab, copy the **Client ID** and **Client Secret**. ## 2. Register AuthRobo's callback Still on the **Auth** tab, under **Authorized redirect URLs**, add exactly: ``` https://authrobo.com/api/v1/auth/linkedin/callback ``` This is [callback #1](/kb/redirect-uris) — it points at AuthRobo, not your app. This is the step people most often get wrong. ## 3. Add your credentials to AuthRobo In the AuthRobo dashboard, open your app → **Sign-in methods** → LinkedIn, paste the **Client ID** and **Client Secret**, and enable the method. Scopes are handled for you: AuthRobo requests `openid profile email`. ## 4. Register your app's redirect URI Add your own callback — where AuthRobo returns its code — to your app's allowed redirect URIs in the dashboard. This is [callback #2](/kb/redirect-uris): ``` https://yourapp.com/auth/callback ``` ## 5. Send users to sign in Use the drop-in button from [@authrobo/react](https://www.npmjs.com/package/@authrobo/react): ```tsx import { AuthRoboButton } from "@authrobo/react"; ``` …or link straight to the hosted flow: `https://authrobo.com/api/v1/auth/linkedin/start?client_id=…&redirect_uri=…`. ## Troubleshooting - **"redirect_uri does not match"** on LinkedIn → callback #1 in your LinkedIn app doesn't exactly equal `https://authrobo.com/api/v1/auth/linkedin/callback`. Check for a trailing slash or `http` vs `https`. - **AuthRobo rejects the return** → callback #2 isn't in your app's allowed redirect URIs in the dashboard. - **Consent screen says "AuthRobo"** → you're still on the shared app; add your own credentials (step 3) to show your brand. --- # Connect a social provider Slug: connect-a-social-provider | Category: Social sign-in | Updated: 2026-07-03 URL: https://authrobo.com/kb/connect-a-social-provider Step-by-step field-by-field setup for Google, LinkedIn, GitHub, and Apple — kept in sync with the dashboard's guided panels. AuthRobo brokers social sign-in, so you register **one** callback URL per provider — and it always points at AuthRobo, never at your own app. See [Redirect URIs](/kb/redirect-uris) for why. ## Your callback URL Every provider needs the same redirect/callback URL, shaped like this: ``` https:///api/v1/auth//callback ``` `` is wherever your app is served from — your default `blah123.authrobo.com`, a Pro **vanity subdomain** like `mycv.authrobo.com`, or your own **custom domain**. The dashboard shows the exact URL to copy for each provider, already filled in for your domain. ## Google Console: [Google Cloud Console](https://console.cloud.google.com/apis/credentials) · Scopes: `openid email profile` 1. In the Google Cloud Console, open APIs & Services → Credentials and create an OAuth client ID of type Web application. 2. Under Authorized redirect URIs, add exactly: https:///api/v1/auth/google/callback 3. Create the client, then copy the Client ID and Client secret. 4. Paste both into the fields below and enable Google. > If your OAuth consent screen is in Testing, only your listed test users can sign in — publish it for public access. > Leave the fields blank to use AuthRobo's shared dev app (fastest, but the consent screen shows “AuthRobo”). ## LinkedIn Console: [LinkedIn Developer Portal](https://www.linkedin.com/developers/apps) · Scopes: `openid profile email` 1. In the LinkedIn Developer Portal, create an app (you'll need an associated LinkedIn Page). 2. On the Products tab, add “Sign In with LinkedIn using OpenID Connect”. 3. On the Auth tab, under Authorized redirect URLs, add exactly: https:///api/v1/auth/linkedin/callback 4. Still on the Auth tab, copy the Client ID and the Primary Client Secret. 5. Paste both into the fields below and enable LinkedIn. > The redirect URL must match {callback} exactly — watch for a trailing slash or http vs https. ## GitHub Console: [GitHub Developer Settings](https://github.com/settings/developers) · Scopes: `read:user user:email` 1. In GitHub Developer Settings, open OAuth Apps → New OAuth App. 2. Set the Homepage URL to your app's URL. 3. Set the Authorization callback URL to exactly: https:///api/v1/auth/github/callback 4. Register the app, copy the Client ID, then Generate a new client secret and copy it. 5. Paste both into the fields below and enable GitHub. > GitHub client secrets are shown only once — copy it immediately after generating. ## Apple Console: [Apple Developer](https://developer.apple.com/account/resources/identifiers) · Scopes: `name email` 1. Apple is managed centrally by AuthRobo's Services ID — there's nothing to create or paste. 2. Just toggle Apple on and it works. > Because AuthRobo signs the Apple client secret for you, per-app Apple credentials aren't supported yet. Bring-your-own Apple is on the roadmap. > Apple only returns the user's name on their first sign-in — AuthRobo captures it then. --- # Set up Sign in with Google Slug: google-setup | Category: Social sign-in | Updated: 2026-07-04 URL: https://authrobo.com/kb/google-setup Why the Google screen says “AuthRobo” by default, and a screenshot-by-screenshot guide to bringing your own Google client so it shows your brand. Google sign-in works in AuthRobo two ways. This guide answers the most-asked question first, then walks you through creating your own Google app against the **current** Google Cloud Console, screen by screen. ## "Why does it say AuthRobo instead of my app?" When you enable Google **without** entering your own credentials, AuthRobo uses its **shared Google app** so you can ship in seconds. The trade-off: Google's consent screen reads **"AuthRobo wants access to your account"**, because — as far as Google is concerned — the app asking is AuthRobo's. To make that screen show **your** name and logo, you create **your own** Google OAuth client (a `client_id` and `client_secret`) and paste it into AuthRobo. Nothing about your app's code changes — it's a dashboard change only. (More on the two modes: [Shared vs bring-your-own](/kb/shared-vs-bring-your-own).) > This is different from your **AuthRobo** client secret. These are Google's credentials, identifying a Google app to Google. If that distinction is fuzzy, read [Your credentials & env vars](/kb/credentials-and-env-vars) first. ## Before you start - A Google account with access to the [Google Cloud Console](https://console.cloud.google.com). - Your app's **AuthRobo callback URL** — copy it from the Google setup panel in your AuthRobo dashboard. It follows our convention `https:///api/v1/auth/google/callback`. Throughout this guide we use **`example.com`** as the stand-in for your domain. ## Step 1 — Create a new project In the Google Cloud Console, open the project picker at the top and click **New project**. Give it a name (e.g. your product name) and create it. Everything below happens inside this project. ![Google Cloud Console — create a new project](/kb/google/01-create-project.png) ## Step 2 — Create an OAuth client (Web application) Go to **Clients → Create client** (under APIs & Services). For **Application type**, choose **Web application**. ![Create OAuth client ID — Application type set to Web application](/kb/google/02-oauth-client-type.png) ## Step 3 — Set the URLs (use your domain + our API convention) Fill in the two URL fields using **your** domain. With `example.com` as the stand-in: - **Authorized JavaScript origins:** `https://example.com` - **Authorized redirect URIs:** `https://example.com/api/v1/auth/google/callback` Copy the exact callback from your AuthRobo dashboard so there's no typo, trailing slash, or http/https mismatch. ![Authorized JavaScript origins and redirect URIs set to example.com](/kb/google/03-redirect-uris.png) > The redirect URI must be **AuthRobo's** callback (`/api/v1/auth/google/callback`), not your app's own login page. Google returns users to AuthRobo, which then returns them to your app. See [Redirect URIs: the two callbacks](/kb/redirect-uris). ## Step 4 — Download the client details JSON After you create the client, Google offers a **Download JSON** of the client details. Download it and keep it somewhere safe — it contains your **Client ID** and **Client secret**. (You'll paste those two values into AuthRobo in the last step.) ![Download the OAuth client details JSON](/kb/google/04-download-json.png) ## Step 5 — Open Data access (scopes) In the left nav, open **Data access**, then click **Add or remove scopes**. Scopes are the permissions your consent screen asks users to approve. ![Data access page with Add or remove scopes](/kb/google/05-data-access.png) ## Step 6 — Choose the three non-sensitive scopes AuthRobo only needs identity basics. Tick exactly these **three non-sensitive** scopes, then **Update**: - `openid` — associates the user with their Google account - `.../auth/userinfo.email` — the user's email address - `.../auth/userinfo.profile` — the user's name and avatar That's the whole of `openid email profile`. Leave the sensitive and restricted scopes untouched — requesting them triggers extra Google review you don't need. ![Update selected scopes — openid, userinfo.email and userinfo.profile ticked](/kb/google/06-choose-scopes.png) ## Step 7 — Branding & verification (to publish) While your app is **unpublished / in testing**, only the test users you list can sign in. To let **any** Google user sign in, you publish the app — and Google won't verify it until the **Branding** section is complete. You'll need: - An **app name and logo** that match your brand (and match across the consent screen — Google checks for consistency). - A **valid, final Privacy Policy URL** and **Terms of Service URL** (live pages on your domain, not placeholders). - **Verified ownership of your domain** via [Google Search Console](https://search.google.com/search-console) — add and verify `example.com` there, then it can be used here. ![Branding, privacy/terms links and verified domain for publishing](/kb/google/07-branding-verification.png) > Verification can take a few days once submitted. Until then you can keep testing with listed test users — sign-in still works for them. ## Step 8 — Paste the credentials into AuthRobo Back in AuthRobo: open your app → **Google** setup panel → paste the **Client ID** and **Client secret** (from the JSON in Step 4), tick **Enable Google sign-in**, and **Save**. ![AuthRobo Google setup panel with the Client ID and secret pasted and enabled](/kb/google/08-paste-into-authrobo.png) Done. The next Google sign-in shows **your** brand on the consent screen instead of "AuthRobo". ## Troubleshooting - **"redirect_uri_mismatch"** → the redirect URI in Step 3 doesn't match AuthRobo's callback character-for-character. Re-copy it from the dashboard. - **Still says "AuthRobo"** → you're still on the shared app; make sure Step 8 saved your credentials and Google is enabled. - **"Access blocked / app not verified"** → your app is unpublished or the signer isn't a listed test user. Add the tester, or complete Step 7 and publish. - **Can't verify the domain** → do it in Google Search Console first (DNS TXT or HTML file), then return to the Branding section.