Intastellar Developers
Versionv1

Betragt cookies og tokens i tre lag: Intastellar-hostet (login-UI), dit sites origin (SDK eller egen session) og dit backend (opake sessioner, verifikation).

På dit sites origin

Når du bruger @intastellar/signin-sdk-react eller et vanilla-flow der spejler det, kan integrationen efter login sætte first-party-cookies, så fanen husker brugeren. Eksakte navne og semantik er defineret af SDK’et og Intastellars dokumentation (npm readme, Plain HTML, CSS og JavaScript) — antag ikke de matcher et andet projekts deployment.

Din applikationskode bør behandle dem som SDK-styrede medmindre Intastellar siger andet.

Kører du backend eller BFF, foretræk:

  1. Opak session-id i et HttpOnly, Secure-cookie med SameSite der passer til din topologi.
  2. Serverside store der mapper id til bruger-id, udløb og refresh-håndtering.
  3. Opret eller forny den session først efter din server stoler på login-resultatet (f.eks. token-validering ifølge din integrationsguide).

Se integrering af React og JavaScript for et overordnet mønster „valgfri serversession“ med kun eksempel-URL’er.

På Intastellar-kontrollerede værter

Mens brugeren logger ind hos Intastellar, kan identity-værten sætte egne cookies (SSO, session). De er ikke læsbare fra dit origins JavaScript. Stol på tokens, din session eller SDK’et — ikke på at læse IdP-cookies på tværs af sites.

ID-token vs. access-token

Ved OAuth-lignende token-svar (manuel code-flow):

  • ID-token — JWT om autentificeringshændelsen; valider iss, aud, exp, signatur (og nonce hvis brugt).
  • Access-token — kald API’er; behandl som opak medmindre du skal parse det.

Log ud

Ryd din session og følg SDK- / Intastellar-vejledning til logout. Hvis en end-session-URL findes, kan redirect dertil rydde IdP SSO-cookies på identity-domænet. Se Log ud, fejl og fejlfinding.

Næste

Last updated