Intastellar Developers
Versionv1

Intastellar only completes sign-in return flows to pre-registered URLs (or URIs your client registration allows for the login URI used by the React SDK). A typo, wrong scheme, or trailing slash mismatch causes redirect_uri_mismatch or similar errors.

If you change the public hostname of your app (for example after a domain migration), update your Intastellar client so allowed redirect / login entries match the new origin and paths. SDKs often derive a login URI from the current page (hostname, port, pathname) unless you override it—register the values you actually send.

Rules of thumb

  1. HTTPS in production — http://localhost is often allowed for development; production should use https://.
  2. Exact match — https://app.example.com/callback and https://app.example.com/callback/ are different paths; register the one you use in the authorize request.
  3. No wildcards in most setups — register each concrete callback path (or follow your console’s documented pattern if path templates are supported).
  4. Query strings — avoid putting dynamic query strings in the registered URI unless your registration explicitly allows it; prefer a fixed path and pass internal context via state.

Multiple environments

Register separate redirect URIs (or separate clients) for:

  • Local development (http://127.0.0.1:5173/auth/callback, etc.)
  • Staging
  • Production

This limits blast radius if a secret leaks in a non-production client.

SPA routers

If you use hash routing (/#/callback), check whether your identity provider allows that pattern for redirects; many require path-based URLs (/auth/callback) for the OAuth callback.

After redirect

On the callback route:

  1. Read code and state from the query string.
  2. Verify state against what you stored when you started the flow.
  3. Exchange the code at the token endpoint (see Authorization code flow).
  4. Redirect the user to the final in-app destination (dashboard, return URL stored in state, etc.).

Next

Sessions, cookies, and tokens for how to persist the signed-in user safely after a successful callback.

Last updated