Når du har en betroet server (Node, .NET, PHP osv.), skal du udføre token-udvekslingen dér, så client secret aldrig når browseren.

Det matcher tilpassede OAuth-kodeopsætninger du kontrollerer. React-SDK- og ren JS-popup-stier er adskilt — Intastellar Sign-In — React og JavaScript.

Sådan hænger det sammen

1. Browseren fuldfører omdirigeringsflowet og lander på din callback med code og state.
2. Din callback-route verificerer state, kalder derefter din backend (eller kører server-side i samme request) for at udveksle koden.
3. Backend POST’er til TOKEN_ENDPOINT med grant_type=authorization_code, code, redirect_uri, client_id og client_secret.
4. Backend opretter en session for brugeren (sæt cookie, gem tokens server-side).
5. Browseren omdirigeres til appen med kun din session-cookie (ikke hemmeligheden).

Eksempel (konceptuelt)

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

Tilføj PKCE-parametre hvis denne klient er konfigureret som hybrid, eller hvis autoriseringstrinnet brugte PKCE.

Hemmeligheds-lagring

• Indlæs client_secret fra miljøvariabler eller en secret manager.
• Roter hemmeligheder hvis de eksponeres; brug separate credentials pr. miljø.

Ofte stillede spørgsmål

Kan frontenden kalde token-URL’en med secret?

Nej. Alt i browseren kan kopieres. Hold hemmeligheden på serveren.

Vi bruger PKCE i browseren — bruger vi stadig secret?

Afhænger af klienttype og registrering. Hvis browseren startede flowet med PKCE som offentlig klient, bruger udvekslingen måske ikke en secret — bekræft i dit konsol. Hybrid-opsætninger findes; følg jeres tekniske reference.

Næste

Log ud, fejl og fejlfinding.