DocID®DocID®-Dokumentation
Zurück zu DocID®
  • Übersicht

    • DocID®-Dokumentation
  • Einführung

    • Einführung
    • So funktioniert DocID®
    • Grundbegriffe
  • Erste Schritte

    • Erste Schritte
    • Drupal-Modul
    • WordPress-Plugin
    • Individuelle Website
    • Go-live-Checkliste
  • Funktionen

    • Funktionen
    • Standard Login
    • Zugang und Personalisierung
    • Analytics
    • Campaigns
  • Lizenzen

    • Lizenzen
  • OAuth 2.0

    • OAuth 2.0
    • Client konfigurieren
    • Authorization Code Flow
    • Scopes und UserInfo
    • Sicherheit und Umgebungen
  • API

    • API
  • Hilfe

    • Fehlerbehebung

Erste Schritte

Individuelle Website

Bereiten Sie eine serverseitig gerenderte Website oder Webanwendung für DocID® OAuth vor.

Verwenden Sie eine individuelle Integration, wenn Ihre Plattform weder auf Drupal noch auf WordPress basiert oder Sie direkte Kontrolle über Sessions, Routing und profilbasiertes Verhalten benötigen.

Voraussetzungen

  • Ein Backend, das Credentials und Tokens geheim halten kann
  • HTTPS Callback Routes
  • Ein serverseitiger Session-Mechanismus
  • Ein DocID® Client für jede Umgebung

Zwei Application Routes erstellen

Ihre Anwendung benötigt in der Regel:

  1. eine Login Route, die state, nonce und die PKCE-Werte erzeugt, bevor sie zu DocID® weiterleitet
  2. eine Callback Route, die die Response validiert, den Code austauscht, die freigegebenen Claims liest und eine lokale Session erstellt

Speichern Sie temporäre Authorization-Daten in einem signierten, HTTP-only, Secure, SameSite Cookie oder in einem serverseitigen Transaction Store.

Authorization anfordern

Leiten Sie den Browser zu /oauth2/authorize weiter und übergeben Sie:

1response_type=code2client_id=YOUR_CLIENT_ID3redirect_uri=https://your-domain.example/auth/docid/callback4scope=openid professional5state=RANDOM_UNGUESSABLE_VALUE6nonce=RANDOM_UNGUESSABLE_VALUE7code_challenge=BASE64URL_SHA256_CODE_VERIFIER8code_challenge_method=S256

Callback verarbeiten

Auf dem Server:

  1. Callbacks mit fehlendem oder abweichendem state ablehnen.
  2. Eine OAuth error Response behandeln, ohne dem Nutzer technische Details offenzulegen.
  3. Den Authorization Code bei /oauth2/token austauschen.
  4. Den ursprünglichen code_verifier mitsenden.
  5. Mit dem Access Token /oauth2/userinfo aufrufen.
  6. sub dem lokalen Konto oder der Session zuordnen.
  7. Die temporären OAuth Transaction Data entfernen.

Vollständigen OAuth-2.0-Flow ansehen

ZurückWordPress-PluginWeiterGo-live-Checkliste

Auf dieser Seite

  1. Voraussetzungen
  2. Zwei Application Routes erstellen
  3. Authorization anfordern
  4. Callback verarbeiten