The authorization code flow is the standard pattern for web sign-in: the browser visits Intastellar, the user authenticates, and Intastellar redirects back to your site with a code you exchange for tokens.
React SDK (popup) vs this guide
If you use @intastellar/signin-sdk-react, sign-in typically runs in a popup: Intastellar returns a token to your page via postMessage, the SDK verifies it, and optional hooks (e.g. loginCallback) run. You do not manually build the GET authorize URL and POST token request in that mode.
Use this page when you implement the authorize + callback + token sequence yourself (non-React, mobile, or custom server). For the React SDK or plain JS path, see Intastellar Sign-In — React SDK and plain JavaScript.
Parameter names below follow common OAuth 2.0 / OIDC usage — confirm exact names, scopes, and discovery URLs in your Intastellar client registration and integration guide.
Step 1 — Redirect the user to authorize
Send the user’s browser to the authorization endpoint with query parameters:
| Parameter | Purpose |
|---|---|
response_type | Use code for this flow. |
client_id | Your registered client ID. |
redirect_uri | Must exactly match a registered URI. |
scope | Space-separated scopes (often includes openid for OIDC). |
state | Random, unguessable value; you verify it on return. |
code_challenge | PKCE: SHA-256 hash of code_verifier, Base64url-encoded (for public clients). |
code_challenge_method | Typically S256. |
Example (line breaks for readability):
GET AUTHORIZATION_ENDPOINT?
response_type=code
&client_id=YOUR_CLIENT_ID
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fauth%2Fcallback
&scope=openid%20profile%20email
&state=RANDOM_STATE
&code_challenge=CODE_CHALLENGE
&code_challenge_method=S256Store state and the raw code_verifier (for PKCE) server-side or in a secure, short-lived cookie so you can validate them on callback.
Step 2 — Handle the callback
Intastellar redirects to your redirect_uri with:
| Query param | Meaning |
|---|---|
code | One-time authorization code. |
state | Echo of the value you sent; must match stored state. |
If the user denies access or an error occurs, you may receive error and error_description instead — handle these without treating them as success.
Step 3 — Exchange the code for tokens
POST to the token endpoint (typically application/x-www-form-urlencoded):
| Field | Purpose |
|---|---|
grant_type | authorization_code |
code | The code from the callback. |
redirect_uri | Same URI as in step 1. |
client_id | Your client ID. |
code_verifier | PKCE: the original secret verifier (public clients). |
client_secret | Confidential clients only. |
The response usually includes access_token, optional refresh_token, and an id_token when openid was requested. Validate the ID token (issuer, audience, expiry, signature) using JWKS from the issuer when you rely on claims in your app.
Security checklist
- Never skip
stateverification — prevents CSRF on the callback. - Use PKCE for any client that cannot hold a client secret (SPAs, mobile).
- Use HTTPS for every redirect URI in production.
- Keep refresh tokens and client secrets only on servers you control.
Next
- Redirect URIs and callbacks — tighten registration and avoid mismatch errors.
- Sessions, cookies, and tokens — SDK cookies on your origin and your own session model.
Last updated