Der Authorization-Code-Flow ist das übliche Muster, wenn der Browser Ihre Site verlässt, der Nutzer bei Intastellar angemeldet wird und Intastellar mit einem Einmal-Code zurück auf Ihre Site leitet, den Sie gegen Tokens eintauschen.
Dieses Handbuch vs. React-/Plain-JS-Popup
Mit @intastellar/signin-sdk-react oder dem Plain-HTML/JS-Bundle läuft Anmeldung meist im Popup; ein Token kommt per postMessage. In diesem Modus bauen Sie keine manuelle GET-Authorize-URL und keinen Token-POST.
Nutzen Sie diese Seite, wenn Ihr Team Authorize + Callback + Token selbst implementiert (eigener Stack, manche Mobile-Setups, servergetriebene Web-Apps). Zur Client-Wahl zuerst Erste Schritte.
Parameternamen folgen üblichem OAuth 2.0 / OIDC — exakte Namen, Scopes und Discovery-URLs in Ihrer Registrierung und Referenz bestätigen.
Voraussetzungen
- Registrierte Client-ID, Redirect-URI und (bei vertraulichen Clients) Client-Secret.
- Sicherer Speicher für
stateund PKCE-code_verifierzwischen den Redirects. - HTTPS-Redirect-URIs in Produktion.
Schritt 1 — Nutzer zur Authorisierung schicken
Browser zum Authorization-Endpunkt mit Query-Parametern:
| Parameter | Zweck |
|---|---|
response_type | code für diesen Flow. |
client_id | Ihre Client-ID. |
redirect_uri | Muss exakt einer registrierten URI entsprechen. |
scope | Scopes, Leerzeichen-getrennt (oft openid für OIDC). |
state | Zufälliger, nicht erratbarer Wert; bei Rückkehr prüfen. |
code_challenge | PKCE: SHA-256 von code_verifier, Base64url. |
code_challenge_method | Typisch S256. |
Beispiel (Zeilenumbrüche der Lesbarkeit wegen):
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=S256Speichern Sie state und den rohen code_verifier serverseitig oder in einem sicheren, kurzlebigen Cookie für den Callback.
Schritt 2 — Callback verarbeiten
Intastellar leitet zu redirect_uri mit:
| Query-Parameter | Bedeutung |
|---|---|
code | Einmaliger Authorization-Code. |
state | Echo Ihres Werts; muss zum gespeicherten state passen. |
Bei Ablehnung oder Fehler können error und error_description kommen — nicht als Erfolg behandeln.
Schritt 3 — Code gegen Tokens tauschen
POST an den Token-Endpunkt (typisch application/x-www-form-urlencoded):
| Feld | Zweck |
|---|---|
grant_type | authorization_code |
code | Code aus dem Callback. |
redirect_uri | dieselbe URI wie in Schritt 1. |
client_id | Ihre Client-ID. |
code_verifier | PKCE: ursprünglicher Verifier (öffentliche Clients). |
client_secret | Nur vertrauliche Clients. |
Die Antwort enthält meist access_token, optional refresh_token und bei openid ein id_token. ID-Token validieren (iss, aud, exp, Signatur, JWKS), wenn Sie auf Claims vertrauen.
Sicherheits-Checkliste
statenie weglassen — schützt vor CSRF am Callback.- PKCE, wenn kein Secret im Client (SPA, mobil).
- HTTPS für alle Redirect-URIs in Produktion.
- Refresh-Tokens und Secrets nur auf kontrollierten Servern.
Häufige Fragen
invalid_grant direkt nach dem Callback
Oft Code schon verbraucht, abgelaufen oder redirect_uri/PKCE-Mismatch. Codes sind meist einmalig. Siehe Abmelden, Fehler und Fehlersuche.
Brauchen wir PKCE bei rein serverseitiger App?
Wenn der Browser startet und kein Secret im Browser liegt: ja. Bei vertraulichem Server-Flow ohne Secret im Browser: nach Registrierung richten — state trotzdem nutzen.
Nächste Schritte
Last updated