משתלב עם כל מערכת, כי זה שתי קריאות HTTP.
שתי קריאות שרת-לשרת וכתובת אחת, מכל שפת צד שרת. כשתרצו שהצילום יקרה בתוך האפליקציה שלכם, מוסיפים את ה-SDK הנייטיב ל-React Native ול-Flutter.
כל צד השרת.
שתי קריאות וכתובת אחת, זה כל החוזה בין השרת שלכם לשלנו. עם ה-webhook החתום, הקריאה השנייה הופכת לאופציונלית.
פותחים הפעלה, ושולחים את האדם לכתובת
POST <session endpoint>
-> { "session_id": "...", "url": "https://..." }
GET <session endpoint>/{session_id}
-> { "verified": true, "meets_age": true, … }השדות נקבעים מול כל לקוח בנפרד. מבנה הבקשות והתשובות המלא נמצא בתיעוד ה-API (באנגלית).
| דרך חיבור | מתי משתמשים בה |
|---|---|
| כתובת מתארחת | כשרוצים אימות באוויר בלי להכניס קוד צילום לאפליקציה. |
| webhook | כשהשרת שלכם יכול לקבל בקשה נכנסת, ואתם רוצים שהתוצאה תישלח אליכם. |
| שליפת תוצאה | כשהשרת שלכם לא מקבל בקשות נכנסות, ולכן אתם קוראים את התוצאה בעצמכם. |
| SDK | כשהצילום יושב בתוך האפליקציה שלכם, ב-React Native או ב-Flutter. |
הרשימה המלאה.
סננו לפי ההחלטה שעומדת בפניכם: איך הקריאה עוברת, איך מקבלים את התשובה, על מה רץ הלקוח, והאם יש לכם צד שרת בכלל.
- שתי קריאות. השרת שלכם פותח הפעלת אימות וקורא את התוצאה. כל שפת צד שרת מתאימה, בלי SDK לשרת שצריך להתקין ולעדכן: כל מה שיודע לשלוח JSON על גבי TLS מוכן לעבודה.
כתובת אימות מתארחתredirect
ההפעלה שאתם פותחים מחזירה כתובת אחת. שולחים אליה את האדם, והוא חוזר אליכם. הצילום, קריאת הצ’יפ, בדיקת שרשרת האמון והמחיקה קורים כולם בצד שלנו של הכתובת, כך שאין קוד צילום לבנות או להפיץ בתוך האפליקציה שלכם.Webhooks חתומיםPOST, signed
התוצאה נשלחת לנקודת קצה שבבעלותכם, חתומה, כך שאפשר להוכיח שהיא הגיעה מאיתנו ולדחות שליחה חוזרת. התשובה מגיעה ישירות לשרת שלכם, ואף פעם לא עוברת דרך הדפדפן של המשתמש.שליפת התוצאה מצד השרתGET
לשרת שלא מקבל בקשות נכנסות: קוראים את התוצאה בעצמכם כשהאדם חוזר. אותו מטען, אותם שדות, והתשובה עדיין אף פעם לא עוברת דרך הלקוח.SDK ל-React Nativenative module
SDK נייטיב לאימות, לאפליקציות שנבנו ב-React Native. הצילום, קריאת הצ’יפ ב-NFC והצילום החתום רצים בתוך האפליקציה שלכם, על גבי אותן שתי קריאות שרת.SDK ל-Flutterplugin
אותה יכולת אימות נייטיב, לאפליקציות Flutter. אפשר להתחיל מהכתובת המתארחת ולהוסיף SDK בהמשך: צד השרת נשאר בדיוק אותו דבר.iOS, עם App AttestApp Attest
כל צילום עובר גיבוב ונחתם על המכשיר עם קוד חד פעמי, וב-iOS הוא נושא גם Apple App Attest, שמוכיח שהבקשה הגיעה מגרסה מקורית של האפליקציה, שלא שונתה, על חומרה אמיתית של Apple. פריים ממצלמה וירטואלית או הקלטה שמושמעת מחדש לא עוברים אימות.Androidnative app
ב-Android האפליקציה קוראת את הצ’יפ בדרכון ב-NFC וחותמת כל צילום על המכשיר עם קוד חד פעמי, כך שאי אפשר להחליף פריימים או להשמיע אותם מחדש בדיעבד.פונקציות serverless לאתר סטטיtwo functions
גם לאתר סטטי בלי צד שרת משלו יש איפה לשים שתי פונקציות קטנות: אחת שפותחת את ההפעלה, ואחת שמקבלת את התוצאה או את ה-webhook. זה כל צד השרת, והטוקן של הלקוח נשאר בצד השרת, בתוך הפונקציה.
פועל בייצור אצל פלטפורמת כרטיסים לגיימינג בנתיב ה-REST, ופלטפורמה שנייה משתלבת באופן נייטיב דרך ה-SDK. בהמשך הדרך: כניסה אחידה (SSO) על גבי OIDC, כולל Microsoft Entra ID, להתקנות ארגוניות.
מקבלים רק את מה שצריך.
אתם בוחרים את השדות. פלטפורמת כרטיסים לגיימינג רצה בייצור על שלושה שדות: בלי שם, בלי מספר זהות, בלי תאריך לידה, בלי תמונה. אין אצלה שום מידע מזהה, ולכן אין לה מה להדליף.
הטוקנים מבודדים לכל לקוח. שתי פלטפורמות שמאמתות את אותו אדם מקבלות טוקנים שונים, ולא יכולות להצליב את מאגרי המשתמשים שלהן.
המטען הקטן ביותר שעדיין שימושי
{
"verified": true,
"meets_age": true,
"age_gate_min": 18
}אפשר לקבל יותר שדות, לפי הגדרה מול כל לקוח.
עשרים דקות כדי לראות את האינטגרציה מקצה לקצה.
דרכון אמיתי, שרשרת אמון שנפתרת בלי רשת, ושתי הקריאות רצות מול העיניים שלכם.
לתיאום הדגמה