Intastellar Developers
Versionv1

Treat cookies and tokens in three layers: Intastellar-hosted (login UI), your site’s origin (SDK or your session), and your backend (opaque sessions, verification).

On your site’s origin

When you use @intastellar/signin-sdk-react or a vanilla flow that mirrors it, the integration may set first-party cookies after sign-in so the tab remembers the user. Exact names and semantics are defined by the SDK and Intastellar’s documentation (npm readme, Plain HTML, CSS, and JavaScript)—do not assume they match another project’s deployment.

Your application code should treat them as SDK-managed unless Intastellar tells you otherwise.

If you run a backend or BFF, prefer:

  1. Opaque session id in an HttpOnly, Secure cookie, with SameSite suited to your topology.
  2. Server-side store mapping that id to user id, expiry, and refresh handling.
  3. Establish or refresh that session only after your server trusts the sign-in outcome (e.g. token validation per your integration guide).

See integrating React and JavaScript for a high-level “optional server session” pattern using example URLs only.

On Intastellar-controlled hosts

While the user signs in at Intastellar, the identity host may set its own cookies (SSO, session). Those are not readable from your origin’s JavaScript. Rely on tokens, your session, or the SDK, not on reading IdP cookies cross-site.

ID token vs access token

When you use OAuth-style token responses (manual code flow):

  • ID token — JWT about the authentication event; validate iss, aud, exp, signature (and nonce if used).
  • Access token — call APIs; treat as opaque unless you need to parse it.

Logout

Clear your session and follow SDK / Intastellar guidance for signing out. If an end-session URL is available, redirecting there clears IdP SSO cookies on the identity domain. See Logout, errors, and troubleshooting.

Next

Last updated