Biometrische Bestätigung für KI-API-Zugriff: Privilegien an eine Person binden (DE)

Die Verifizierung beim Onboarding beweist, wer ein Konto erstellt hat. Sie beweist nichts darüber, wer es jetzt nutzt.

Diese Lücke ist in den meisten Produkten gewöhnlich und auf einer KI-Plattform, wo die Assets hinter dem Konto Modellzugriff, Credits und Kontingente sind, von Bedeutung. Ein API-Schlüssel ist ein Bearer-Token – wer ihn besitzt, ist das Konto. Schlüssel werden innerhalb von Teams geteilt, in Repositories eingefügt, verkauft und übernommen. Sechs Monate nach einem sauberen Onboarding ist „dieses Konto wurde verifiziert“ eine Aussage über die Vergangenheit.

Biometrische Authentifizierung schließt diese Lücke. Sie verifiziert den tatsächlichen Menschen im Moment einer privilegierten Aktion erneut – keine Dokumente, kein Passwort, unter zwei Sekunden, 0,10 $ pro Authentifizierung.

Wichtige Erkenntnisse

• Die Onboarding-Verifizierung ist eine Momentaufnahme. Biometrische Authentifizierung ist eine Prüfung im entscheidenden Moment.
• Liveness plus Gesichtsabgleich mit dem bereits gespeicherten Porträt aus der ursprünglichen Verifizierung des Benutzers. Keine Dokumente, kein Passwort.
• Nur für die Sitzung. Es gibt keinen /v3/biometric-auth/ Endpunkt – es läuft über eine Sitzung mit workflow_type=BIOMETRIC_AUTHENTICATION.
• Das entscheidende Implementierungsdetail: Verwenden Sie die gleichen vendor_data wie bei der ursprünglichen Verifizierung des Benutzers, sonst kann das gespeicherte Gesicht nicht abgerufen werden.
• Richtige Auslöser: Kontingenterhöhungen, Kreditvergaben, Ausgabe neuer API-Schlüssel, Tier-Upgrades, Hinzufügen privilegierter Teammitglieder und jede Verhaltenswarnung von Ihrer Traffic-Ebene.
• 0,10 $ pro Authentifizierung, Pay-per-Success, unter zwei Sekunden.

Warum die Re-Authentifizierung auf eine KI-Plattform gehört

Drei Fehlerursachen machen die Onboarding-Momentaufnahme unzureichend.

Schlüsselteilung und Weiterverkauf. Ein an einen verifizierten Entwickler ausgegebener Schlüssel kann überall landen. Das Konto bleibt verifiziert; die Person, die es verwendet, ist nicht die Person, die es verifiziert hat. Dies ist der Mechanismus, durch den ein legitim verifiziertes Konto zu einem Einstiegspunkt in ein gefarmtes Netzwerk wird – und es ist für jede Kontrolle, die nur das Onboarding berücksichtigt, unsichtbar.

Kontoübernahme. Anmeldeinformationen werden gephisht oder gestopft, und der Angreifer erbt ein verifiziertes Konto mit etabliertem Ruf und erhöhten Limits. Ein verifiziertes Konto ist ein attraktiveres Übernahmeziel, kein weniger attraktives.

Eskalation im Nachhinein. Das Konto, das im Januar für bescheidenen Zugang verifiziert wurde, beantragt im August eine 50-fache Kontingenterhöhung. Nichts an der Januar-Verifizierung spricht für den August-Antrag.

In allen drei Fällen ist der Verifizierungsstatus des Kontos unverändert, und die Person dahinter ist nicht die, die Sie vermuten. Ein Passwort, ein Einmalcode oder ein Sitzungstoken können diese Fälle nicht unterscheiden, da jeder von ihnen ein Angreifer ist, der die Anmeldeinformationen legitim besitzt. Nur eine biometrische Prüfung stellt die entscheidende Frage: Ist die jetzt anwesende Person die Person, die verifiziert wurde?

Funktionsweise

Die biometrische Authentifizierung verwendet dieselben LivenessV3- und FaceMatchV3-Komponenten wie der reguläre Identitätsfluss. Der einzige Unterschied besteht darin, woher das Referenzbild stammt – anstelle des Porträts auf einem frisch eingereichten Dokument verwendet es das bereits gespeicherte Porträt aus der vorherigen Verifizierung des Benutzers.

Deshalb benötigt es keine Dokumente und ist schnell und günstig genug, um in einen normalen Produktfluss integriert zu werden.

Es ist nur für die Sitzung

Es gibt keinen dedizierten /v3/biometric-auth/ Endpunkt. Die Authentifizierung erfolgt über eine Sitzung, deren Workflow dafür konfiguriert ist – workflow_type=BIOMETRIC_AUTHENTICATION. Wenn Sie in der API-Referenz nach einem eigenständigen Endpunkt suchen, ist dies der Grund, warum Sie keinen finden können.

Der Ablauf

1. Konfigurieren Sie einen Workflow vom Typ BIOMETRIC_AUTHENTICATION in der Konsole und notieren Sie dessen workflow_id.
2. Erstellen Sie eine Sitzung:

curl -X POST 'https://verification.didit.me/v3/session/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "YOUR_BIOMETRIC_AUTH_WORKFLOW_ID",
    "vendor_data": "acct_8842",
    "callback": "https://yourplatform.example/auth/complete"
  }'

1. Senden Sie den Benutzer durch die zurückgegebene Sitzung – gehostet oder eingebettet mit einem der kostenlosen SDKs.
2. Rufen Sie die Entscheidung ab:

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

Oder abonnieren Sie session.status.updated und verwenden Sie den Webhook.

Das eine Detail, das Integrationen zum Scheitern bringt

Verwenden Sie dieselben vendor_data wie bei der ursprünglichen Verifizierung des Benutzers.

Dieser Wert ist der Weg, wie Didit das gespeicherte Porträt zum Abgleich abruft. Eine neue oder andere vendor_data bedeutet, dass kein gespeichertes Gesicht zum Vergleich vorhanden ist, und der Ablauf kann nicht das tun, was Sie angefordert haben. Wenn Sie die gespeicherte Referenz absichtlich überschreiben müssen, übergeben Sie portrait_image explizit – aber der normale Pfad ist eine stabile vendor_data pro Konto, die beim Onboarding festgelegt und für immer wiederverwendet wird.

Dies ist das Argument dafür, vendor_data von Anfang an als erstklassigen Bezeichner in Ihrem eigenen Schema zu behandeln. Es ist auch das, was Face Search-Ergebnisse sauber Ihren Konten zuordnet.

Das Ergebnis lesen

Die Ergebnisse werden in liveness_checks und face_matches geliefert. Beide sind immer Arrays – niemals einzelne Objekte – und jedes Element trägt eine node_id, damit Workflows mit mehreren Instanzen Schritte eindeutig identifizieren können. Jedes ist null, bis sein Schritt Daten produziert hat.

Warnungen umfassen LOW_LIVENESS_SCORE, Gesichtsangriffswarnungen, Blacklist-Treffer und geringe Gesichtsabgleichsähnlichkeit. Schwellenwerte und Ablehnungsaktionen sind konfigurierbar, sodass Sie für eine große Kreditvergabe strengere Maßstäbe anlegen können als für eine routinemäßige Kontingenterhöhung.

Was eine Step-Up-Authentifizierung auslösen sollte

Der Wert dieser Kontrolle hängt fast ausschließlich vom Auslöserdesign ab. Zu viele, und Sie haben eine Belästigung geschaffen; zu wenige, und sie wird nie ausgelöst, wenn es darauf ankommt.

Zugriffs-Eskalation – Kontingenterhöhungen, Kreditvergaben, Ausgabe neuer API-Schlüssel, Tier-Upgrades, Wechsel zu einer Fähigkeitsstufe, die Sie als sensibel betrachten.

Kontoänderungen – ein neues privilegiertes Teammitglied, eine Änderung des Rechnungsinhabers, eine Änderung des Auszahlungsziels, ein Passwort- oder MFA-Reset.

Verhaltenswarnungen – der wertvollste Auslöser. Wenn Ihre eigene Traffic-Ebene ein Konto wegen konzentrierter Abfragen oder eines destillationsförmigen Musters kennzeichnet, stellt eine biometrische Step-Up-Authentifizierung die eine Frage, die die Traffic-Ebene nicht beantworten kann: Ist die verifizierte Person immer noch diejenige, die dieses Konto bedient? Ein Bestehen schränkt die Interpretation ein. Ein Scheitern oder ein Abbruch ist selbst ein starkes Signal.

Verknüpfungssignale – eine Sitzung, die DEVICE_RECOVERED_HIGH_CONFIDENCE enthält, oder ein Gesicht, das mit einem bestehenden verifizierten Benutzer übereinstimmt, hat unabhängig davon, was das Konto anfordert, eine Step-Up-Authentifizierung verdient.

Ruhezustand plus Eskalation – ein Konto, das monatelang still war und plötzlich eine große Erhöhung anfordert. Nicht nur der Ruhezustand; die Kombination.

Warum nicht einfach ein Passwort oder einen Code verlangen?

Weil jeder herkömmliche Faktor ein Bearer-Credential ist und das Bedrohungsmodell hier ein Angreifer ist, der das Credential besitzt.

Ein Einmalcode geht an die hinterlegte Telefonnummer oder Adresse – die der Angreifer nach einer Übernahme kontrolliert und die der legitime Schlüssel-Teiler einfach weiterleitet. Ein Passwort beweist die Kenntnis einer Zeichenfolge. Ein Hardware-Schlüssel beweist den Besitz eines Objekts, das mit dem Schlüssel übergeben werden kann.

Ein liveness-geprüfter Gesichtsabgleich beweist, dass eine bestimmte Person in diesem Moment anwesend ist. Um Privilegien an eine Person zu binden, ist dies der einzige Faktor, der die eigentliche Frage beantwortet. Mit 0,10 $ und unter zwei Sekunden ist es auch günstig genug, um bei echten Auslösern eingesetzt zu werden, anstatt es für Notfälle aufzuheben.

Was es nicht tut, ist ebenfalls erwähnenswert. Die erneute Authentifizierung der Person hinter einem Konto verhindert keine Modell-Extraktion und erkennt sie auch nicht. Ein verifizierter Entwickler kann den Zugang, den er besitzt, immer noch missbrauchen. Dies schließt die Lücke zwischen „dieses Konto wurde einmal verifiziert“ und „diese Person ist jetzt hier“ – eine enge, reale Lücke. Modell-Level-Ausgabekontrollen und semantische Traffic-Erkennung bleiben separate Schichten und gehören weiterhin Ihnen.

Anwendungsfälle

KI-API-Plattformen, die Kontingenterhöhungen, Kreditvergaben und Schlüsselvergabe hinter einer Prüfung der Person absichern.

Agenten- und Automatisierungsprodukte, die eine Step-Up-Authentifizierung erfordern, bevor einem Agenten eine neue Funktion oder ein erhöhtes Ausgabenlimit gewährt wird.

Finanzdienstleistungen, die vor einer hochvolumigen Überweisung oder einer Änderung des Auszahlungsziels erneut authentifizieren.

Marktplätze, die einen Verkäufer vor einer Änderung der Auszahlungsmethode erneut verifizieren – der häufigste Gewinn bei Kontoübernahmen.

Jede Plattform mit einem Wiederherstellungsfluss, die biometrische Re-Authentifizierung anstelle von wissensbasierten Fragen verwendet, die das schwächste Glied in den meisten Kontosicherheitsdesigns sind.

Häufig gestellte Fragen

Muss der Benutzer erneut ein Dokument einreichen?

Nein. Das ist der Punkt. Die Prüfung erfolgt anhand des bereits aus der ursprünglichen Verifizierung gespeicherten Porträts – Liveness plus Gesichtsabgleich, keine Dokumente.

Was, wenn der Benutzer nie mit Didit verifiziert wurde?

Dann gibt es kein gespeichertes Porträt und nichts, woran man sich authentifizieren könnte. Biometrische Authentifizierung ist ein Re-Verifizierungs-Primitiv; es setzt eine frühere Verifizierung unter den gleichen vendor_data voraus.

Wie lange dauert es?

Inferenz unter zwei Sekunden. Aus Sicht des Benutzers ist es ein Selfie und ein Augenblick.

Kann es in unserer eigenen Oberfläche ausgeführt werden?

Ja. Die SDKs für Web, iOS, Android, React Native und Flutter sind alle kostenlos, und White Label (0,20 $) entfernt das Didit-Branding.

Was, wenn jemand ein Foto oder Video des Kontoinhabers hochhält?

Dafür ist die Liveness-Erkennung da. Didits passive Liveness verfügt über eine iBeta Level 1 Präsentationsangriffs-Erkennungsevaluation, und Gesichtsangriffswarnungen werden in den Warnungen angezeigt. Schwellenwerte sind konfigurierbar.

Was kostet es?

0,10 $ pro Authentifizierung, Pay-per-Success, keine Mindestbeträge.

Sollte jede Anmeldung dies erfordern?

Nein. Die Anmeldung ist der falsche Auslöser – sie wird ständig und meistens umsonst ausgelöst. Verknüpfen Sie sie mit Privilegien-Eskalation und Warnungen, wo die Kosten für einen Fehler hoch und die Häufigkeit gering ist.

Bereit zum Start?

Konfigurieren Sie einen Workflow, verbinden Sie ihn mit Ihren Eskalationspunkten und verwenden Sie ihn überall wieder.

• Lesen Sie die Dokumentation – Übersicht zur Biometrischen Authentifizierung und die Sessions API.
• Sehen Sie sich das Produkt an – Benutzerverifizierung.
• Prüfen Sie die Preise – 0,10 $ pro Authentifizierung, Pay-per-Success, keine Mindestbeträge.
• Kostenlos starten – business.didit.me, 500 KYC-Verifizierungen pro Monat kostenlos.