Single-Page-Anwendungen können ein Client-Secret im Browser nicht sicher speichern. Nutzen Sie den Authorization-Code-Flow mit PKCE, oder das offizielle @intastellar/signin-sdk-react, wenn Sie React nutzen und Ihr Client dafür eingerichtet ist — das SDK nutzt Popup und Verifizierung statt manuellem Authorize- und Token-POST.

Konkrete React- und Vanilla-Muster (nur Platzhalter): Intastellar Sign-In — React und JavaScript.

Flow-Kurzfassung (manueller Code + PKCE)

1. code_verifier erzeugen und code_challenge (S256) ableiten.
2. code_verifier speichern (z. B. sessionStorage oder verschlüsseltes Cookie via kleinem BFF).
3. Redirect zu AUTHORIZATION_ENDPOINT mit code_challenge / code_challenge_method=S256.
4. Im Callback code + code_verifier ans Backend senden (empfohlen) oder direkt an den Token-Endpunkt, wenn Ihr Produkt das ohne Secret erlaubt (Konsole prüfen).

Backend-for-Frontend (BFF) bevorzugen

Auch in SPAs sind Token-Austausch und Refresh sicherer auf einer Same-Origin-API:

• Browser erhält nur ein opakes Session-Cookie von Ihrer API.
• Refresh-Tokens nicht in localStorage.
• CORS und CSRF besser kontrollierbar.

Wenn Tokens komplett im Browser: kurze Lebensdauer, kein Refresh in localStorage, XSS = voller Kompromiss.

CORS und iframes

Intastellar-Login nicht in verstecktem iframe einbetten, außer stille/embedded-Flows sind explizit unterstützt. Vollständiger Seiten-Redirect für An- und Abmeldung bevorzugen.

Häufige Fragen

Ist das React-Popup dasselbe wie PKCE-Redirect?

Nein. SDK-Popup ist ein anderer Integrationsstil. Diese Seite betrifft Redirect + PKCE, wenn Sie den Flow selbst bauen.

„CORS-Fehler“ beim Token-Endpunkt aus JavaScript

Oft beabsichtigt — viele Token-Endpunkte sind nicht für direkten Browser-Call gedacht. Backend oder BFF nutzen.

Nächste Schritte

Serverseitig (vertrauliche Clients), wenn Sie zusätzlich ein klassisches Backend mit Secret betreiben.