Redirect URIs: the two callbacks

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/<provider>/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

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.