Single-page applications kunnen geen client secret veilig opslaan. Gebruik de authorization code flow alleen met PKCE, of het officiële @intastellar/signin-sdk-react-pakket als u React target en Intastellar dat voor uw client ondersteunt — de SDK gebruikt een popup en tokenverificatie in plaats van zelf de authorize-URL en token-POST te bedraden.
Voor React- en vanilla JS-patronen (alleen placeholder-voorbeelden), zie Intastellar Sign-In — React-SDK en plat JavaScript.
Flow-samenvatting (handmatige code + PKCE)
- Genereer
code_verifier(hoog-entropie willekeurige string) en leidcode_challengeaf (S256). - Bewaar
code_verifierwaar u het bij callback kunt lezen — bijv.sessionStoragevoor het tabblad, of een versleutelde cookie via een kleine BFF. - Redirect naar
AUTHORIZATION_ENDPOINTmetcode_challenge/code_challenge_method=S256. - Bij callback stuurt u
code+code_verifiernaar uw backend (aanbevolen) of naar het token endpoint als het product publieke clients zonder secret toestaat (bevestig in console).
Geef de voorkeur aan een backend-for-frontend (BFF)
Zelfs in een SPA zijn token-uitwisseling en refresh veiliger op een same-origin API:
- De browser krijgt alleen een opaque sessiecookie van uw API.
- Refresh tokens raken nooit
localStorage. - CORS en CSRF zijn op uw domein te beheersen.
Als u tokens volledig in de browser moet afhandelen, minimaliseer de levensduur, vermijd localStorage voor refresh tokens en plan XSS als volledige compromittering van de sessie.
CORS en iframes
Embed de Intastellar-aanmeld-UI niet in een verborgen iframe tenzij het product expliciet stille of embedded flows ondersteunt. Geef de voorkeur aan full-page redirect voor aan- en afmelden.
Volgende
Server-side (vertrouwelijke) clients als u ook een traditionele backend serveert.
Last updated