Als je een vertrouwde server hebt (Node, .NET, PHP, enz.), voer je de token exchange daar uit zodat het client secret nooit in de browser komt.

Dit sluit aan bij eigen OAuth-code-opzetten die jij beheert. De React-SDK- en platte JS-pop-uppaden zijn apart — Intastellar Sign-In — React en JavaScript.

Hoe het samenhangt

1. Browser voltooit de redirectflow en landt op je callback met code en state.
2. Je callbackroute controleert state, roept daarna je backend aan (of draait server-side in hetzelfde verzoek) om de code in te wisselen.
3. Backend doet POST naar TOKEN_ENDPOINT met grant_type=authorization_code, code, redirect_uri, client_id en client_secret.
4. Backend maakt een sessie voor de gebruiker (cookie zetten, tokens server-side opslaan).
5. Browser wordt doorgestuurd naar de app met alleen jouw sessiecookie (niet het secret).

Voorbeeld (conceptueel)

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

Voeg PKCE-parameters toe als deze client hybride is geconfigureerd of als de authorisatiestap PKCE gebruikte.

Secret-opslag

• Laad client_secret uit omgevingsvariabelen of een secret manager.
• Roteer secrets bij blootstelling; gebruik aparte credentials per omgeving.

Veelgestelde vragen

Kan de front-end de token-URL met het secret aanroepen?

Nee. Alles in de browser kan worden gekopieerd. Houd het secret op de server.

We gebruiken PKCE in de browser — gebruiken we dan nog het secret?

Hangt af van clienttype en registratie. Als de browser de flow start met PKCE als publieke client, gebruikt de exchange mogelijk geen secret — bevestig in je console. Hybride opzetten bestaan; volg je technische referentie.

Volgende

Afmelden, fouten en probleemoplossing.