מדריך טכני למשתמשים חדשים ב-FPNV

תאריך השינוי האחרון: 10 בספטמבר 2025

סקירה כללית

במסמך הזה מפורטים כל השלבים הנדרשים להוספת ספק סלולר ל-Firebase Phone Number Verification (אימות מספר טלפון ב-Firebase,‏ FPNV) באמצעות אימותי מספר טלפון לפי תקן TS.43.

הסברים על המונחים

הצדדים המעורבים

• CSP: ספק שירותי תקשורת
  • למשל: ספקי סלולר
• אתרי אגרגטור
  • אגרגטורים שפונים לאפליקציות: אגרגטור שמאפשר לאפליקציות לבצע אימות בלי שהאפליקציה תקיים אינטראקציה ישירה עם הספק
  • לדוגמה: אימות מספר טלפון ב-Firebase
  • אתר אגרגטור-על: אתר אגרגטור שתומך בהצטרפות של ספק לאתר אגרגטור שפונה לאפליקציה
    • מטא-אגרגטור יכול להיות אחראי להגדרת שרתי ההרשאות עבור הספקים ו/או להגדרת פרטי שרתי ההרשאות באגרגטורים שפונים לאפליקציה
• FPNV: אימות מספר טלפון ב-Firebase
• מנהל חשבון טכני (TAM) של Google: מנהל חשבון טכני של Google, שעוזר לחבר את הספק ל-FPNV
• ‫Android Telephony: מציע ממשקי API של מספרי טלפון ב-Android, כולל פלטפורמה לספקי תקשורת ולאגרגטורים כדי לספק אימותים לפי TS.43.
• ‫GSMA: איגוד של חברות סלולר שמגדיר מפרטים, כולל TS.43
• ‫CAMARA: פרויקט קוד פתוח של Linux שמגדיר ממשקי API של ספקי סלולר בשיתוף עם GSMA

תנאי האימות

• PNV: אימות מספר טלפון
• ‫TS.43: מגדיר את הפרוטוקול לתקשורת בין לקוחות ניידים ושרתים לבין הספק באמצעות HTTP
• ‫EAP-AKA: שיטת אימות שמוגדרת בכתובת https://www.rfc-editor.org/rfc/rfc4187, שלא דורשת אינטראקציה עם המשתמש
• ‫ECS: Entitlement Configuration Server (שרת הגדרות הרשאות)
  • נקודת כניסה לצבירת נתונים כדי לדבר עם הספק
• ‫ODSA: הפעלת שירות במכשיר
  • מתייחס לפעולות שונות שמסופקות על ידי ECS להפעלת שירותים במכשיר
  • לדוגמה: AcquireTemporaryToken; GetPhoneNumber

שרת הרשאות של ספק ונקודת קצה של PNV

יצירת נקודות הקצה הנדרשות

ACTION1: הספק מטמיע את נקודות הקצה הבאות, שכולן נגישות דרך האינטרנט. פרטים נוספים על ההטמעה מופיעים בנספח א'.

דרישות טכניות

ביצועים כלליים: זמן הפעולה של כל נקודות הקצה יהיה לפחות 99.99%.

אבטחה: מטעמי אבטחה, נקודות הקצה של הספק צריכות לעמוד בדרישות הבאות:

• אסימון אימות EAP-AKA: התוקף שלו חייב לפוג תוך שעה
• טוקן זמני: לשימוש חד-פעמי, עם תפוגה של 5 דקות
• אפשרות 1 – Vanilla TS.43
  • ‫OAuth Token: התוקף שלו חייב לפוג תוך שעה
• אפשרות 2 – CAMARA
  • אסימון גישה ל-CAMARA: לשימוש חד-פעמי עם תפוגה של 5 דקות

איכות הנתונים ב-API: 100% מהתוכן של תגובות מוצלחות (כלומר, מספר ה-MSISDN צריך להיות מדויק).

‫FPNV תומך בשתי גרסאות של TS.43. ההבדל העיקרי הוא באופן שבו שרת ה-FPNV יחליף את ה-TempToken עם הספק.

• ‫Vanilla TS.43: מתייחס להטמעה כפי שנקבע במפרט TS.43
• ‫CAMARA: מתייחס להטמעה כפי שנקבע על ידי זרימת ה-JWT bearer של CAMARA

אפשרות 1 – הטמעה של Vanilla TS.43

בקשות ממכשיר Android

1. נקודת קצה (endpoint) של EAP-AKA: החזרת אסימון אימות
2. נקודת הקצה (endpoint) של AcquireTemporaryToken: בהינתן טוקן האימות, מחזירה TempToken

בקשות משרת FPNV

1. ‫OAuth 2.0 Endpoint - OAuth Client ID/Secret Flow: בהינתן מזהה לקוח/סוד לקוח של OAuth, מחזירה אסימון גישה של OAuth
2. ‫GetPhoneNumber Endpoint: בהינתן טוקן גישה מסוג OAuth ו-TempToken, מחזיר את מספר הטלפון התואם

אפשרות 2 – הטמעה של CAMARA

ההטמעה של CAMARA דומה להטמעה הרגילה של TS.43, למעט נקודות הקצה לטיפול בבקשות מהשרת של FPNV.

בקשות ממכשיר Android

1. נקודת קצה (endpoint) של EAP-AKA: החזרת אסימון אימות
2. נקודת הקצה (endpoint) של AcquireTemporaryToken: בהינתן טוקן אימות, מחזירה TempToken

בקשות משרת FPNV

1. ‫OAuth 2.0 Endpoint - JWT Bearer Flow: בהינתן JWT שמכיל את TempToken, מחזיר אסימון גישה של CAMARA
2. ‫CAMARA NumberVerification v2 Endpoint: בהינתן טוקן הגישה של CAMARA, מחזיר את מספר הטלפון התואם

הצטרפות ל-Android Telephony ול-FPNV

Carrier Test App

פעולה 2: נציג של הספק פונה למנהל החשבון הטכני (TAM) של Google, והמנהל ישתף עם הספק את אפליקציית הבדיקה של הספק ל-FPNV. אפליקציית הבדיקה של הספק מדמה את הבקשות שיישלחו על ידי FPNV, בלי לערב את שרת FPNV. אפליקציית הבדיקה של הספק שימושית לספק כדי לוודא שנקודות הקצה שלו פועלות כמו שצריך.

פעולה 3: הספק מאמת שנקודות הקצה שלמעלה פועלות מקצה לקצה באמצעות אפליקציית הבדיקה של הספק FPNV.

הגדרת ההגדרות הנדרשות לסביבת הייצור

הגדרת Android – EAP-AKA / AcquireTempToken

‫ACTION4: ספק הסלולר מגדיר את הגדרת הייצור שלו לבקשות EAP-AKA/AcquireTempToken מ-Android Telephony

• הגדרה:
  • מזהה הספק הקנוני של Android
  • הערכים של TS.43 use_cases: use_case=GetPhoneNumber
  • כתובת ה-URL של שרת ההרשאות בסביבת הייצור עבור EAP-AKA/AcquireTempToken
  • טביעת האצבע ו-SAN של אישור x509 של Firebase
  • SAN: fpnv.googleapis.com
  • טביעת אצבע: aad068c93399a22fc2b11ab58468e8cb72b8f9fc53700991799a8b764c589c7e

הגדרת Firebase – החלפת TempToken בטלפון

‫ACTION5: פרטי הכניסה ל-Firebase לאחזור טוקן OAuth מהספק

• Vanilla TS.43
  • הספק יוצר את מזהה הלקוח ואת הסוד ב-OAuth עבור הבקשות של FPNV. הספק מגדיר את נקודת הקצה (endpoint) של OAuth כך שתחזיר אסימון גישה לפרטי הכניסה האלה
• CAMARA
  • ‫Google TAM מספקת את המפתח הציבורי של Google, כדי שנקודת הקצה של OAuth של הספק תוכל לאמת שה-JWT נחתם על ידי Google

‫ACTION6: ספק הסלולר מגדיר הגדרת ייצור לשרת FPNV כדי להחליף את TempToken בטלפון

• מזהה הספק הקנוני של Android של ה-MNO הזה
• Vanilla TS.43
  • OAuth – תהליך מזהה לקוח/סוד
  • כתובת ה-URL של נקודת הקצה של OAuth
  • מזהה לקוח/סוד ב-OAuth
  • היקף הרשאות OAuth (אם רלוונטי)
  • GetPhoneNumber
  • כתובת ה-URL של נקודת הקצה GetPhoneNumber
• CAMARA
  • OAuth – תהליך Bearer JWT
  • כתובת ה-URL של נקודת הקצה של OAuth
  • NumberVerification API v2
  • כתובת ה-URL של נקודת הקצה של NumberVerification

שיתוף פרטי כניסה או הגדרות

אימות מספר הטלפון ב-Firebase

פעולה 7: הספק משתף את הגדרות הייצור שלו מפעולה 4 ומפעולה 6 עם מנהל החשבון הטכני של Google.

• [חשוב] צריך לשתף את סוד ה-OAuth עם Google באמצעות מנגנון מאובטח שלא מבוסס על תקשורת רגילה (לא אימיילים, לא מסמכים וכו'). מנגנון מחוץ לפס יוסכם על ידי הספק וצוות TAM של Google.

פעולה 8: צוות TAM של Google מאמת שההגדרה פועלת מקצה לקצה באמצעות אפליקציית הבדיקה של הספק. לאחר מכן, צוות TAM של Google יאחסן את פרטי הכניסה של OAuth באחסון מאובטח של Google ויעדכן את ההגדרות של FPNV כדי להחליף את TempToken בטלפון (כלומר, ההגדרות של פעולה 6).

טלפוניה ב-Android

פעולה 9: הספק פועל לפי המסמך Google Open Gateway CSP Onboarding (צירוף ספק שירותי תקשורת ל-Google Open Gateway) (מנהל החשבון הטכני של Google ישתף את המסמך עם הספק). הספק או ה-TAM שלו ב-Google מגישים כרטיס Buganizer כדי להצטרף להגדרות של Android Telephony: https://issuetracker.google.com/issues/new?component=1861595&template=2168610. הבאג הזה יקבל את הגדרות הייצור מ-ACTION4.

אם מטא-אגרגטור מגדיר את השילוב של FPNV בשם הספק, צריך לקבל הצהרת הסכמה (באימייל, ב-PDF, במכתב וכו') מההנהלה של הספק (ברמת מנהל ומעלה) שמאשרת את הקשר העסקי עם המפעיל. לאחר מכן, המטא-אגרגטור יכול לספק את ההגדרה של הספק בשם הספק ל-Android Telephony.

נספח א'. הטמעה מפורטת

תלות באותיות רישיות (Case sensitivity)

• כותרות HTTP לא תלויות באותיות רישיות
• עם זאת, הפורמטים XML ו-JSON הם תלויי-רישיות. לכן, בשדות של הבקשה/התגובה, צריך לוודא שהשדות תואמים בדיוק לתיעוד הזה.

שלב 1 – EAP-AKA / AcquireTempToken

נקודות קצה: הפונקציות EAP-AKA ו-AcquireTempToken צריכות להשתמש באותה נקודת קצה של ECS.

אתגר EAP-AKA

הפניות: TS.43 v12.0 - Section 2.8.1 - "Embedded EAP-AKA Authentication by Entitlement Configuration Server".

EAP-AKA שלב 1 – אתגר אימות

EAP-AKA #1 - GET Request to ECS

מודול הטלפוניה של Android שולח בקשת TS.43 EAP-AKA לשרת ההרשאות של הספק.

כותרות בקשות ב-Android

• Accept: application/vnd.gsma.eap-relay.v1.0+json
  • זהו פורמט JSON שספציפי ל-GSMA, ולא רק ל-application/json

שדות הבקשה ב-Android

• ‫eap_id: ראו RCC.14 Annex C
  • כלומר, 0<IMSI>@<realm>.mnc<MNC>.mcc<MCC>.3gppnetwork.org
• ‫GID1: מצוין רק אם גרסת ההרשאה היא 12.0
• ‫app_name: ל-AppName המקודד יהיה ערך גיבוב MD5 של תרחיש השימוש שמבצע אימות טלפוני:
  • לכל הבקשות מאגרגטורים שמופנות לאפליקציה יהיה שם אפליקציה של Google-OGI
• ‫app: מזהה האפליקציה ap2014 מייצג מידע על מספר טלפון
• ‫terminal_vendor/model/sw_version: מוגדר לערך שרירותי. מערכת Android לא מבטיחה שהשדות האלה יכילו את המידע בפועל של המכשיר
• ‫vers: גרסת ההגדרה, לדוגמה: 0 או 1
• ‫entitlement_version: Google תקבע את גרסת ההרשאה שתישלח לחברות הסלולר בהתאם לבקשה של חברת הסלולר.
  • בדרך כלל, הערך של entitlement_version הוא 10.0 או 12.0

EAP-AKA #1 - Response from ECS

כותרות תגובה של ECS

• ‫Content-Type: מערכת Android מצפה שסוג התגובה יתאים לכותרת Accept של הבקשה
  • כלומר, application/vnd.gsma.eap-relay.v1.0+json

שדות תגובה של ECS

• ‫eap-relay-packet: מכיל את חבילת ה-EAP בהתאם ל-RCC.14 - Section C.2

שלב 2 ב-EAP-AKA – קבלת טוקן אימות

EAP-AKA #2 - POST Request to ECS

מודול הטלפוניה של Android ישלח בחזרה את הנתונים שהתקבלו eap-relay-packet לאותה נקודת קצה.

כותרות בקשות ב-Android

• ‫Accept: מערכת Android תגדיר שתי כותרות Accept:
  • ‫application/vnd.gsma.eap-relay.v1.0+json: מתייחס למצב שבו הספק מחזיר JSON שוב אם המכשיר צריך לשלוח שוב בקשת EAP-AKA
  • ‫text/vnd.wap.connectivity-xml: מתייחס לפורמט בפועל שאנדרואיד מצפה שהספק יחזיר את אסימון האימות של EAP-AKA
• Content-Type: application/vnd.gsma.eap-relay.v1.0+json

שדות הבקשה ב-Android

• ‫eap-relay-packet: מכיל את eap-relay-packet של התגובה הקודמת של EAP-AKA, אבל בפורמט EAP-Response/AKA-Challenge בהתאם ל-RFC‏ 4817 – סעיף 9.2.

EAP-AKA #2 - Response from ECS

אחרי אימות מוצלח של EAP-AKA, הספק מחזיר אסימון אימות.

כותרות תגובה של ECS

• ‫Content-Type: מערכת Android מצפה שהתגובה שתתאים לכותרת Accept של הבקשה
  • כלומר, מערכת Android מצפה שהתשובה עם אסימון ההרשאה תהיה מהסוג text/vnd.wap.connectivity-xml
  • הכותרת השנייה של Accept, ‏ application/vnd.gsma.eap-relay.v1.0+json, היא אם הספק רוצה שמערכת Android תבצע בקשת EAP-AKA נוספת

שדות תגובה של ECS

• ‫TOKEN.token: מכיל את טוקן האימות
• ‫TOKEN.validity: מספר השניות שהתשובה תקפה, אחרי שהמכשיר מקבל את התשובה.
  • ‫Google תאמת שאסימון ההרשאה עומד בדרישות הטכניות

AcquireTemporary Token

‫AcquireTempToken – בקשת GET אל ECS

באמצעות טוקן האימות שהתקבל מ-EAP-AKA, לקוח Android מאחזר את הטוקן הזמני על ידי קריאה לנקודת הקצה AcquireTemporaryToken של הספק. הבקשה

• דוגמה: TS.43 v12.0 - Section 6.4.6 - "AcquireTemporaryToken Request Example"
• ל-AcquireTempToken יש פרמטרים דומים ל-EAP-AKA #1, אבל:
  • בנוסף, הפונקציה AcquireTempToken מציינת את IMSI, operation ואת operation_targets
  • הפונקציה AcquireTempToken לא מציינת את EAP_ID

כותרות בקשות ב-Android

• ‫Accept: מערכת Android תגדיר את text/vnd.wap.connectivity-xml

שדות הבקשה ב-Android

• ‫terminal_vendor/model/sw_version: מערכת Android לא מבטיחה שהשדות האלה יכילו את המידע בפועל של המכשיר
• operation_targets
  • FPNV: יעד הפעולה הוא GetPhoneNumber

AcquireTempToken - Response from ECS

דוגמה: TS.43 v12.0 - Section 6.6.6 - "AcquireTemporaryToken Response Example"

כותרות תגובה של ECS

• ‫Content-Type: מערכת Android מצפה שסוג התגובה יתאים לכותרת Accept של הבקשה
  • כלומר, text/vnd.wap.connectivity-xml

שדות תגובה של ECS

• ‫APPLICATION.TemporaryToken: TemporaryToken שהשרת של FPNV יכול להמיר למספר טלפון
• ‫APPLICATION.TemporaryTokenExpiry: שעת התפוגה בפורמט YYYY-MM-DDThh:mm:ssTZD
  • ‫Google תאמת שתוקף הטוקן הזמני עומד בדרישות הטכניות
• ‫APPLICATION.OperationResult: ראו TS.43 v12.0 - Section 6.5.1
  • באופן ספציפי, אם הפעולות הן SUCCESS, הפונקציה מחזירה 1

שלב 2 – החלפת TempToken במספר טלפון

אפשרות 1 – Vanilla TS.43

נקודות קצה: יכול להיות שנקודות הקצה של OAuth ושל GetPhoneNumber יהיו שרתים או נקודות קצה שונים. יכול להיות שנקודות הקצה האלה יהיו שונות מנקודת הקצה של EAP-AKA/AcquireTempToken.

OAuth

הספק צריך לפעול לפי המדריך הזה בנושא OAuth ולספק ל-Google את פרטי ה-OAuth הנדרשים (מזהה לקוח, סוד לקוח, כתובת URL של שרת OAuth)

‫OAuth – בקשת POST לשרת האימות של הספק

FPNV Request Headers

• ‫Authorization: FPNV יגדיר את Basic $BASE64_ENCODED_CREDENTIALS
  • הפרטים בקידוד Base64 הם קידוד Base64 של OAuth $CLIENT_ID:$CLIENT_SECRET
• ‫Content-Type: FPNV יגדיר את application/x-www-form-urlencoded
• ‫Accept: FPNV יגדיר את application/json

שדות בבקשה לניוד מספרים וירטואליים

• grant_type: client_credentials

POST HTTP/1.1
Host: $OAUTH_ENDPOINT
Authorization: Basic $BASE64_ENCODED_CREDENTIALS
Content-Type: application/x-www-form-urlencoded
Accept: application/json

grant_type=client_credentials

‫OAuth – תגובה משרת האימות של הספק

כותרות התגובה של הספק

• ‫Content-Type: ב-FPNV מצפים שסוג התגובה יתאים לכותרת Accept של הבקשה
  • כלומר, application/json

שדות התגובה של הספק

• ‫access_token: אסימון גישה ל-OAuth
• token_type: bearer
• ‫expires_in: תפוגה של אסימון הגישה מסוג OAuth בשניות
  • ‫Google תאמת שזמן התפוגה של טוקן OAuth עומד בדרישות הטכניות

200 OK
Content-Type: application/json

{
  "access_token": $ACCESS_TOKEN,
  "token_type": "bearer",
  "expires_in": $EXPIRATION_IN_SECS,
}

GetPhoneNumber

GetPhoneNumber – בקשת POST ל-ECS

שרת האימות של Google מאחזר את מספר הטלפון באמצעות הפעולה GetPhoneNumber.

• דוגמה: TS.43 v12.0 - Section 6.4.7 - "GetPhoneNumber Request Example"

כותרות הבקשה של FPNV

• Accept: application/json
• Content-Type: application/json

שדות הבקשה של FPNV

• ‫requestor_id: מזהה את השירות שקורא לפעולה GetPhoneNumber TS.43
  • Firebase Phone Number Verification UUID: 191fd7cc-f7cd-4bb4-a5d2-455ae1fb9a19
• ‫temporary_token: TemporaryToken מ-AcquireTempToken
• ‫access_token: טוקן OAuth שמאפשר ל-Google לבצע אימות מול הספק
• ‫terminal_vendor/model/sw_version: המערכת של FPNV תאכלס את השדות האלה בערכים שרירותיים
• ‫entitlement_version: Google תקבע את גרסת ההרשאה שתישלח לחברות הסלולר בהתאם לבקשה של חברת הסלולר.
  • בדרך כלל, הערך של entitlement_version הוא 10.0 או 12.0
• ‫app: FPNV יגדיר את ap2014
• ‫app_name: FPNV יגדיר firebase לכל הבקשות של FPNV
  • הערה: ל-AcquireTempToken יהיה app_name של Google-OGI, לא משנה באיזה צובר משתמשים
• ‫operation: FPNV יגדיר את GetPhoneNumber

GetPhoneNumber - Response from ECS

דוגמה: TS.43 v12.0 - Section 6.6.7 - "GetPhoneNumber Response Example"

כותרות התגובה של הספק

• ‫Content-Type: ב-FPNV מצפים שסוג התגובה יתאים לכותרת Accept של הבקשה
  • כלומר, application/json

שדות התגובה של הספק

• ‫ap2014.MSISDN: FPNV מצפה שמספר הטלפון יוחזר בפורמט E164
  • פורמט JSON הוא תלוי אותיות רישיות, ולכן צריך להשתמש באותיות רישיות ב-MSISDN

קודי שגיאה של TemporaryToken

מקורות מתוך TS.43 v12.0, סעיף 2.8.6.

בטבלה הבאה מפורטות תגובות השגיאה שצפויות לחזור מ-ECS לשרת האימות של Google עבור בקשות GetPhoneNumber:

אפשרות 2 – CAMARA

נקודות קצה (endpoints): אחזור אסימון הגישה של CAMARA ואחזור מספר הטלפון יכולים להיות שרתים או נקודות קצה שונים. נקודות הקצה האלה יכולות להיות שונות מנקודת הקצה של EAP-AKA / AcquireTempToken.

OAuth – אחזור אסימון גישה של CAMARA

‫Google תתמוך רק בתהליך JWT bearer של CAMARA ולא בתהליך CIBA.

טוקן גישה של CAMARA – בקשת POST לספק

‫Google תיצור JWT עם השדות הבאים.

• ‫iss: המנפיק של ה-JWT (המכונה גם מזהה לקוח)
  • כלומר firebase (שילוב FPNV בפועל) או fpnv-carrier-tester-app (אפליקציית בדיקה של ספק)
• ‫sub: הנושא של ה-JWT
  • כלומר, operatortoken:$TEMP_TOKEN
• ‫aud: קהל; נמענים שה-JWT מיועד להם
  • כתובת ה-URL של נקודת הקצה של הטוקן (כלומר, כתובת ה-URL של שרת ההרשאות)
• ‫exp: זמן התפוגה בשניות
  • ‫Google תשלח משך תפוגה שתואם למשך הזמן שבו אסימון הגישה של CAMARA צריך להיות תקף (ראו דרישות טכניות)
• ‫iat: זמן ההנפקה בשניות
• ‫jti: מזהה ייחודי למניעת מתקפות שידור חוזר
  • לדוגמה: מזהה ייחודי אוניברסלי (UUID) שנוצר באופן אקראי
• ‫scope: מטרת הבקשה
  • כלומר, dpv:FraudPreventionAndDetection number-verification:device-phone-number:read

{
  "iss": "firebase",
  "sub": "operatortoken:ey...",
  "aud": $OAUTH_ENDPOINT,
  "exp": $EXPIRATION_TIME_IN_SECS,
  "iat": $ISSUED_AT_TIME_IN_SECS,
  "jti": $RANDOMLY_GENERATED_UUID,
  "scope": "dpv:FraudPreventionAndDetection number-verification:device-phone-number:read"
}

ה-FPNV יחתום על ה-JWT באמצעות המפתח הפרטי שלו, והספק יוכל לאמת את ה-JWT באמצעות המפתח הציבורי התואם. FPNV יספק את המפתח הציבורי באמצעות נקודת קצה של JWKS. ספקי הסלולר צריכים לבצע שאילתות באופן קבוע בנקודת הקצה הזו של JWKS כדי לקבל את המפתח הציבורי (למשל, פעם ביום), כי FPNV יבצע רוטציה של המפתחות הציבוריים בקצב קבוע (למשל, פעם ב-30 יום).

כותרות הבקשה של FPNV

• Content-Type: application/x-www-form-urlencoded
• Accept: application/json

שדות הבקשה של FPNV

• grant_type: urn:ietf:params:oauth:grant-type:jwt-bearer
• ‫assertion: ה-JWT שנוצר למעלה ונחתם באמצעות המפתח הפרטי של FPNV
  • חשוב לציין שאסימון ה-JWT הזה מכיל את TempToken

POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Accept: application/json

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=$JWT

טוקן גישה של CAMARA – תגובה מהספק

כותרות התגובה של הספק

• ‫Content-Type: ב-FPNV מצפים שסוג התגובה יתאים לכותרת Accept של הבקשה
  • כלומר, application/json

שדות התגובה של הספק

• ‫access_token: אסימון גישה של CAMARA, שאפשר להמיר אותו בהמשך למספר טלפון
• token_type: bearer
• ‫expires_in: תפוגה של אסימון הגישה מסוג OAuth בשניות
  • ‫Google תאמת שזמן התפוגה של טוקן OAuth עומד בדרישות הטכניות
• ‫scope: מטרת הבקשה
  • כלומר, dpv:FraudPreventionAndDetection number-verification:device-phone-number:read

200 OK
Content-Type: application/json

{
  "access_token": $CAMARA_ACCESS_TOKEN,
  "token_type": "bearer",
  "expires_in": $EXPIRATION_IN_SECS,
  "scope": "dpv:FraudPreventionAndDetection number-verification:device-phone-number:read"
}

CAMARA NumberVerification API v2

לאחר מכן, Google תשלח בקשת GET לנקודת הקצה ‎/device-phone-number של הספק כדי להחליף את אסימון הגישה של CAMARA.

CAMARA NumberVerification - GET Request to Carrier

כותרות הבקשה של FPNV

• Authorization: Bearer $CAMARA_ACCESS_TOKEN
• Accept: application/json

GET /device-phone-number
Authorization: Bearer $CAMARA_ACCESS_TOKEN
Accept: application/json
Content-Type: application/json

CAMARA NumberVerification - Response from Carrier

כותרות התגובה של הספק

• ‫Content-Type: ב-FPNV מצפים שסוג התגובה יתאים לכותרת Accept של הבקשה
  • כלומר, application/json

שדות התגובה של הספק

• ‫devicePhoneNumber: מחזירה את מספר הטלפון בפורמט E164

200 OK
Content-Type: application/json

{
 "devicePhoneNumber": $PHONE_NUMBER
}