This article is the checklist you use before buttons, popups, and callbacks go live. If you already know you use React or plain HTML/JS, you can open those articles first and return here for anything you need to register or agree on with your team.
Pick your path
| You are building… | Start here |
|---|---|
| React | Intastellar Sign-In — React and JavaScript — matches the npm package. |
| Plain HTML / CSS / JS | Plain HTML, CSS, and JavaScript. |
| Custom OAuth-style flow (your own redirect + token steps) | Stay on this page, then Authorization code flow. |
What to have ready (checklist)
- Someone can register (or update) your app in the Intastellar client flow your organisation uses.
- You know production vs staging URLs (use separate clients or separate redirect lists).
- You know whether sign-in is only in the browser or also needs a server (session APIs, secret, etc.).
- HTTPS is planned for production (required for safe cookies and redirects).
1. Register your application
Create an OAuth/OIDC-style client and keep a safe record of:
- Client ID — public identifier (fine in front-end code for public clients).
- Client secret — only for confidential (server-side) clients. Never put it in the browser or in app binaries.
- Redirect / login URIs — exact URLs Intastellar may use when returning the user. Typos here cause the errors everyone blames on “the login server”. See Redirect URIs and callbacks.
2. Choose a flow (plain language)
| Your app | Practical approach |
|---|---|
| React | @intastellar/signin-sdk-react — React and JavaScript. |
| Vanilla JS (static site) | Plain HTML, CSS, and JavaScript. |
| SPA (custom, no SDK) | Authorization code with PKCE; no client secret in the browser. |
| Classic server-rendered site | Browser finishes the redirect; your server exchanges the code (often with a 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 technical reference should list (or link to discovery for):
- Authorization endpoint — where the user signs in (code-flow integrations).
- Token endpoint — where the code is exchanged for tokens.
- Issuer / JWKS — for validating ID tokens (OpenID Connect).
Articles use placeholders like AUTHORIZATION_ENDPOINT and TOKEN_ENDPOINT until you substitute your real values.
4. Plan how your site remembers the user
Decide how your origin keeps someone signed in:
- HttpOnly session cookies from your server (typical classic apps).
- Opaque session id plus server-side store.
- Short-lived access token in memory for SPAs, with a BFF (backend-for-frontend) when you can.
If you use the SDK, it may set first-party cookies on your domain; combine that with your own session if you also serve server-rendered pages — Sessions, cookies, and tokens.
Frequently asked questions
We only want a “Sign in with Intastellar” button
Use React or plain HTML/JS articles above; they describe the popup flow your visitors see.
“Invalid redirect” before anyone even signs in
Registration problem. Open Redirect URIs and callbacks and compare character for character with what your app sends.
Where does the client secret live?
Only on servers you control, loaded from environment or a secret manager — Server-side (confidential) clients.
Next steps
- Authorization code flow — hand-built authorize URL, callback, and token
POST. - Logout, errors, and troubleshooting — when something already “almost works”.
Last updated