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

Login with appsolut

Frontend-Benutzer mit OAuth 2.1 und OpenID Connect anmelden.

Login with appsolut ist die eine Anmeldung für alle Frontends einer Organisation. Ihr Frontend schickt den Browser zum OAuth-2.1-Server des Studios; die Anmeldeseiten im Branding der Organisation melden die Person an oder registrieren sie, führen die Mitgliedschaftsprüfung durch und schicken sie mit einem Autorisierungscode zurück; Ihr Backend tauscht den Code gegen Tokens ein.

Das Konto einer Person bei einer Organisation ist ein Frontend-Benutzer. Dieselbe Person bei zwei Organisationen sind zwei voneinander unabhängige Frontend-Benutzer, und ein Frontend-Benutzer ist nie ein Studio-Benutzer. Die erste Anmeldung macht ihn außerdem zum Mitglied, wo das Frontend danach fragt.

Das Protokoll in Kürze

  • Authorization Code mit PKCE, wie in OAuth 2.1, mit der PKCE-Methode S256 und nur dem Scope openid.
  • Ein vertraulicher Client: Ihr Backend authentifiziert sich am Token-Endpunkt mit HTTP Basic.
  • Tokens sind JWTs, signiert mit dem Schlüssel aus JWKS. Das Zugriffstoken trägt E-Mail-Adresse und Namen des Benutzers, die Organisation (tenant_id) und die Frontend-Rolle (frontend_role); ID-Token und UserInfo tragen nur sub.

OIDC-Discovery

Lesen Sie die Konfiguration einmal aus Ihrem Backend:

GET <auth>/.well-known/openid-configuration
apikey: <Publishable Key>

Die Discovery nennt mehr, als Sie verwenden dürfen. Sie listet die PKCE-Methode plain, die Client-Authentifizierungsmethoden client_secret_post und none, den Signaturalgorithmus HS256 und die Scopes email, profile, phone und offline_access. Verwenden Sie nur, was diese Seiten nennen: PKCE S256, client_secret_basic, den Scope openid und den Algorithmus des Schlüssels in JWKS.

Bevor Sie beginnen

Sie brauchen Client-ID und Secret (siehe OAuth-Clients), die zwei Ursprünge <auth> und <studio> mit dem Publishable Key (siehe Umgebungen und Endpunkte) und die ID der Organisation, um tenant_id zu prüfen.

In diesem Abschnitt

  • Authorization-Code-Flow: Start, Anmeldung, Callback und Refresh, mit den Regeln dahinter.
  • Tokens und Claims: was die Tokens tragen und wie Sie sie prüfen.
  • Frontend-Rolle: was frontend_role sagt und wann sie sich ändert.
  • Abmeldung: einen Benutzer in zwei Schritten abmelden.
  • Widerruf und ausgestellte Tokens: was eine Sitzung beendet und was ein bereits ausgestelltes Token noch kann.
  • Fehler des Token-Endpunkts: die Antworten, die ein Code-Tausch oder ein Refresh erhalten kann.