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.
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 next.