INTASTELLAR SOLUTIONSHelp Center
Versionv1

Autorisationskode-flowet er det sædvanlige mønster når browseren forlader dit site, brugeren logger ind hos Intastellar, og Intastellar sender dem tilbage til dit site med en engangskode du bytter til tokens.

Denne artikel vs React / ren JS popup-flow

Hvis du bruger @intastellar/signin-sdk-react eller ren HTML/JS-bundlen, kører logind som regel i en popup, og en token kommer via postMessage. I den tilstand bygger du ikke manuelt GET authorize-URL og POST token-forespørgsel.

Brug denne side når dit team implementerer authorize + callback + token (tilpasset stack, visse mobil-opsætninger eller server-drevne web-apps). Til valg af klienttyper først, se Kom godt i gang.

Parameternavne nedenfor følger almindelig OAuth 2.0 / OIDC-brug — bekræft præcise navne, scopes og discovery-URL’er i din Intastellar-registrering og tekniske reference.

Hvad du skal bruge

  • Registreret client ID, redirect URI og (for fortrolige klienter) client secret.
  • Et sikkert sted til at gemme state og PKCE-code_verifier mellem omdirigeringstrin.
  • HTTPS omdirigerings-URI’er i produktion.

Trin 1 — Send brugeren til authorize

Send browseren til autorisationsendepunktet med query-parametre:

ParameterFormål
response_typeBrug code til dette flow.
client_idDit registrerede client ID.
redirect_uriSkal præcist matche en registreret URI.
scopeMellemrumsadskilte scopes (ofte inkl. openid til OIDC).
stateTilfældig, uigættelig værdi; du verificerer den ved retur.
code_challengePKCE: SHA-256-hash af code_verifier, Base64url-kodet (offentlige klienter).
code_challenge_methodTypisk S256.

Eksempel (linjeskift for læsbarhed):

GET AUTHORIZATION_ENDPOINT?
  response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fauth%2Fcallback
  &scope=openid%20profile%20email
  &state=RANDOM_STATE
  &code_challenge=CODE_CHALLENGE
  &code_challenge_method=S256

Gem state og den rå code_verifier (til PKCE) server-side eller i en sikker, kortlivet cookie, så du kan validere dem ved callback.

Trin 2 — Håndter callback

Intastellar omdirigerer til din redirect_uri med:

Query-paramBetydning
codeEngangs autorisationskode.
stateEkko af værdien du sendte; skal matche gemt state.

Hvis brugeren nægter adgang eller der opstår en fejl, kan du modtage error og error_description i stedet — håndter dem uden at behandle dem som succes.

Trin 3 — Udveksl koden til tokens

POST til token-endepunktet (typisk application/x-www-form-urlencoded):

FeltFormål
grant_typeauthorization_code
codeKoden fra callback.
redirect_uriSamme URI som i trin 1.
client_idDit client ID.
code_verifierPKCE: den oprindelige hemmelige verifier (offentlige klienter).
client_secretKun fortrolige klienter.

Svaret indeholder som regel access_token, valgfri refresh_token og et id_token når openid blev anmodet om. Valider ID-token (issuer, audience, udløb, signatur) med JWKS fra issuer, når du stoler på claims i din app.

Sikkerhedstjekliste

  • Aldrig spring state-verifikation over — forebygger CSRF på callback.
  • Brug PKCE for enhver klient der ikke kan holde en client secret (SPA’er, mobil).
  • Brug HTTPS for hver omdirigerings-URI i produktion.
  • Opbevar refresh tokens og client secrets kun på servere du kontrollerer.

Ofte stillede spørgsmål

invalid_grant lige efter callback

Ofte kode allerede brugt, udløbet kode eller redirect_uri / PKCE mismatch. Koder er som regel engangsbrug. Se Log ud, fejl og fejlfinding.

Skal vi bruge PKCE på en ren server-app?

Hvis browseren starter flowet og der ingen hemmelighed er i browseren, ja. Hvis en fortrolig server starter og afslutter alt uden at eksponere hemmeligheden, følg hvad din registrering tillader — brug stadig state.

Næste

Last updated