Dokumentation/Entwickler
Zurück
  • Erste Schritte
    • Frontends und App-Typen
    • Umgebungen und Endpunkte
  • OAuth-Clients
    • Client-ID und Client-Secret
    • Redirect-URIs und Start-URL
    • Secret erneuern
  • Login with appsolut
    • Authorization-Code-Flow
    • Tokens und Claims
    • Frontend-Rolle
    • Abmeldung
    • Widerruf und ausgestellte Tokens
    • Fehler des Token-Endpunkts
  • Frontend-Schlüssel
    • Einen Schlüssel ausstellen und aufbewahren
    • Einen Schlüssel senden
    • Wechseln und widerrufen
  • Mitglieder-API
    • Berechtigung aus einem Backend
    • Das angemeldete Mitglied
    • Ergebnisse, Ratenlimits und Fehler
    • Ist ein Antragsteller ein berechtigtes Mitglied?
    • Die Mitgliedschaft des angemeldeten Frontend-Benutzers
  • appsolut Register-API
    • Die API umsetzen
    • Anbinden und testen
    • Ein Mitglied mit seinem Prüfcode verifizieren
    • Alle Mitglieder auflisten
    • Der Status mehrerer Mitglieder
    • Der Status eines Mitglieds
    • Die Personendaten mehrerer Mitglieder
    • Die Personendaten eines Mitglieds
    • Die Claims mehrerer Mitglieder
    • Die Claims eines Mitglieds
    • Health-Check

Tokens und Claims

Was das Zugriffstoken trägt, wie Sie es prüfen und wofür es nicht da ist.

Das Zugriffstoken

Ein JWT für Ihr Backend. Ein dekodiertes Beispiel mit erfundenen Werten:

{
  "iss": "https://example-project.supabase.co/auth/v1",
  "sub": "3f0c9a52-7d1e-4b8a-9c6f-2e5d8b1a4c70",
  "aud": "authenticated",
  "iat": 1792682619,
  "exp": 1792686219,
  "client_id": "9d4b7c1e-3a2f-4e5d-8b6a-7c0f1e2d3a4b",
  "scope": "openid",
  "tenant_id": "c2a8e6f4-1b3d-4f5a-9e7c-0d2b4f6a8c1e",
  "frontend_role": "member",
  "email": "anna.berger@pannoniqa.example",
  "given_name": "Anna",
  "family_name": "Berger",
  "role": "frontend_user",
  "user_metadata": {},
  "phone": ""
}

Lesen Sie diese Claims:

ClaimBedeutung
subDer Frontend-Benutzer, stabil für die Lebensdauer des Kontos. Führen Sie Ihre Benutzer unter diesem Wert. Dieselbe Person hat bei zwei Organisationen zwei unabhängige sub.
tenant_idDie Organisation, zu der der Benutzer gehört.
client_idDas Frontend, für das das Token ausgestellt wurde.
scopeImmer openid.
frontend_roleauthenticated oder member (siehe Frontend-Rolle). Nur auf diesen OAuth-Tokens.
emailDie echte, bestätigte Adresse des Benutzers, in Kleinbuchstaben. Sie kann sich ändern; führen Sie einen Benutzer nie unter ihr.
given_name, family_nameDie Namen, die der Benutzer bei der Registrierung angegeben hat.
iss, aud, exp, iatStandard-Claims eines JWT. aud ist für das Token jedes Frontends authenticated.

Lesen Sie die anderen nie:

  • role ist die Datenbank-Rolle (frontend_user), nicht die Frontend-Rolle.
  • user_metadata ist immer {} und phone immer "".
  • app_metadata, session_id, aal, amr und is_anonymous gehören dem Auth-Server. Nehmen Sie die Organisation aus dem tenant_id der obersten Ebene.

Prüfen Sie jedes Zugriffstoken, bevor Sie ihm vertrauen

  1. Prüfen Sie die Signatur gegen die Schlüssel von <auth>/.well-known/jwks.json. Speichern Sie sie zwischen und laden Sie sie bei einer unbekannten kid neu. Akzeptieren Sie nur den Algorithmus des Schlüssels in JWKS; nie HS256 oder none.
  2. Prüfen Sie iss gegen den Issuer aus der Discovery, exp und aud authenticated.
  3. Prüfen Sie, dass client_id Ihre eigene Client-ID ist. aud ist für jedes Frontend gleich, nur client_id bindet ein Token und seine frontend_role an Ihr Frontend. Ohne diese Prüfung akzeptiert Ihr Backend ein Token, das ein anderes Frontend der Organisation erhalten hat, mit dessen member, und das kann eine andere Community bedeuten.
  4. Prüfen Sie, dass tenant_id Ihre Organisation ist.
  5. Erst dann lesen Sie frontend_role, sub, email und die Namen.

Wofür das Zugriffstoken nicht da ist

  • Senden Sie es nie als Bearer-Token an das Studio. Das Studio weist jedes Authorization: Bearer mit einem Zugriffstoken ab, und die Mitglieder-API authentifiziert Ihr Backend über seinen Frontend-Schlüssel. Die einzige Ausnahme ist GET /api/v1/members/me, das das Token zusätzlich zum Schlüssel in einem eigenen Header nimmt (siehe Das angemeldete Mitglied).
  • Senden Sie es nie an die Datenbank-, Storage- oder GraphQL-APIs des Projekts. Es trägt die Datenbankrolle frontend_user, die dort auf nichts zugreifen darf.
  • Rufen Sie damit nie GET <auth>/user (oder einen anderen <auth>/user-Endpunkt) auf: Er antwortet mit der internen technischen Adresse des Kontos, nicht mit der echten E-Mail-Adresse. Außer an /oauth/userinfo senden Sie es überhaupt nie an <auth>.
  • Behalten Sie es auf Ihrem Server. Geben Sie Zugriffs- oder Refresh-Token nie an den Browser weiter.

ID-Token und UserInfo

Beide tragen über den Benutzer nur sub, weil der Scope allein openid ist. Das ID-Token trägt außerdem die Standard-Claims iss, aud, exp und iat und Ihre nonce, falls Sie eine gesendet haben. Alles andere steht im Zugriffstoken.