# Login‑Client anlegen
Diese Anleitung führt Sie durch das Anlegen und die Grundkonfiguration eines Login‑Clients in DocCheck Access.
# Voraussetzungen
- DocCheck User Account
- Firmenaccount in DocCheck Access (opens new window)
- Admin-Rechte
# Login‑Client erstellen und validieren
Info
Login-Clients können immer nur in einem Projekt angelegt werden. In diesem Projekt sollten nur Login-Clients liegen, die mit diesem Projekt zusammenhängen.
Ein erstes Projekt wird immer direkt und automatisch angelegt, nachdem der Firmenaccount erstellt wurde.
Öffnen Sie DocCheck Access (opens new window) und wählen Sie das gewünschte Projekt oder legen Sie ein neues an.
Klicken Sie auf „Neuen Login‑Client anlegen“, füllen Sie die Pflichtfelder aus und speichern Sie. Genauere Beschreibungen zu den Feldern finden Sie weiter unten in der Tabelle Felder im Überblick.
Wenn der Login Client erfolgreich angelegt wurde, finden Sie sich in den Client "Einstellungen" wieder. Dort wird Ihnen ebenfalls angezeigt, ob Ihr Client aktiviert und valide ist.
Sie können die Einstellungen des Clients jederzeit über den Button "Konfigurieren" anpassen.
# Client-Secret erneuern
Sie können das Client-Secret eines Login-Clients selbstständig in DocCheck Access erneuern. Nach dem Generieren eines neuen Secrets bleibt das alte Secret noch für mehrere Stunden gültig. Dadurch können Sie das neue Secret in Ihrer Anwendung austauschen und den Login testen, ohne dass bestehende Integrationen sofort abbrechen.
Wichtig
Behandeln Sie sowohl das alte als auch das neue Client-Secret vertraulich. Das Secret darf nur serverseitig gespeichert und verwendet werden.
# Ablauf
- Öffnen Sie in DocCheck Access (opens new window) die Detailseite des gewünschten Login-Clients.
- Klicken Sie in den Client-Einstellungen auf das Recycle-Icon neben dem Client-Secret.
- Klicken Sie auf „Neu generieren“.
- DocCheck Access generiert ein neues Secret. Das alte Secret bleibt noch wenige Stunden nutzbar.
- Das neue Secret wird mit einem Hinweis auf der Detailseite des Login-Clients angezeigt.
- Tauschen Sie das Secret in Ihrer Anwendung aus.
- Testen Sie anschließend einmal den Login.
Empfehlung
Planen Sie den Austausch so, dass Entwicklung oder Betrieb das neue Secret zeitnah in der Anwendung hinterlegen und den Login direkt testen können.
# Felder im Überblick
| Feld | Beschreibung |
|---|---|
| Projekt | Der Login‑Client gehört immer genau zu einem Projekt. Projekte bündeln fachlich zusammengehörige Clients (z. B. pro Website/Produkt). Ein erstes Standard‑Projekt wird beim Anlegen des Firmenaccounts automatisch erstellt. |
| Umgebung (prod oder dev) | dev: Entwicklungs-/Testumgebung. prod: Produktivumgebung. Wählen Sie die Umgebung zuerst; je nach Umgebung erscheinen weitere Felder/Optionen. |
| Lizenz wählen | Basic:
Unsicher? Zunächst Basic wählen; eine Lizenz kann später zugeordnet/gewechselt werden. Für Personal und Scopes siehe auch Personal, Scopes & Consent. |
| Name | Sprechender, eindeutiger Name zur Wiedererkennung (z. B. „Produkt A – DE – Fachinfos“). |
| Home-URL | Start-/Zielseite des geschützten Bereichs; dient der Orientierung/Dokumentation im UI. |
| Redirect‑URL | Zieladresse für die Rückleitung nach erfolgreichem Login. Dynamische Ziele steuern Sie über state (optional in Kombination mit redirectUri). Details: Redirect- & State-Flow. |
| Vertrauenswürdig | Aktivieren Sie diese Option für vertrauliche Anwendungen mit sicherem Backend. Das client_secret darf dann nur serverseitig gespeichert und verwendet werden. Für Public Clients wie Browser-Apps oder Mobile Apps sollte kein Secret öffentlich ausgeliefert werden. Details: PKCE. |
| CORS für Hostnamen erlauben | Erlaubt JavaScript-Zugriffe von einer bestimmten Browser-Origin auf DocCheck API-Endpunkte. Tragen Sie nur Schema, Host und optional Port ein, z. B. https://example.com oder https://localhost:8080. |
| Datenschutz‑URL | Öffentliche URL zur Datenschutzerklärung (wird im Flow verlinkt). Bei Economy-/Business-Clients sollte die Datenschutzerklärung zu den angefragten Scopes passen. Details: Consent-Formular konfigurieren. |
| Zugänge für folgende Berufsgruppen | Legt fest, welche verifizierten Berufsgruppen den Login‑Client passieren dürfen. Nur Nutzer dieser Gruppen durchlaufen den Login erfolgreich. |
| Legacy-Personal-Scopes verwenden | Bei Business-Clients kann im Button-Konfigurator „Datenset des bisherigen Personal Forms verwenden (Legacy DocCheck CReaM)“ aktiviert werden. Dann werden die bestehenden Legacy-Personal-Scopes aus dem vorherigen DocCheck CReaM verwendet. Eine manuelle Scope-Auswahl ist in diesem Zustand nicht möglich. Um Scopes manuell auszuwählen, entfernen Sie den Haken bei „Legacy-Personal-Scopes verwenden“. Wenn der vollständige Datensatz wie im alten System erhalten bleiben soll, müssen die übernommenen Scopes zusätzlich als Pflicht-Scopes gesetzt werden. Andernfalls kann der Nutzer einzelne optionale Scopes abwählen und das Datenset ist nicht mehr vollständig wie im bisherigen Personal Form. |
# Nächste Schritte
- Basic-Clients: Fahren Sie direkt mit der Button-Implementierung fort. Details: Login Button konfigurieren.
- Economy-/Business-Clients: Prüfen Sie vor der finalen Button-Konfiguration die Consent-Einstellungen. Lizenz, Datenschutz-URL, angefragte Personal-Scopes und Button-Konfiguration greifen hier ineinander. Details: Consent-Formular konfigurieren.