When you have a trusted server (Node, .NET, PHP, etc.), perform the token exchange there so the client secret never reaches the browser.

This matches custom OAuth code setups you control. The React SDK and plain JS popup paths are separate — Intastellar Sign-In — React and JavaScript.

How it fits together

1. Browser completes the redirect flow and lands on your callback with code and state.
2. Your callback route verifies state, then calls your backend (or runs server-side in the same request) to exchange the code.
3. Backend POSTs to TOKEN_ENDPOINT with grant_type=authorization_code, code, redirect_uri, client_id, and client_secret.
4. Backend creates a session for the user (set cookie, store tokens server-side).
5. Browser is redirected to the app with only your session cookie (not the secret).

Example (conceptual)

POST TOKEN_ENDPOINT
Content-Type: application/x-www-form-urlencoded
 
grant_type=authorization_code
&code=AUTHORIZATION_CODE
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fauth%2Fcallback
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET

Add PKCE parameters if this client is configured as hybrid or if the authorization step used PKCE.

Secret storage

• Load client_secret from environment variables or a secret manager.
• Rotate secrets if exposed; use separate credentials per environment.

Frequently asked questions

Can the front end call the token URL with the secret?

No. Anything in the browser can be copied. Keep the secret on the server.

We use PKCE in the browser — do we still use the secret?

Depends on client type and registration. If the browser started the flow with PKCE as a public client, the exchange may not use a secret — confirm in your console. Hybrid setups exist; follow your technical reference.

Next

Logout, errors, and troubleshooting.