Mit einem vertrauenswürdigen Server (Node, .NET, PHP usw.) führen Sie den Token-Austausch dort aus, damit das Client-Secret nie im Browser ankommt.

Das passt zu eigenen OAuth-Code-Setups. React-SDK und Plain-JS-Popup sind getrennt — Intastellar Sign-In — React und JavaScript.

Ablauf

1. Browser schließt Redirect ab und landet mit code und state auf Ihrem Callback.
2. Callback-Route prüft state, ruft Backend auf (oder läuft serverseitig im selben Request), um den Code zu tauschen.
3. Backend POST auf TOKEN_ENDPOINT mit grant_type=authorization_code, code, redirect_uri, client_id, client_secret.
4. Backend legt Session an (Cookie, Tokens serverseitig).
5. Browser erhält nur Ihr Session-Cookie (nicht das Secret).

Beispiel (konzeptionell)

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

PKCE-Parameter ergänzen, wenn der Authorization-Schritt PKCE nutzte oder der Client hybrid ist.

Secret-Aufbewahrung

• client_secret aus Umgebungsvariablen oder Secret-Manager.
• Bei Leak rotieren; getrennte Credentials pro Umgebung.

Häufige Fragen

Darf das Front-End den Token-Endpunkt mit Secret aufrufen?

Nein. Alles im Browser kann kopiert werden.

Wir nutzen PKCE im Browser — brauchen wir trotzdem das Secret?

Hängt von Client-Typ und Registrierung ab. Öffentlicher Client mit PKCE tauscht oft ohne Secret — Konsole/Referenz prüfen.

Nächste Schritte

Abmelden, Fehler und Fehlersuche.