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

Client-ID und Client-Secret

Wofür Client-ID und Client-Secret da sind und wie Ihr Backend sie sendet.

Client-ID

Die „Client-ID“ ist nicht geheim. Die Karte „Anmeldung“ des Frontends zeigt sie jederzeit an, mit einer Schaltfläche „Kopieren“. Sie senden sie:

  • als client_id in der Autorisierungsanfrage, die der Browser stellt;
  • zusammen mit dem Client-Secret, wenn Ihr Backend einen Code eintauscht oder ein Token erneuert;
  • als client_id an die Abmeldeseite.

Außerdem erkennen Sie daran Ihre eigenen Tokens: Jedes Zugriffstoken trägt die client_id, für die es ausgestellt wurde, und Ihr Backend muss sie prüfen (siehe Tokens und Claims).

Client-Secret

Das „Client-Secret“ beweist dem Token-Endpunkt, dass die Anfrage von Ihrem Backend kommt. Das Studio zeigt es einmal an, beim Erstellen des Clients und bei jeder Erneuerung, und speichert es nicht. Kopieren Sie es in den Secret-Speicher Ihres Backends, bevor Sie den Dialog mit „Ich habe das Secret gespeichert“ schließen. Wenn Sie es verlieren, lassen Sie das Secret erneuern.

Senden Sie es nur an POST <auth>/oauth/token, und nur mit HTTP Basic (client_secret_basic), der Methode, mit der der Client registriert ist:

POST <auth>/oauth/token
Authorization: Basic base64(<Client-ID>:<Client-Secret>)
apikey: <Publishable Key>
Content-Type: application/x-www-form-urlencoded

Ein Secret im Formularinhalt wird abgewiesen, obwohl die Discovery client_secret_post nennt.

Öffentliche und vertrauliche Clients

OAuth kennt zwei Arten von Clients. Ein vertraulicher Client hat ein Backend, das ein Geheimnis bewahren kann; ein öffentlicher Client (eine Single-Page-, mobile oder Desktop-App) kann das nicht und weist sich nur mit PKCE aus. Jedes Frontend, das derzeit Benutzer anmelden kann, ist eine Web-App und damit ein vertraulicher Client: Es verwendet das Client-Secret und PKCE. Öffentliche Clients folgen später.

Nicht der Frontend-Schlüssel

Das Client-Secret ist nur für den Token-Endpunkt. Aufrufe der Mitglieder-API authentifizieren sich mit dem Frontend-Schlüssel des Frontends, einem eigenen Geheimnis, das auf der Karte „Schlüssel“ ausgestellt wird (siehe Frontend-Schlüssel).