راهنمای ورود به شرکت مخابراتی تأیید صحت شماره تلفن Firebase

آخرین تاریخ اصلاح: 10 سپتامبر 2025

نمای کلی

این سند تمام مراحل اجباری را برای ورود به شرکت مخابراتی در تأیید شماره تلفن Firebase (Firebase PNV) از طریق تأیید شماره تلفن TS.43 نشان می‌دهد.

اصطلاحات

احزاب درگیر

• CSP : ارائه دهنده خدمات ارتباطی
  • به عنوان مثال اپراتورهای تلفن همراه
• تجمیع کننده ها
  • App-Facing Aggregators : جمع‌آوری که به برنامه‌ها اجازه می‌دهد بدون اینکه برنامه مستقیماً با شرکت مخابراتی تعامل داشته باشد، تأیید را انجام دهد.
    • به عنوان مثال تأیید شماره تلفن Firebase
  • Meta-Aggregator : Aggregator که از حامل پشتیبانی می کند تا در یک جمع کننده رو به برنامه باشد.
    • یک متاجمع‌کننده می‌تواند مسئول راه‌اندازی سرورهای استحقاق برای شرکت‌های مخابراتی و/یا پیکربندی جزئیات سرورهای استحقاق با تجمیع‌کننده‌های روبه‌روی برنامه باشد.
• Firebase PNV : تأیید شماره تلفن Firebase
• Google TAM : Google Technical Account Manager، که به شرکت مخابراتی در Firebase PNV کمک می‌کند.
• Android Telephony : APIهای شماره تلفن را در Android ارائه می‌کند، از جمله پلتفرمی برای شرکت‌های مخابراتی و تجمیع‌کننده‌ها برای ارائه تأییدیه‌های TS.43
• GSMA : انجمن اپراتورهای شبکه تلفن همراه که مشخصاتی از جمله TS.43 را تعریف می کنند
• CAMARA : پروژه منبع باز لینوکس که API های حامل را با همکاری GSMA تعریف می کند.

شرایط تأیید

• PNV : تأیید شماره تلفن
• TS.43 : پروتکلی را برای کلاینت‌ها و سرورهای موبایل برای برقراری ارتباط با اپراتور با استفاده از HTTP تعریف می‌کند.
• EAP-AKA : روش احراز هویت تعریف شده در https://www.rfc-editor.org/rfc/rfc4187 ، که نیازی به تعامل با کاربر ندارد
• ECS : سرور پیکربندی حق
  • نقطه ورود جمع کننده برای صحبت با شرکت مخابراتی
• ODSA : فعال سازی سرویس روی دستگاه
  • به عملیات های مختلف ارائه شده توسط ECS برای فعال کردن خدمات در دستگاه اشاره دارد
  • به عنوان مثال AcquireTemporaryToken. دریافت شماره تلفن

سرور حق حامل و نقطه پایانی PNV

ایجاد نقاط پایانی لازم

ACTION1 : حامل نقاط پایانی زیر را پیاده سازی می کند که همگی از طریق اینترنت قابل دسترسی هستند. برای جزئیات بیشتر در مورد اجرا به پیوست A مراجعه کنید.

الزامات فنی

عملکرد کلی : زمان به کارگیری تمام نقاط پایانی باید حداقل 99.99٪ باشد.

امنیت : به دلایل امنیتی، نقاط پایانی حامل باید شرایط زیر را برآورده کنند:

• EAP-AKA Auth Token : باید ظرف 1 ساعت منقضی شود
• ژتون موقت : یکبار مصرف با انقضای 5 دقیقه
• گزینه 1 - وانیل TS.43
  • Token OAuth : باید ظرف 1 ساعت منقضی شود
• گزینه 2 - CAMARA
  • CAMARA Access Token : یکبار مصرف با انقضای 5 دقیقه

کیفیت داده های API : 100٪ از محتوای پاسخ های موفق (یعنی MSISDN باید دقیق باشد).

Firebase PNV از دو طعم TS.43 پشتیبانی می کند. تفاوت اصلی این است که سرور Firebase PNV چگونه TempToken را با اپراتور مبادله می کند.

• Vanilla TS.43 : به پیاده سازی مطابق با مشخصات TS.43 اشاره دارد
• CAMARA : به پیاده سازی که توسط جریان حامل JWT CAMARA تجویز شده است اشاره دارد.

گزینه 1 - اجرای Vanilla TS.43

درخواست از دستگاه Android

1. نقطه پایانی EAP-AKA : یک نشانه تأیید اعتبار را برگردانید
2. نقطه پایانی AcquireTemporaryToken : با توجه به رمز تأیید، یک TempToken برگردانید

درخواست از سرور PNV Firebase

1. OAuth 2.0 Endpoint - OAuth Client ID/Secret Flow : با توجه به شناسه/راز مشتری OAuth، یک نشانه دسترسی OAuth برگردانید
2. GetPhoneNumber Endpoint : با توجه به نشانه دسترسی OAuth و TempToken، شماره تلفن مربوطه را برگردانید

گزینه 2 - پیاده سازی CAMARA

پیاده‌سازی CAMARA شبیه اجرای vanilla TS.43 است، به جز نقاط پایانی برای رسیدگی به درخواست‌های سرور Firebase PNV.

درخواست از دستگاه Android

1. نقطه پایانی EAP-AKA : یک نشانه تأیید اعتبار را برگردانید
2. نقطه پایانی AcquireTemporaryToken : با توجه به یک نشانه تأیید اعتبار، یک TempToken برگردانید

درخواست از سرور PNV Firebase

1. OAuth 2.0 Endpoint - JWT Bearer Flow : با توجه به JWT حاوی TempToken، یک نشانه دسترسی CAMARA را برگردانید.
2. CAMARA NumberVerification v2 Endpoint : با توجه به رمز دسترسی CAMARA، شماره تلفن مربوطه را برگردانید

ورود به سیستم تلفن Android و Firebase PNV

برنامه تست حامل

ACTION2 : شرکت مخابراتی با Google Technical Account Manager (TAM) تماس می گیرد و TAM برنامه آزمایشی شرکت مخابراتی Firebase PNV را با شرکت مخابراتی به اشتراک می گذارد. این برنامه آزمایشی حامل درخواست‌هایی را که توسط Firebase PNV ارسال می‌شود، بدون دخالت سرور Firebase PNV تقلید می‌کند. این برنامه آزمایشی شرکت مخابراتی برای تأیید صحت این که نقاط پایانی آنها به درستی کار می کنند مفید است.

ACTION3 : حامل تأیید می‌کند که نقاط پایانی بالا با استفاده از برنامه آزمایشی حامل Firebase PNV، سرتاسر کار می‌کنند.

تنظیم تنظیمات تولید لازم

پیکربندی Android - EAP-AKA / AcquireTempToken

ACTION4 : شرکت مخابراتی پیکربندی تولید خود را برای درخواست‌های EAP-AKA/AcquireTempToken از Android Telephony تعریف می‌کند.

• پیکربندی:
  • شناسه حامل Android Canonical این شرکت مخابراتی
  • مقادیر use_cases TS.43: use_case=GetPhoneNumber
  • URL سرور حق تولید برای EAP-AKA/AcquireTempToken
  • SAN و اثر انگشت گواهی x509 تولید Firebase
    • SAN : fpnv.googleapis.com
    • اثر انگشت : aad068c93399a22fc2b11ab58468e8cb72b8f9fc53700991799a8b764c589c7e

Firebase Config - TempToken را برای تلفن مبادله کنید

ACTION5 : اطلاعات کاربری Firebase برای بازیابی یک توکن OAuth از شرکت مخابراتی

• وانیل TS.43
  • حامل شناسه مشتری OAuth و راز را برای درخواست های Firebase PNV ایجاد می کند. سپس حامل، نقطه پایانی OAuth خود را پیکربندی می کند تا یک نشانه دسترسی برای این اعتبارنامه ها را بازگرداند
• کامارا
  • Google TAM کلید عمومی Google را فراهم می کند، به طوری که نقطه پایانی OAuth شرکت مخابراتی می تواند تأیید کند که JWT توسط Google امضا شده است.

ACTION6 : حامل یک پیکربندی تولیدی برای سرور Firebase PNV تعریف می‌کند تا TempToken را با تلفن مبادله کند.

• این MNO's Android Canonical Carrier ID
• وانیل TS.43
  • OAuth - شناسه مشتری/جریان مخفی
    • نشانی وب نقطه پایانی OAuth
    • شناسه/مخفی کلاینت OAuth
    • محدوده OAuth (در صورت وجود)
  • دریافت شماره تلفن
    • نشانی وب نقطه پایانی GetPhoneNumber
• کامارا
  • OAuth - جریان حامل JWT
    • نشانی وب نقطه پایانی OAuth
  • NumberVerification API نسخه 2
    • URL نقطه پایان NumberVerification

اشتراک گذاری اعتبارنامه ها/پیکربندی ها

تأیید شماره تلفن Firebase

ACTION7 : شرکت مخابراتی پیکربندی تولید خود را از ACTION4 و ACTION6 با مدیر حساب فنی Google به اشتراک می‌گذارد.

• [مهم] راز OAuth باید با استفاده از مکانیزم ایمن و خارج از باند (بدون ایمیل، بدون سند و غیره) با Google به اشتراک گذاشته شود. این مکانیسم خارج از باند مورد توافق شرکت مخابراتی و Google TAM خواهد بود.

ACTION8 : Google TAM تأیید می‌کند که این پیکربندی با استفاده از برنامه آزمایشی شرکت مخابراتی، سرتاسر کار می‌کند. پس از آن، Google TAM اعتبار OAuth را در یک فضای ذخیره‌سازی امن Google ذخیره می‌کند و تنظیمات Firebase PNV را به‌روزرسانی می‌کند تا TempToken را با یک تلفن (یعنی تنظیمات ACTION6 ) مبادله کند.

تلفن اندروید

ACTION9 : شرکت مخابراتی از سند "Google Open Gateway CSP Onboarding" (که Google TAM با شرکت مخابراتی به اشتراک می گذارد) پیروی می کند. شرکت مخابراتی یا Google TAM آنها یک بلیت Buganizer را برای نصب روی پیکربندی Android Telephony ارسال می‌کند: https://issuetracker.google.com/issues/new?component=1861595&template=2168610 . این اشکال پیکربندی تولید را از ACTION4 می گیرد.

اگر یک متا جمع‌آوری یکپارچه‌سازی PNV Firebase را از طرف شرکت مخابراتی تنظیم می‌کند، باید بیانیه رضایت (ایمیل، PDF، نامه، و غیره) از سوی رهبری شرکت مخابراتی (سطح +Director) ارتباط تجاری آنها را با اپراتور مذکور تأیید کند. پس از آن، متاجمع‌کننده می‌تواند پیکربندی اپراتور را از طرف اپراتور به Android Telephony ارائه دهد.

ضمیمه A. اجرای تفصیلی

حساسیت به حروف کوچک

• هدرهای HTTP به حروف بزرگ و کوچک حساس نیستند
• با این حال، فرمت های XML و JSON به حروف بزرگ و کوچک حساس هستند. بنابراین برای فیلدهای درخواست/پاسخ، مطمئن شوید که فیلدها دقیقاً با این مستندات مطابقت دارند.

مرحله 1 - EAP-AKA / AcquireTempToken

نقاط پایانی : EAP-AKA و AcquireTempToken باید از یک نقطه پایانی ECS استفاده کنند.

چالش EAP-AKA

منابع : TS.43 v12.0 - بخش 2.8.1 - "تأثیر هویت EAP-AKA تعبیه شده توسط سرور پیکربندی حق".

EAP-AKA مرحله 1 - چالش احراز هویت

EAP-AKA #1 - درخواست ECS را دریافت کنید

ماژول Android Telephony یک درخواست TS.43 EAP-AKA را به سرور مجاز شرکت مخابراتی ارسال می کند.

هدرهای درخواست اندروید

• Accept : application/vnd.gsma.eap-relay.v1.0+json
  • این یک فرمت JSON مخصوص GSMA است، نه فقط application/json

فیلدهای درخواست اندروید

• 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 - پاسخ از ECS

هدرهای پاسخ ECS

• Content-Type : اندروید انتظار دارد که نوع پاسخ با سرصفحه پذیرش درخواست مطابقت داشته باشد
  • یعنی application/vnd.gsma.eap-relay.v1.0+json

فیلدهای پاسخ ECS

• eap-relay-packet : حاوی بسته EAP زیر RCC.14 - بخش C.2

EAP-AKA مرحله 2 - توکن Auth را دریافت کنید

EAP-AKA #2 - ارسال درخواست به ECS

سپس ماژول Android Telephony eap-relay-packet دریافتی را به همان نقطه پایانی ارسال می کند.

هدرهای درخواست اندروید

• Accept : اندروید دو هدر Accept را تنظیم می‌کند:
  • application/vnd.gsma.eap-relay.v1.0+json : اگر دستگاه نیاز به ارسال مجدد درخواست EAP-AKA دیگری داشته باشد، به حاملی که دوباره JSON را برمی گرداند، اشاره دارد.
  • text/vnd.wap.connectivity-xml : به قالب واقعی اشاره دارد که اندروید انتظار دارد که اپراتور رمز احراز هویت EAP-AKA را به عنوان بازگرداند
• Content-Type : application/vnd.gsma.eap-relay.v1.0+json

فیلدهای درخواست اندروید

• eap-relay-packet : حاوی بسته eap-relay پاسخ EAP-AKA قبلی است اما در قالب EAP-Response/AKA-Challenge به دنبال RFC 4817 - بخش 9.2 .

EAP-AKA #2 - پاسخ از ECS

پس از احراز هویت موفقیت‌آمیز EAP-AKA، شرکت مخابراتی یک توکن احراز هویت را برمی‌گرداند.

هدرهای پاسخ ECS

• Content-Type : اندروید انتظار دارد که پاسخی که با سرصفحه پذیرش درخواست مطابقت داشته باشد
  • یعنی اندروید انتظار دارد که پاسخ با توکن auth نوع text/vnd.wap.connectivity-xml داشته باشد.
  • هدر دیگر Accept، application/vnd.gsma.eap-relay.v1.0+json ، در صورتی است که شرکت مخابراتی بخواهد Android درخواست EAP-AKA دیگری را انجام دهد.

فیلدهای پاسخ ECS

• TOKEN.token : حاوی نشانه auth است
• TOKEN.validity : تعداد ثانیه هایی که پاسخ معتبر است، پس از اینکه دستگاه پاسخ را دریافت کرد
  • Google تأیید می‌کند که نشانه تأییدیه مطابق با الزامات فنی است

توکن موقت را بدست آورید

AcquireTempToken - دریافت درخواست به ECS

با استفاده از رمز تأیید دریافت شده از EAP-AKA، مشتری Android با فراخوانی نقطه پایانی AcquireTemporaryToken شرکت مخابراتی، رمز موقت را واکشی می کند. درخواست

• مثال : TS.43 v12.0 - بخش 6.4.6 - "مثال درخواست AcquireTemporaryToken"
• AcquireTempToken دارای پارامترهای مشابه EAP-AKA #1 است، به جز:
  • AcquireTempToken همچنین IMSI, operation و operation_targets را مشخص می کند
  • AcquireTempToken EAP_ID مشخص نمی کند

هدرهای درخواست اندروید

• Accept : Android text/vnd.wap.connectivity-xml را تنظیم می‌کند

فیلدهای درخواست اندروید

• terminal_vendor/model/sw_version : Android تضمین نمی‌کند که این فیلدها حاوی اطلاعات واقعی دستگاه باشند.
• operation_targets
  • Firebase PNV : هدف عملیات GetPhoneNumber است

AcquireTempToken - پاسخ از ECS

مثال : TS.43 v12.0 - بخش 6.6.6 - "مثال پاسخگویی موقت توکن"

هدرهای پاسخ ECS

• Content-Type : اندروید انتظار دارد که نوع پاسخ با سرصفحه پذیرش درخواست مطابقت داشته باشد
  • یعنی text/vnd.wap.connectivity-xml

فیلدهای پاسخ ECS

• APPLICATION.TemporaryToken : TemporaryToken که سرور Firebase PNV می تواند آن را با شماره تلفن مبادله کند.
• APPLICATION.TemporaryTokenExpiry : زمان انقضا در قالب YYYY-MM-DDTh:mm:ssTZD
  • Google تأیید خواهد کرد که انقضای TempToken الزامات فنی را برآورده می کند
• APPLICATION.OperationResult : به TS.43 v12.0 - بخش 6.5.1 مراجعه کنید.
  • به طور خاص، اگر عملیات به عنوان یک SUCCESS ، سپس 1 را برگردانید

مرحله 2 - TempToken را با شماره تلفن تعویض کنید

گزینه 1 - وانیل TS.43

نقاط پایانی : نقاط پایانی OAuth و GetPhoneNumber می توانند سرورها/نقاط پایانی متفاوتی از یکدیگر باشند. این نقاط پایانی همچنین می توانند با نقطه پایانی EAP-AKA/AcquireTempToken متفاوت باشند.

OAuth

شرکت مخابراتی باید این راهنمای OAuth را دنبال کند و اطلاعات OAuth لازم را به Google ارائه دهد (شناسه مشتری، راز مشتری، URL سرور OAuth)

OAuth - ارسال درخواست به سرور تأییدیه حامل

هدرهای درخواست Firebase PNV

• Authorization : Firebase PNV Basic $BASE64_ENCODED_CREDENTIALS را تنظیم خواهد کرد
  • اعتبارنامه‌های کدگذاری‌شده base64، کدگذاری base64 از OAuth $CLIENT_ID:$CLIENT_SECRET هستند.
• Content-Type : Firebase PNV application/x-www-form-urlencoded را تنظیم می کند
• Accept : Firebase PNV application/json را تنظیم می‌کند

فیلدهای درخواست Firebase PNV

• 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 : Firebase PNV انتظار دارد که نوع پاسخ با سرصفحه پذیرش درخواست مطابقت داشته باشد.
  • یعنی 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 - ارسال درخواست به ECS

سرور تأیید Google شماره تلفن را با استفاده از عملیات GetPhoneNumber واکشی می کند.

• مثال : TS.43 v12.0 - بخش 6.4.7 - "مثال درخواست شماره تلفن دریافت کنید"

هدرهای درخواست Firebase PNV

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

فیلدهای درخواست Firebase PNV

• requestor_id : سرویسی را که عملیات GetPhoneNumber TS.43 را فراخوانی می کند، شناسایی می کند.
  • UUID تأیید شماره تلفن Firebase : 191fd7cc-f7cd-4bb4-a5d2-455ae1fb9a19
• temporary_token : TemporaryToken از AcquireTempToken
• access_token : توکن OAuth برای Google تا با شرکت مخابراتی احراز هویت کند
• terminal_vendor/model/sw_version : Firebase PNV این فیلدها را با مقادیر دلخواه پر می کند
• entitlement_version : Google نسخه حق ارسال شده به شرکت‌های مخابراتی را بر اساس درخواست شرکت مخابراتی پیکربندی می‌کند.
  • به طور معمول، entitlement_version 10.0 یا 12.0 است
• app : Firebase PNV ap2014 را تنظیم می کند
• app_name : Firebase PNV firebase برای همه درخواست‌های Firebase PNV تنظیم می‌کند
  • توجه : AcquireTempToken یک app_name از Google-OGI خواهد داشت، صرف نظر از اینکه کدام جمع‌کننده استفاده می‌شود
• operation : Firebase PNV GetPhoneNumber تنظیم می کند

GetPhoneNumber - پاسخ از ECS

مثال : TS.43 v12.0 - بخش 6.6.7 - "مثال پاسخ شماره تلفن دریافت کنید"

سرصفحه های پاسخ حامل

• Content-Type : Firebase PNV انتظار دارد که نوع پاسخ با سرصفحه پذیرش درخواست مطابقت داشته باشد.
  • یعنی application/json

فیلدهای پاسخ حامل

• ap2014.MSISDN : Firebase PNV انتظار دارد شماره تلفن در قالب E164 بازگردانده شود
  • JSON به حروف کوچک و بزرگ حساس است، بنابراین MSISDN باید با حروف بزرگ نوشته شود

کدهای خطای موقت توکن

مراجع از TS.43 v12.0 ، بخش 2.8.6.

جدول زیر به جزئیات پاسخ‌های خرابی می‌پردازد که انتظار می‌رود ECS برای درخواست‌های GetPhoneNumber به سرور تأیید Google بازگرداند:

گزینه 2 - CAMARA

نقاط پایانی : بازیابی رمز دسترسی CAMARA و بازیابی شماره تلفن می تواند سرورها/نقاط پایانی متفاوتی از یکدیگر باشد. این نقاط پایانی همچنین می توانند با نقطه پایانی EAP-AKA / AcquireTempToken متفاوت باشند.

OAuth - رمز دسترسی CAMARA را بازیابی کنید

Google فقط از جریان حامل JWT CAMARA و نه جریان CIBA پشتیبانی خواهد کرد.

CAMARA Access Token - POST Request to Carrier

گوگل یک JWT با فیلدهای زیر ایجاد خواهد کرد.

• iss : صادرکننده JWT (با نام مستعار Client ID)
  • یعنی firebase (ادغام واقعی Firebase PNV) یا fpnv-carrier-tester-app (برنامه آزمایش حامل)
• sub : موضوع JWT
  • به عنوان مثال operatortoken:$TEMP_TOKEN
• aud : مخاطب; گیرندگانی که JWT برای آنها در نظر گرفته شده است
  • نشانی وب نقطه پایانی رمز (یعنی نشانی وب سرور مجوز)
• 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"
}

Firebase PNV JWT را با استفاده از کلید خصوصی خود امضا می کند و شرکت مخابراتی می تواند JWT را با استفاده از کلید عمومی مربوطه تأیید کند. Firebase PNV کلید عمومی را با استفاده از نقطه پایانی JWKS ارائه می کند. اپراتورها باید به طور منظم این نقطه پایانی JWKS را برای کلید عمومی نظرسنجی کنند (به عنوان مثال یک بار در روز)، زیرا Firebase PNV کلیدهای عمومی را با سرعتی منظم می چرخاند (مثلاً هر 30 روز یک بار).

هدرهای درخواست Firebase PNV

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

فیلدهای درخواست Firebase PNV

• grant_type : urn:ietf:params:oauth:grant-type:jwt-bearer
• assertion : JWT ایجاد شده در بالا و امضا شده با کلید خصوصی Firebase PNV
  • قابل ذکر است، این 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 Access Token - پاسخ از حامل

سرصفحه های پاسخ حامل

• Content-Type : Firebase PNV انتظار دارد که نوع پاسخ با سرصفحه پذیرش درخواست مطابقت داشته باشد.
  • یعنی 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 نسخه 2

سپس Google آن رمز دسترسی CAMARA را با ارسال یک درخواست GET به نقطه پایانی /device-phone-number شرکت مخابراتی مبادله می کند.

CAMARA NumberVerification - دریافت درخواست به شرکت مخابراتی

هدرهای درخواست Firebase PNV

• 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 - پاسخ از حامل

سرصفحه های پاسخ حامل

• Content-Type : Firebase PNV انتظار دارد که نوع پاسخ با سرصفحه پذیرش درخواست مطابقت داشته باشد.
  • یعنی application/json

فیلدهای پاسخ حامل

• devicePhoneNumber : شماره تلفن را در قالب E164 برمی گرداند

200 OK
Content-Type: application/json

{
 "devicePhoneNumber": $PHONE_NUMBER
}