Przewodnik techniczny dotyczący wdrażania FPNV dla operatorów

Data ostatniej modyfikacji: 10 września 2025 r.

Przegląd

Ten dokument zawiera wszystkie obowiązkowe kroki, które należy wykonać, aby wdrożyć weryfikację numeru telefonu w Firebase (FPNV) za pomocą weryfikacji numeru telefonu TS.43.

Terminologia

Strony

  • CSP: dostawca usług komunikacyjnych
    • np. operatorzy komórkowi
  • Agregatory
    • Agregatorzy współpracujący z aplikacjami: agregator, który umożliwia aplikacjom przeprowadzenie weryfikacji bez bezpośredniej interakcji z operatorem.
    • np. weryfikacja numeru telefonu w Firebase
    • Meta-Aggregator: pośrednik, który pomaga przewoźnikowi w integracji z pośrednikiem dostępnym w aplikacji.
      • Metaagregator może odpowiadać za konfigurowanie serwerów uprawnień dla operatorów lub konfigurowanie szczegółów serwerów uprawnień za pomocą agregatorów aplikacji.
  • FPNV: Firebase Phone Number Verification
  • Techniczny menedżer konta Google: pomaga operatorowi w integracji z FPNV.
  • Telefonia na Androidzie: udostępnia interfejsy API numerów telefonów na Androidzie, w tym platformę dla operatorów i agregatorów do przeprowadzania weryfikacji TS.43.
  • GSMA: stowarzyszenie operatorów sieci komórkowych, które określa specyfikacje, w tym TS.43.
  • CAMARA: projekt open source w systemie Linux, który definiuje interfejsy API operatorów we współpracy z GSMA.

Warunki weryfikacji

  • PNV: weryfikacja numeru telefonu
  • TS.43: określa protokół komunikacji między klientami mobilnymi a serwerami operatora za pomocą HTTP.
  • EAP-AKA: metoda uwierzytelniania zdefiniowana w dokumencie https://www.rfc-editor.org/rfc/rfc4187, która nie wymaga interakcji z użytkownikiem.
  • ECS: serwer konfiguracji uprawnień.
    • Punkt wejścia, w którym agregator może kontaktować się z przewoźnikiem.
  • ODSA: On-Device Service Activation
    • Odnosi się do różnych operacji wykonywanych przez ECS w celu aktywowania usług na urządzeniu.
    • np. AcquireTemporaryToken, GetPhoneNumber

Serwer uprawnień operatora i punkt końcowy PNV

Tworzenie niezbędnych punktów końcowych

ACTION1: przewoźnik wdraża te punkty końcowe, które są dostępne przez internet. Więcej informacji o wdrażaniu znajdziesz w Załączniku A.

Wymagania techniczne

Ogólna wydajność: czas działania wszystkich punktów końcowych musi wynosić co najmniej 99,99%.

Bezpieczeństwo: ze względów bezpieczeństwa punkty końcowe operatora muszą spełniać te wymagania:

  • Token uwierzytelniania EAP-AKA: musi wygasnąć w ciągu 1 godziny.
  • Token tymczasowy: jednorazowy token, który wygasa po 5 minutach.
  • Opcja 1. Zwykły TS.43
    • Token OAuth: musi wygasnąć w ciągu 1 godziny.
  • Opcja 2. CAMARA
    • Token dostępu CAMARA: jednorazowy, wygasa po 5 minutach.

Jakość danych interfejsu API: 100% zawartości odpowiedzi (czyli numer MSISDN powinien być prawidłowy).

FPNV obsługuje 2 wersje TS.43. Główna różnica polega na tym, jak serwer FPNV wymienia TempToken z operatorem.

  • Vanilla TS.43: odnosi się do implementacji zgodnie ze specyfikacją TS.43.
  • CAMARA: odnosi się do implementacji zgodnie z przepływem tokena JWT określonym przez CAMARA.

Opcja 1. Implementacja TS.43 w wersji podstawowej

Żądania z urządzenia z Androidem

  1. Punkt końcowy EAP-AKA: zwraca token autoryzacji.
  2. Punkt końcowy AcquireTemporaryToken: na podstawie tokena autoryzacji zwraca TempToken.

Żądania z serwera FPNV

  1. Punkt końcowy OAuth 2.0 – przepływ identyfikatora klienta OAuth i tajnego klucza klienta OAuth: na podstawie identyfikatora klienta OAuth i tajnego klucza klienta OAuth zwraca token dostępu OAuth.
  2. Punkt końcowy GetPhoneNumber: na podstawie tokena dostępu OAuth i tokena tymczasowego zwraca odpowiedni numer telefonu.

Opcja 2. Implementacja CAMARA

Implementacja CAMARA jest podobna do standardowej implementacji TS.43, z wyjątkiem punktów końcowych obsługujących żądania z serwera FPNV.

Żądania z urządzenia z Androidem

  1. Punkt końcowy EAP-AKA: zwraca token autoryzacji.
  2. Punkt końcowy AcquireTemporaryToken: na podstawie tokena autoryzacji zwraca TempToken.

Żądania z serwera FPNV

  1. Punkt końcowy OAuth 2.0 – przepływ tokena JWT okaziciela: na podstawie tokena JWT zawierającego TempToken zwraca token dostępu CAMARA.
  2. Punkt końcowy CAMARA NumberVerification v2: na podstawie tokena dostępu CAMARA zwraca odpowiedni numer telefonu.

Wprowadzenie do telefonii na Androidzie i usługi FPNV

Aplikacja testowa operatora

ACTION2: Operator kontaktuje się z Technicznym menedżerem konta Google (TAM), który udostępnia mu aplikację testową operatora FPNV. Ta aplikacja testowa operatora imituje żądania, które będą wysyłane przez FPNV, bez udziału serwera FPNV. Ta aplikacja testowa operatora jest przydatna do sprawdzania, czy punkty końcowe działają prawidłowo.

ACTION3: operator sprawdza, czy powyższe punkty końcowe działają kompleksowo, korzystając z aplikacji testowej operatora FPNV.

Konfigurowanie niezbędnych ustawień produkcji

Android Config - EAP-AKA / AcquireTempToken

ACTION4: operator określa konfigurację produkcyjną dla żądań EAP-AKA/AcquireTempToken z Android Telephony

  • Konfiguracja:
    • Kanoniczny identyfikator operatora Androida tego operatora.
    • Wartości TS.43 use_cases: use_case=GetPhoneNumber
    • Adres URL serwera uprawnień w wersji produkcyjnej dla EAP-AKA/AcquireTempToken
    • SAN i odcisk cyfrowy produkcyjnego certyfikatu x509 Firebase
    • SAN: fpnv.googleapis.com
    • Odcisk palca: aad068c93399a22fc2b11ab58468e8cb72b8f9fc53700991799a8b764c589c7e

Konfiguracja Firebase – wymiana tymczasowego tokena na token telefonu

ACTION5: dane logowania Firebase do pobierania tokena OAuth od operatora

  • Vanilla TS.43
    • Operator tworzy identyfikator klienta OAuth i tajny klucz na potrzeby żądań FPNV. Operator konfiguruje następnie swój punkt końcowy OAuth, aby zwracał token dostępu dla tych danych logowania.
  • CAMARA
    • Menedżer ds. klientów strategicznych Google udostępnia klucz publiczny Google, aby punkt końcowy OAuth operatora mógł zweryfikować, czy token JWT został podpisany przez Google.

ACTION6: Operator określa konfigurację produkcyjną serwera FPNV, aby wymieniać TempToken na telefon.

  • Kanoniczny identyfikator operatora Androida tego operatora sieci komórkowej.
  • Vanilla TS.43
    • OAuth – proces identyfikatora klienta i tajnego klucza
    • URL punktu końcowego OAuth
    • Identyfikator klienta OAuth/tajny klucz
    • Zakres protokołu OAuth (jeśli obowiązuje)
    • GetPhoneNumber
    • URL punktu końcowego GetPhoneNumber
  • CAMARA
    • OAuth – przepływ okaziciela JWT
    • URL punktu końcowego OAuth
    • NumberVerification API w wersji 2
    • URL punktu końcowego NumberVerification

Udostępnianie danych logowania i konfiguracji

Weryfikacja numeru telefonu w Firebase

ACTION7: operator udostępnia menedżerowi technicznemu Google konfigurację produkcyjną z ACTION4ACTION6.

  • [WAŻNE] Tajny klucz protokołu OAuth musi być udostępniany Google za pomocą bezpiecznego mechanizmu poza pasmem (bez e-maili, dokumentów itp.). Ten mechanizm poza pasmem zostanie uzgodniony przez operatora i opiekuna klienta Google.

ACTION8: zespół TAM Google sprawdza, czy konfiguracja działa kompleksowo, korzystając z aplikacji testowej operatora. Następnie zapisuje dane logowania OAuth w bezpiecznym miejscu w Google i aktualizuje konfiguracje FPNV, aby wymieniać TempToken na telefon (czyli konfiguracje ACTION6).

Połączenia telefoniczne na Androidzie

ACTION9: operator postępuje zgodnie z dokumentem „Google Open Gateway CSP Onboarding” (który zostanie mu udostępniony przez opiekuna klienta Google). Operator lub jego opiekun klienta Google otwiera zgłoszenie w Buganizerze, aby wdrożyć konfigurację telefonii na Androidzie: https://issuetracker.google.com/issues/new?component=1861595&template=2168610. Ten błąd zostanie uwzględniony w konfiguracji produkcyjnej z ACTION4.

Jeśli metaagregator konfiguruje integrację FPNV w imieniu przewoźnika, oświadczenie o zgodzie (e-mail, PDF, list itp.) od kierownictwa przewoźnika (na poziomie dyrektora lub wyższym) musi potwierdzać relacje biznesowe z tym operatorem. Następnie metaagregator może w imieniu operatora przekazać konfigurację operatora do Telefonu na Androidzie.

Załącznik A. Szczegółowa implementacja

Rozróżnianie wielkości liter

  • W nagłówkach HTTP nie jest rozróżniana wielkość liter.
  • Formaty XML i JSON uwzględniają jednak wielkość liter. W przypadku pól żądania/odpowiedzi upewnij się, że są one zgodne z tą dokumentacją.

Krok 1. EAP-AKA / AcquireTempToken

Diagram przedstawiający urządzenie wykonujące EAP-AKA i AcquireTempToken w celu pobrania tokena tymczasowego z serwera operatora.
Rysunek 1. Urządzenie pobiera TempToken z serwera operatora, wykonując EAP-AKA, a następnie AcquireTempToken. Krok 2. Wymiana tymczasowego tokena na numer telefonu zawiera szczegółowe informacje o tym, jak wymienić tymczasowy token na numer telefonu.

Punkty końcowe: EAP-AKA i AcquireTempToken muszą używać tego samego punktu końcowego ECS.

EAP-AKA Challenge

Referencje: TS.43 v12.0 – sekcja 2.8.1 – „Embedded EAP-AKA Authentication by Entitlement Configuration Server”.

EAP-AKA Step 1 - Authentication Challenge
EAP-AKA #1 - GET Request to ECS

Moduł telefonii Androida wysyła żądanie TS.43 EAP-AKA do serwera uprawnień operatora.

Nagłówki żądań Androida

  • Accept: application/vnd.gsma.eap-relay.v1.0+json
    • Jest to format JSON specyficzny dla GSMA, a nie tylko application/json

Pola żądania Androida

  • eap_id: patrz RCC.14 Annex C
    • np. 0<IMSI>@<realm>.mnc<MNC>.mcc<MCC>.3gppnetwork.org
  • GID1: podany tylko wtedy, gdy wersja uprawnień to 12.0
  • app_name: zakodowana nazwa aplikacji będzie zawierać wartość skrótu MD5 przypadku użycia, w którym przeprowadzana jest weryfikacja telefonu:
    • Wszystkie żądania agregatora kierowane do aplikacji będą miały nazwę aplikacji Google-OGI.
  • app: identyfikator aplikacji ap2014 reprezentuje informacje o numerze telefonu.
  • terminal_vendor/model/sw_version: ustaw na dowolną wartość; Android nie gwarantuje, że te pola będą zawierać rzeczywiste informacje o urządzeniu.
  • vers: wersja konfiguracji, np.0 lub 1.
  • entitlement_version: Google skonfiguruje wersję uprawnień wysyłaną do przewoźników na podstawie ich żądań.
    • Zwykle entitlement_version wynosi 10,0 lub 12,0.
EAP-AKA #1 - Response from ECS

Nagłówki odpowiedzi ECS

  • Content-Type: Android oczekuje, że typ odpowiedzi będzie zgodny z nagłówkiem Accept w żądaniu.
    • np. application/vnd.gsma.eap-relay.v1.0+json

Pola odpowiedzi ECS

EAP-AKA Step 2 - Get Auth Token
EAP-AKA #2 - POST Request to ECS

Moduł telefonii Androida odeśle otrzymane eap-relay-packet do tego samego punktu końcowego.

Nagłówki żądań Androida

  • Accept: Android ustawi 2 nagłówki Accept:
    • application/vnd.gsma.eap-relay.v1.0+json: odnosi się do operatora, który ponownie zwraca JSON, jeśli urządzenie musi ponownie wysłać żądanie EAP-AKA.
    • text/vnd.wap.connectivity-xml: odnosi się do formatu, w jakim Android oczekuje, że operator zwróci token uwierzytelniania EAP-AKA.
  • Content-Type: application/vnd.gsma.eap-relay.v1.0+json

Pola żądania Androida

  • eap-relay-packet: zawiera poprzedni pakiet eap-relay-packet odpowiedzi EAP-AKA, ale w formacie EAP-Response/AKA-Challenge zgodnie z dokumentem RFC 4817 – sekcja 9.2.
EAP-AKA #2 - Response from ECS

Po pomyślnym uwierzytelnieniu EAP-AKA operator zwraca token uwierzytelniania.

Nagłówki odpowiedzi ECS

  • Content-Type: Android oczekuje, że odpowiedź będzie zgodna z nagłówkiem Accept w żądaniu.
    • Oznacza to, że Android oczekuje, że odpowiedź z tokenem autoryzacji będzie miała typ text/vnd.wap.connectivity-xml.
    • Drugi nagłówek Accept, application/vnd.gsma.eap-relay.v1.0+json, jest używany, gdy operator chce, aby Android wykonał kolejne żądanie EAP-AKA.

Pola odpowiedzi ECS

  • TOKEN.token: zawiera token uwierzytelniania.
  • TOKEN.validity: liczba sekund, przez które odpowiedź jest ważna po otrzymaniu jej przez urządzenie.

AcquireTemporary Token

AcquireTempToken – żądanie GET do ECS

Za pomocą tokena uwierzytelniania otrzymanego z EAP-AKA klient Androida pobiera token tymczasowy, wywołując punkt końcowy AcquireTemporaryToken operatora. Żądanie

  • Przykład: TS.43 v12.0 – Section 6.4.6 – „AcquireTemporaryToken Request Example”
  • Funkcja AcquireTempToken ma podobne parametry jak EAP-AKA #1, z wyjątkiem:
    • Funkcja AcquireTempToken określa też IMSI, operationoperation_targets.
    • Funkcja AcquireTempToken nie określa parametru EAP_ID

Nagłówki żądań Androida

  • Accept: Android ustawi wartość text/vnd.wap.connectivity-xml.

Pola żądania Androida

  • terminal_vendor/model/sw_version: Android nie gwarantuje, że te pola zawierają informacje o rzeczywistym urządzeniu.
  • operation_targets
    • FPNV: docelowa operacja to GetPhoneNumber

AcquireTempToken – odpowiedź z ECS

Przykład: TS.43 v12.0 – Section 6.6.6 – „AcquireTemporaryToken Response Example”

Nagłówki odpowiedzi ECS

  • Content-Type: Android oczekuje, że typ odpowiedzi będzie zgodny z nagłówkiem Accept w żądaniu.
    • np. text/vnd.wap.connectivity-xml

Pola odpowiedzi ECS

  • APPLICATION.TemporaryToken: TemporaryToken, który serwer FPNV może następnie wymienić na numer telefonu.
  • APPLICATION.TemporaryTokenExpiry: czas wygaśnięcia w formacie RRRR-MM-DDTgg:mm:ssTZD
  • APPLICATION.OperationResult: patrz TS.43 v12.0 – sekcja 6.5.1
    • Jeśli operacje są typu SUCCESS, zwróć wartość 1.

Krok 2. Wymień TempToken na numer telefonu

Opcja 1. Vanilla TS.43

Diagram przedstawiający serwer Google wymieniający tymczasowy token na zweryfikowany numer telefonu z operatorem za pomocą protokołu Vanilla TS.43.
Rysunek 2a. Serwer Google przekazuje następnie TempToken operatorowi w zamian za zweryfikowany numer telefonu, wywołując funkcję GetPhoneNumber. Ten diagram pomija krok 1 – EAP-AKA / AcquireTempToken.

Punkty końcowe: punkty końcowe OAuth i GetPhoneNumber mogą być różnymi serwerami lub punktami końcowymi. Te punkty końcowe mogą się też różnić od punktu końcowego EAP-AKA/AcquireTempToken.

OAuth

Operator powinien postępować zgodnie z tym przewodnikiem po OAuth i przekazać Google niezbędne informacje o OAuth (identyfikator klienta, tajny klucz klienta, adres URL serwera OAuth).

OAuth – żądanie POST do serwera uwierzytelniania operatora

Nagłówki żądania FPNV

  • Authorization: FPNV ustawi Basic $BASE64_ENCODED_CREDENTIALS
    • Dane logowania zakodowane w formacie base64 to kodowanie base64 OAuth $CLIENT_ID:$CLIENT_SECRET
  • Content-Type: FPNV ustawi wartość application/x-www-form-urlencoded
  • Accept: FPNV ustawi wartość application/json

Pola żądania FPNV

  • 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 – odpowiedź serwera autoryzacji operatora

Nagłówki odpowiedzi operatora

  • Content-Type: FPNV oczekuje, że typ odpowiedzi będzie zgodny z nagłówkiem Accept w żądaniu.
    • np. application/json

Pola odpowiedzi operatora

  • access_token: token dostępu OAuth
  • token_type: bearer
  • expires_in: czas wygaśnięcia tokena dostępu OAuth w sekundach.
200 OK
Content-Type: application/json

{
  "access_token": $ACCESS_TOKEN,
  "token_type": "bearer",
  "expires_in": $EXPIRATION_IN_SECS,
}
GetPhoneNumber
GetPhoneNumber – żądanie POST do ECS

Serwer weryfikacyjny Google pobiera numer telefonu za pomocą operacji GetPhoneNumber.

Nagłówki żądań FPNV

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

Pola żądania FPNV

  • requestor_id: identyfikuje usługę wywołującą operację GetPhoneNumber TS.43.
    • Identyfikator UUID weryfikacji numeru telefonu w Firebase: 191fd7cc-f7cd-4bb4-a5d2-455ae1fb9a19
  • temporary_token: TemporaryToken z funkcji AcquireTempToken
  • access_token: token OAuth dla Google do uwierzytelniania u operatora.
  • terminal_vendor/model/sw_version: FPNV będzie wypełniać te pola dowolnymi wartościami.
  • entitlement_version: Google skonfiguruje wersję uprawnień wysyłaną do przewoźników na podstawie ich żądań.
    • Zwykle entitlement_version wynosi 10,0 lub 12,0.
  • app: FPNV ustawi wartość ap2014
  • app_name: FPNV ustawi wartość firebase dla wszystkich żądań FPNV.
    • Uwaga: funkcja AcquireTempToken będzie miała wartość app_name Google-OGI, niezależnie od tego, którego agregatora używasz.
  • operation: FPNV ustawi wartość GetPhoneNumber
GetPhoneNumber – odpowiedź z ECS

Przykład: TS.43 v12.0 – Section 6.6.7 – „GetPhoneNumber Response Example”

Nagłówki odpowiedzi operatora

  • Content-Type: FPNV oczekuje, że typ odpowiedzi będzie zgodny z nagłówkiem Accept w żądaniu.
    • np. application/json

Pola odpowiedzi operatora

  • ap2014.MSISDN: FPNV oczekuje, że numer telefonu zostanie zwrócony w formacie E164.
    • W przypadku formatu JSON wielkość liter ma znaczenie, więc numer MSISDN musi być zapisany wielkimi literami.
Kody błędów TemporaryToken

Odwołania z dokumentu TS.43 v12.0, sekcja 2.8.6.

W tabeli poniżej znajdziesz szczegółowe informacje o odpowiedziach o błędzie, które ECS powinien zwracać do serwera weryfikacji Google w przypadku żądań GetPhoneNumber:

Scenariusz

Kod odpowiedzi GET/POST z ECS

Działanie serwera firmy zewnętrznej

Nieprawidłowe lub brakujące parametry albo nieprawidłowy format w żądaniu

400 Nieprawidłowe żądanie

Ponów przy następnym wywołaniu przez użytkownika lub po ponownym uruchomieniu klienta

Nieprawidłowy lub nieważny token tymczasowy w żądaniu

401 Brak autoryzacji

Jeśli to możliwe, wywołaj na urządzeniu pobranie (nowego) ważnego tokena tymczasowego z ECS.

Nieprawidłowa operacja w połączeniu z tymczasowym tokenem

403 Dostęp zabroniony

Ponów przy następnym wywołaniu przez użytkownika lub po ponownym uruchomieniu klienta

Nie znaleziono żądanego zasobu

404 – nie znaleziono

Ponów przy następnym wywołaniu przez użytkownika lub po ponownym uruchomieniu klienta

Podczas przetwarzania żądania w ECS wystąpił błąd wewnętrzny

500 Wewnętrzny błąd serwera

Ponów przy następnym wywołaniu przez użytkownika lub po ponownym uruchomieniu klienta

Opcja 2. CAMARA

Diagram przedstawiający serwer Google wymieniający tymczasowy token na zweryfikowany numer telefonu z operatorem za pomocą przepływu nośnika JWT CAMARA.
Rysunek 2b. Serwer Google przekazuje TempToken operatorowi w zamian za zweryfikowany telefon, wykonując przepływ nośnika JWT CAMARA. Ten diagram pomija krok 1 – EAP-AKA / AcquireTempToken.

Punkty końcowe: pobieranie tokena dostępu CAMARA i pobieranie numeru telefonu mogą odbywać się na różnych serwerach lub w różnych punktach końcowych. Te punkty końcowe mogą się też różnić od punktu końcowego EAP-AKA / AcquireTempToken.

OAuth – pobieranie tokena dostępu CAMARA

Google będzie obsługiwać tylko przepływ nośnika JWT w CAMARA, a nie przepływ CIBA.

Token dostępu CAMARA – żądanie POST do operatora

Google utworzy token JWT z tymi polami:

  • iss: wystawca tokena JWT (czyli identyfikator klienta).
    • np. firebase (rzeczywista integracja FPNV) lub fpnv-carrier-tester-app (aplikacja testowa operatora)
  • sub: podmiot tokena JWT.
    • np. operatortoken:$TEMP_TOKEN
  • aud: odbiorcy, do których jest kierowany token JWT.
    • URL punktu końcowego tokena (czyli URL serwera autoryzacji)
  • exp: czas do wygaśnięcia w sekundach.
    • Google wyśle czas ważności, który odpowiada okresowi ważności tokena dostępu CAMARA (patrz Wymagania techniczne).
  • iat: Issued at time in seconds
  • jti: unikalny identyfikator zapobiegający atakom typu replay.
    • np.losowo wygenerowany identyfikator UUID.
  • scope: Cel żądania
    • np. 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 podpisze token JWT własnym kluczem prywatnym, a operator może zweryfikować token JWT za pomocą odpowiedniego klucza publicznego. FPNV udostępni klucz publiczny za pomocą punktu końcowego JWKS. Operatorzy powinni regularnie odpytywać ten punkt końcowy JWKS o klucz publiczny (np. raz dziennie), ponieważ FPNV będzie regularnie poddawać klucze publiczne rotacji (np. raz na 30 dni).

Nagłówki żądań FPNV

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

Pola żądania FPNV

  • grant_type: urn:ietf:params:oauth:grant-type:jwt-bearer
  • assertion: token JWT utworzony powyżej i podpisany za pomocą klucza prywatnego FPNV.
    • Ten token JWT zawiera 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
Token dostępu CAMARA – odpowiedź operatora

Nagłówki odpowiedzi operatora

  • Content-Type: FPNV oczekuje, że typ odpowiedzi będzie zgodny z nagłówkiem Accept w żądaniu.
    • np. application/json

Pola odpowiedzi operatora

  • access_token: token dostępu CAMARA, który można później wymienić na numer telefonu.
  • token_type: bearer
  • expires_in: czas wygaśnięcia tokena dostępu OAuth w sekundach.
  • scope: Cel żądania
    • np. 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 w wersji 2

Następnie Google wymieni ten token dostępu CAMARA, wysyłając żądanie GET do punktu końcowego operatora /device-phone-number.

CAMARA NumberVerification - GET Request to Carrier

Nagłówki żądań 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

Nagłówki odpowiedzi operatora

  • Content-Type: FPNV oczekuje, że typ odpowiedzi będzie zgodny z nagłówkiem Accept w żądaniu.
    • np. application/json

Pola odpowiedzi operatora

  • devicePhoneNumber: zwraca numer telefonu w formacie E164.
200 OK
Content-Type: application/json

{
 "devicePhoneNumber": $PHONE_NUMBER
}