Intastellar Sign-In supports more than one integration style. Pick the path that matches your stack:

You are building…	Start here
React app	Intastellar Sign-In — React SDK and plain JavaScript — aligns with the official npm package.
Plain HTML / CSS / JS	Plain HTML, CSS, and JavaScript — no framework; migrated from the former developers-site JS docs.
Custom OAuth code flow (any server)	Continue below, then Authorization code flow.

The sections below focus on registering a client and planning redirects / sessions for your applications. They complement the SDK-focused guide, which uses illustrative code only.

1. Register your application

Create an OAuth/OIDC-style client in the Intastellar registration flow your team uses. Capture:

• Client ID — public identifier (safe in front-end code for public clients).
• Client secret — only for confidential (server-side) clients; never ship it in the browser or app binaries.
• Redirect / login URIs — exact URLs Intastellar may use when returning the user or completing sign-in. See Redirect URIs and callbacks.

Use separate clients (or isolated redirect lists) for production and staging.

2. Choose a flow

Your app	Recommended approach
React	@intastellar/signin-sdk-react — see integrating React and JavaScript.
Vanilla JS (static sites)	Plain HTML, CSS, and JavaScript.
SPA (custom)	Authorization code with PKCE; no client secret in the browser.
Server-rendered site	Browser completes redirect; your server exchanges the code with the client secret.
Mobile / native	PKCE, custom scheme or HTTPS redirect.

Details: Authorization code flow, SPAs and JavaScript, Server-side exchange.

3. Endpoints and metadata

Your registration or Intastellar’s guide should list (or link to discovery for):

• Authorization endpoint — user signs in (for code-flow integrations).
• Token endpoint — exchange code for tokens.
• Issuer / JWKS — for validating ID tokens with OpenID Connect.

Examples in these guides use placeholders such as AUTHORIZATION_ENDPOINT and TOKEN_ENDPOINT.

4. Plan sessions

Decide how your origin remembers the user:

• HttpOnly session cookies from your server (typical for traditional apps).
• Opaque session id plus server-side store.
• Short-lived access token in memory for SPAs, with a BFF when possible.

If you use the SDK, it may set first-party cookies on your domain; combine that with your own session if you need server-rendered pages—see Sessions, cookies, and tokens.

Next steps

Authorization code flow — for hand-rolled authorize + callback + token integrations.