INTASTELLAR SOLUTIONSHelp Center
Versionv1

De authorization code-flow is het gebruikelijke patroon waarbij de browser je site verlaat, de gebruiker zich bij Intastellar aanmeldt en Intastellar ze terugstuurt naar je site met een eenmalige code die je inwisselt voor tokens.

Deze handleiding versus de React- / platte JS-pop-upflow

Als je @intastellar/signin-sdk-react of het platte HTML/JS-bundelpad gebruikt, loopt aanmelden meestal in een pop-up en komt een token binnen via postMessage. In die modus hoef je niet handmatig de GET authorize-URL en POST token-request op te bouwen.

Gebruik deze pagina als jouw team authorize + callback + token implementeert (eigen stack, sommige mobiele opzetten of server-gestuurde webapps). Voor het eerst clienttypen kiezen, zie Aan de slag.

Parameternamen hieronder volgen gangbare OAuth 2.0 / OIDC-gebruik — bevestig exacte namen, scopes en discovery-URL’s in jouw Intastellar-registratie en technische referentie.

Wat je nodig hebt

  • Geregistreerde client ID, redirect-URI en (voor vertrouwelijke clients) client secret.
  • Een veilige plek om state en de PKCE-code_verifier tussen redirectstappen op te slaan.
  • HTTPS-redirect-URI’s in productie.

Stap 1 — Stuur de gebruiker naar authorize

Stuur de browser naar het authorization endpoint met queryparameters:

ParameterDoel
response_typeGebruik code voor deze flow.
client_idJe geregistreerde client ID.
redirect_uriMoet exact overeenkomen met een geregistreerde URI.
scopeSpaties-gescheiden scopes (bevat vaak openid voor OIDC).
stateWillekeurige, niet te raden waarde; je controleert die bij terugkeer.
code_challengePKCE: SHA-256-hash van code_verifier, Base64url-gecodeerd (publieke clients).
code_challenge_methodMeestal S256.

Voorbeeld (regelafbrekingen voor leesbaarheid):

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

Bewaar state en de ruwe code_verifier (voor PKCE) server-side of in een veilige, kortlevende cookie zodat je ze bij de callback kunt valideren.

Stap 2 — Verwerk de callback

Intastellar redirect naar je redirect_uri met:

QueryparamBetekenis
codeEenmalige authorization code.
stateEcho van de waarde die je stuurde; moet overeenkomen met opgeslagen state.

Als de gebruiker toegang weigert of er een fout optreedt, kun je error en error_description krijgen — verwerk die zonder ze als succes te behandelen.

Stap 3 — Wissel de code in voor tokens

POST naar het token endpoint (meestal application/x-www-form-urlencoded):

VeldDoel
grant_typeauthorization_code
codeDe code uit de callback.
redirect_uriDezelfde URI als in stap 1.
client_idJe client ID.
code_verifierPKCE: de oorspronkelijke secret verifier (publieke clients).
client_secretAlleen vertrouwelijke clients.

Het antwoord bevat meestal access_token, optioneel refresh_token en een id_token als openid was gevraagd. Valideer de ID token (issuer, audience, verloop, handtekening) met JWKS van de issuer als je op claims in je app vertrouwt.

Security-checklist

  • Sla state-verificatie nooit over — voorkomt CSRF op de callback.
  • Gebruik PKCE voor elke client die geen client secret kan bewaren (SPA’s, mobiel).
  • Gebruik HTTPS voor elke redirect-URI in productie.
  • Houd refresh tokens en client secrets alleen op servers die jij beheert.

Veelgestelde vragen

invalid_grant direct na de callback

Vaak code al gebruikt, verlopen code of redirect_uri / PKCE-mismatch. Codes zijn meestal eenmalig. Zie Afmelden, fouten en probleemoplossing.

Hebben we PKCE nodig op een puur server-app?

Als de browser de flow start en er geen secret in de browser zit, ja. Als een vertrouwelijke server alles start en afrondt zonder het secret bloot te geven, volg wat je registratie toestaat — gebruik nog steeds state.

Volgende

Last updated