Hướng dẫn kỹ thuật cho nhà mạng mới tham gia FPNV

Ngày sửa đổi gần đây nhất: 10/9/2025

Tổng quan

Tài liệu này ghi lại tất cả các bước bắt buộc để tích hợp một nhà mạng vào quy trình Xác minh số điện thoại bằng Firebase (FPNV) thông qua quy trình xác minh số điện thoại TS.43.

Thuật ngữ

Các bên liên quan

• CSP: Nhà cung cấp dịch vụ truyền thông
  • ví dụ: Nhà mạng di động
• Trang web tổng hợp
  • Trình tổng hợp hướng đến ứng dụng: Trình tổng hợp cho phép các ứng dụng thực hiện quy trình xác minh mà không cần ứng dụng tương tác trực tiếp với nhà mạng
  • ví dụ: Xác minh số điện thoại bằng Firebase
  • Meta-Aggregator: Đơn vị tập hợp hỗ trợ hãng vận chuyển tham gia vào một đơn vị tập hợp hướng đến ứng dụng
    • Một đơn vị tổng hợp cấp cao có thể chịu trách nhiệm thiết lập các máy chủ cấp quyền cho hãng vận chuyển và/hoặc định cấu hình thông tin chi tiết về máy chủ cấp quyền với các đơn vị tổng hợp hướng đến ứng dụng
• FPNV: Xác minh số điện thoại bằng Firebase
• TAM của Google: Nhà quản lý tài khoản hỗ trợ kỹ thuật của Google, người giúp hãng vận chuyển tham gia FPNV
• Dịch vụ điện thoại Android: Cung cấp các API số điện thoại trên Android, bao gồm cả một nền tảng để nhà mạng và đơn vị tổng hợp cung cấp quy trình xác minh TS.43
• GSMA: Hiệp hội các nhà mạng di động xác định các thông số kỹ thuật, bao gồm cả TS.43
• CAMARA: Dự án nguồn mở Linux xác định các API của nhà mạng khi hợp tác với GSMA

Điều khoản xác minh

• PNV: Xác minh số điện thoại
• TS.43: Xác định giao thức để máy chủ và ứng dụng di động giao tiếp với nhà mạng bằng HTTP
• EAP-AKA: Phương thức xác thực được xác định trong https://www.rfc-editor.org/rfc/rfc4187, không yêu cầu tương tác với người dùng
• ECS: Entitlement Configuration Server (Máy chủ cấu hình quyền)
  • Điểm truy cập để đơn vị tập hợp liên hệ với hãng vận chuyển
• ODSA: Kích hoạt dịch vụ trên thiết bị
  • Đề cập đến các thao tác khác nhau do ECS cung cấp để kích hoạt các dịch vụ trên thiết bị
  • ví dụ: AcquireTemporaryToken; GetPhoneNumber

Máy chủ cấp quyền của nhà cung cấp dịch vụ và điểm cuối PNV

Tạo các điểm cuối cần thiết

HÀNH ĐỘNG 1: Hãng vận chuyển triển khai các điểm cuối sau đây. Tất cả các điểm cuối này đều có thể truy cập qua Internet. Hãy xem Phụ lục A để biết thêm thông tin chi tiết về cách triển khai.

Yêu cầu về kỹ thuật

Hiệu suất chung: Thời gian hoạt động của tất cả các điểm cuối phải ít nhất là 99,99%.

Bảo mật: Vì lý do bảo mật, các điểm cuối của hãng vận chuyển phải đáp ứng các yêu cầu sau:

• Mã thông báo xác thực EAP-AKA: Phải hết hạn trong vòng 1 giờ
• Mã thông báo tạm thời: Chỉ dùng một lần và hết hạn sau 5 phút
• Cách 1 – TS.43 gốc
  • Mã thông báo OAuth: Phải hết hạn trong vòng 1 giờ
• Cách 2 – CAMARA
  • Mã truy cập CAMARA: Chỉ dùng một lần và có thời hạn 5 phút

Chất lượng dữ liệu API: 100% nội dung của các phản hồi thành công (tức là MSISDN phải chính xác).

FPNV hỗ trợ 2 phiên bản TS.43. Điểm khác biệt chính là cách máy chủ FPNV trao đổi TempToken với nhà mạng.

• Vanilla TS.43: Đề cập đến việc triển khai theo quy định của thông số kỹ thuật TS.43
• CAMARA: Đề cập đến việc triển khai theo quy định của quy trình truyền tải JWT của CAMARA

Lựa chọn 1 – Triển khai TS.43 nguyên bản

Yêu cầu từ thiết bị Android

1. Điểm cuối EAP-AKA: Trả về mã thông báo uỷ quyền
2. Điểm cuối AcquireTemporaryToken: Cho trước mã thông báo xác thực, trả về một TempToken

Yêu cầu từ Máy chủ FPNV

1. Điểm cuối OAuth 2.0 – Quy trình mã ứng dụng khách/khoá bí mật OAuth: Cho trước mã ứng dụng khách/khoá bí mật OAuth, trả về mã truy cập OAuth
2. Điểm cuối GetPhoneNumber: Cho trước mã truy cập OAuth và TempToken, hãy trả về số điện thoại tương ứng

Cách 2 – Triển khai CAMARA

Việc triển khai CAMARA tương tự như việc triển khai TS.43 thông thường, ngoại trừ các điểm cuối để xử lý các yêu cầu từ máy chủ FPNV.

Yêu cầu từ thiết bị Android

1. Điểm cuối EAP-AKA: Trả về mã thông báo uỷ quyền
2. Điểm cuối AcquireTemporaryToken: Cho trước một mã thông báo xác thực, trả về một TempToken

Yêu cầu từ Máy chủ FPNV

1. Điểm cuối OAuth 2.0 – Quy trình truyền mã thông báo JWT: Cho trước một JWT chứa TempToken, trả về mã truy cập CAMARA
2. Endpoint NumberVerification v2 của CAMARA: Với mã truy cập CAMARA, hãy trả về số điện thoại tương ứng

Tham gia dịch vụ Điện thoại Android và FPNV

Ứng dụng kiểm thử của nhà mạng

HÀNH ĐỘNG 2: Hãng vận chuyển liên hệ với Giám đốc Quản lý Khách hàng về Kỹ thuật (TAM) của Google và TAM sẽ chia sẻ ứng dụng kiểm thử hãng vận chuyển FPNV với hãng vận chuyển. Ứng dụng kiểm thử của nhà mạng này mô phỏng các yêu cầu mà FPNV sẽ gửi mà không liên quan đến máy chủ FPNV. Ứng dụng kiểm thử nhà mạng này hữu ích cho nhà mạng trong việc xác thực rằng các điểm cuối của họ đang hoạt động đúng cách.

HÀNH ĐỘNG 3: Nhà mạng xác minh rằng các điểm cuối nêu trên hoạt động từ đầu đến cuối bằng cách sử dụng ứng dụng kiểm thử nhà mạng FPNV.

Thiết lập các cấu hình cần thiết cho bản phát hành công khai

Cấu hình Android – EAP-AKA / AcquireTempToken

ACTION4: Nhà mạng xác định cấu hình sản xuất cho các yêu cầu EAP-AKA/AcquireTempToken từ Dịch vụ điện thoại Android

• Cấu hình:
  • Mã nhận dạng nhà mạng chuẩn của Android của nhà mạng này
  • Giá trị TS.43 use_cases: use_case=GetPhoneNumber
  • URL máy chủ quyền sản xuất cho EAP-AKA/AcquireTempToken
  • SAN và dấu vân tay của chứng chỉ x509 sản xuất của Firebase
  • SAN: fpnv.googleapis.com
  • Dấu vân tay: aad068c93399a22fc2b11ab58468e8cb72b8f9fc53700991799a8b764c589c7e

Cấu hình Firebase – Trao đổi TempToken cho điện thoại

ACTION5: Thông tin đăng nhập Firebase để truy xuất mã thông báo OAuth từ hãng vận chuyển

• Vanilla TS.43
  • Hãng vận chuyển tạo mã ứng dụng khách và khoá bí mật OAuth cho các yêu cầu của FPNV. Sau đó, nhà mạng sẽ định cấu hình điểm cuối OAuth để trả về mã truy cập cho những thông tin đăng nhập này
• CAMARA
  • Google TAM cung cấp khoá công khai của Google để điểm cuối OAuth của hãng vận chuyển có thể xác minh rằng JWT đã được Google ký

ACTION6: Nhà mạng xác định cấu hình sản xuất cho máy chủ FPNV để trao đổi TempToken cho điện thoại

• Mã nhận dạng nhà mạng chuẩn của Android của MNO này
• Vanilla TS.43
  • OAuth – Quy trình mã ứng dụng/khoá bí mật
  • URL điểm cuối OAuth
  • Mã ứng dụng/khoá bí mật của ứng dụng OAuth
  • Phạm vi OAuth (nếu có)
  • GetPhoneNumber
  • URL điểm cuối GetPhoneNumber
• CAMARA
  • OAuth – Luồng mã thông báo JWT
  • URL điểm cuối OAuth
  • NumberVerification API phiên bản 2
  • URL điểm cuối NumberVerification

Chia sẻ thông tin xác thực/cấu hình

Xác minh số điện thoại bằng Firebase

HÀNH ĐỘNG 7: Hãng vận chuyển chia sẻ cấu hình sản xuất từ HÀNH ĐỘNG 4 và HÀNH ĐỘNG 6 với Người quản lý tài khoản kỹ thuật của Google.

• [QUAN TRỌNG] Bạn phải chia sẻ bí mật OAuth bằng một cơ chế an toàn, ngoài băng tần (không dùng email, không dùng tài liệu, v.v.) với Google. Nhà mạng và TAM của Google sẽ thoả thuận về cơ chế ngoài băng tần này.

HÀNH ĐỘNG 8: TAM của Google xác thực rằng cấu hình hoạt động từ đầu đến cuối bằng ứng dụng kiểm thử của nhà mạng. Sau đó, TAM của Google sẽ lưu trữ thông tin đăng nhập OAuth trong một bộ nhớ an toàn của Google và cập nhật cấu hình của FPNV để trao đổi TempToken cho điện thoại (tức là cấu hình của HÀNH ĐỘNG 6).

Dịch vụ điện thoại Android

ACTION9: Nhà mạng làm theo tài liệu "Google Open Gateway CSP Onboarding" (mà TAM của Google sẽ chia sẻ với nhà mạng). Nhà mạng hoặc TAM của Google sẽ gửi một phiếu yêu cầu trên Buganizer để tham gia vào cấu hình của Android Telephony: https://issuetracker.google.com/issues/new?component=1861595&template=2168610. Lỗi này sẽ lấy cấu hình sản xuất từ ACTION4.

Nếu một đơn vị tổng hợp đang thiết lập chế độ tích hợp FPNV thay mặt cho hãng vận chuyển, thì một tuyên bố đồng ý (email, PDF, thư, v.v.) của ban lãnh đạo hãng vận chuyển (cấp Giám đốc trở lên) phải xác nhận mối quan hệ kinh doanh của họ với đơn vị tổng hợp đó. Sau đó, meta-aggregator có thể cung cấp cấu hình của nhà mạng thay cho nhà mạng cho Android Telephony.

Phụ lục A. Triển khai chi tiết

Phân biệt chữ hoa chữ thường

• Tiêu đề HTTP không phân biệt chữ hoa chữ thường
• Tuy nhiên, định dạng XML và JSON phân biệt chữ hoa chữ thường. Vì vậy, đối với các trường yêu cầu/phản hồi, hãy đảm bảo rằng các trường này khớp chính xác với tài liệu này.

Bước 1 – EAP-AKA / AcquireTempToken

Điểm cuối: EAP-AKA và AcquireTempToken phải sử dụng cùng một điểm cuối ECS.

Thử thách EAP-AKA

Tài liệu tham khảo: TS.43 phiên bản 12.0 – Mục 2.8.1 – "Xác thực EAP-AKA nhúng bằng máy chủ cấu hình quyền".

EAP-AKA Bước 1 – Thử thách xác thực

EAP-AKA #1 - GET Request to ECS

Mô-đun Điện thoại Android gửi yêu cầu TS.43 EAP-AKA đến máy chủ cấp quyền của nhà mạng.

Tiêu đề yêu cầu của Android

• Accept: application/vnd.gsma.eap-relay.v1.0+json
  • Đây là định dạng JSON dành riêng cho GSMA, chứ không chỉ là application/json

Các trường yêu cầu của Android

• eap_id: Xem Phụ lục C của RCC.14
  • tức là 0<IMSI>@<realm>.mnc<MNC>.mcc<MCC>.3gppnetwork.org
• GID1: Chỉ được chỉ định nếu phiên bản quyền là 12.0
• app_name: AppName được mã hoá sẽ có giá trị băm MD5 của trường hợp sử dụng đang thực hiện quy trình xác minh qua điện thoại:
  • Tất cả các yêu cầu của đơn vị tổng hợp hướng đến ứng dụng sẽ có tên ứng dụng là Google-OGI
• app: Mã ứng dụng ap2014 đại diện cho Thông tin về số điện thoại
• terminal_vendor/model/sw_version: Đặt thành một giá trị tuỳ ý; Android sẽ không đảm bảo rằng các trường này chứa thông tin thực tế của thiết bị
• vers: Phiên bản cấu hình; ví dụ: 0 hoặc 1
• entitlement_version: Google sẽ định cấu hình phiên bản quyền được gửi đến hãng vận chuyển dựa trên yêu cầu của hãng vận chuyển
  • Thông thường, entitlement_version là 10.0 hoặc 12.0

EAP-AKA #1 – Phản hồi của ECS

Tiêu đề phản hồi ECS

• Content-Type: Android dự kiến rằng loại phản hồi sẽ khớp với tiêu đề Chấp nhận của yêu cầu
  • tức là application/vnd.gsma.eap-relay.v1.0+json

Trường phản hồi ECS

• eap-relay-packet: Chứa gói EAP theo RCC.14 – Mục C.2

EAP-AKA Bước 2 – Nhận mã xác thực

EAP-AKA #2 – Yêu cầu POST đến ECS

Sau đó, mô-đun Điện thoại Android sẽ gửi lại eap-relay-packet đã nhận đến cùng một điểm cuối.

Tiêu đề yêu cầu của Android

• Accept: Android sẽ đặt 2 tiêu đề Accept:
  • application/vnd.gsma.eap-relay.v1.0+json: Đề cập đến nhà mạng trả về lại JSON nếu thiết bị cần gửi lại một yêu cầu EAP-AKA khác
  • text/vnd.wap.connectivity-xml: Đề cập đến định dạng thực tế mà Android sẽ mong đợi nhà mạng trả về mã thông báo xác thực EAP-AKA
• Content-Type: application/vnd.gsma.eap-relay.v1.0+json

Các trường yêu cầu của Android

• eap-relay-packet: Chứa eap-relay-packet của phản hồi EAP-AKA trước đó nhưng ở định dạng EAP-Response/AKA-Challenge theo RFC 4817 – Phần 9.2.

EAP-AKA #2 – Phản hồi từ ECS

Sau khi xác thực EAP-AKA thành công, nhà mạng sẽ trả lại mã thông báo uỷ quyền.

Tiêu đề phản hồi ECS

• Content-Type: Android dự kiến rằng phản hồi sẽ khớp với tiêu đề Chấp nhận của yêu cầu
  • tức là Android dự kiến rằng phản hồi có mã thông báo uỷ quyền sẽ có loại text/vnd.wap.connectivity-xml
  • Tiêu đề Accept khác, application/vnd.gsma.eap-relay.v1.0+json, là nếu nhà mạng muốn Android thực hiện một yêu cầu EAP-AKA khác

Trường phản hồi ECS

• TOKEN.token: Chứa mã thông báo uỷ quyền
• TOKEN.validity: Số giây mà phản hồi có hiệu lực, sau khi thiết bị nhận được phản hồi
  • Google sẽ xác thực rằng mã thông báo uỷ quyền đáp ứng Yêu cầu kỹ thuật

AcquireTemporary Token

AcquireTempToken – Yêu cầu GET đến ECS

Bằng cách sử dụng mã thông báo uỷ quyền nhận được từ EAP-AKA, ứng dụng Android sẽ tìm nạp mã thông báo tạm thời bằng cách gọi điểm cuối AcquireTemporaryToken của nhà mạng. Yêu cầu

• Ví dụ: TS.43 v12.0 – Phần 6.4.6 – "Ví dụ về yêu cầu AcquireTemporaryToken"
• AcquireTempToken có các tham số tương tự như EAP-AKA #1, ngoại trừ:
  • AcquireTempToken cũng chỉ định IMSI, operation và operation_targets
  • AcquireTempToken không chỉ định EAP_ID

Tiêu đề yêu cầu của Android

• Accept: Android sẽ đặt text/vnd.wap.connectivity-xml

Các trường yêu cầu của Android

• terminal_vendor/model/sw_version: Android không đảm bảo rằng các trường này chứa thông tin thực tế của thiết bị
• operation_targets
  • FPNV: Mục tiêu của thao tác là GetPhoneNumber

AcquireTempToken – Phản hồi từ ECS

Ví dụ: TS.43 phiên bản 12.0 – Mục 6.6.6 – "Ví dụ về phản hồi AcquireTemporaryToken"

Tiêu đề phản hồi ECS

• Content-Type: Android dự kiến rằng loại phản hồi sẽ khớp với tiêu đề Chấp nhận của yêu cầu
  • tức là text/vnd.wap.connectivity-xml

Trường phản hồi ECS

• APPLICATION.TemporaryToken: TemporaryToken mà sau đó máy chủ FPNV có thể trao đổi để lấy số điện thoại
• APPLICATION.TemporaryTokenExpiry: Thời gian hết hạn theo định dạng YYYY-MM-DDThh:mm:ssTZD
  • Google sẽ xác thực rằng thời gian hết hạn của TempToken đáp ứng Yêu cầu kỹ thuật
• APPLICATION.OperationResult: Xem TS.43 phiên bản 12.0 – Phần 6.5.1
  • Cụ thể, nếu các thao tác là SUCCESS, thì trả về 1

Bước 2 – Trao đổi TempToken để lấy số điện thoại

Cách 1 – Vanilla TS.43

Điểm cuối: Các điểm cuối OAuth và GetPhoneNumber có thể là các máy chủ/điểm cuối khác nhau. Các điểm cuối này cũng có thể khác với điểm cuối EAP-AKA/AcquireTempToken.

OAuth

Hãng vận chuyển phải làm theo hướng dẫn về OAuth này và cung cấp cho Google thông tin cần thiết về OAuth (Mã ứng dụng; Khoá bí mật của ứng dụng; URL máy chủ OAuth)

OAuth – Yêu cầu POST đến máy chủ xác thực của nhà mạng

Tiêu đề yêu cầu FPNV

• Authorization: FPNV sẽ đặt Basic $BASE64_ENCODED_CREDENTIALS
  • Thông tin đăng nhập được mã hoá base64 là thông tin mã hoá base64 của OAuth $CLIENT_ID:$CLIENT_SECRET
• Content-Type: FPNV sẽ đặt application/x-www-form-urlencoded
• Accept: FPNV sẽ đặt application/json

Các trường yêu cầu 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 – Phản hồi từ Máy chủ xác thực của hãng vận chuyển

Tiêu đề phản hồi của hãng vận chuyển

• Content-Type: FPNV dự kiến rằng loại phản hồi sẽ khớp với tiêu đề Chấp nhận của yêu cầu
  • tức là application/json

Các trường phản hồi của hãng vận chuyển

• access_token: Mã truy cập OAuth
• token_type: bearer
• expires_in: Thời hạn của mã truy cập OAuth tính bằng giây
  • Google sẽ xác thực rằng thời gian hết hạn của mã thông báo OAuth đáp ứng Yêu cầu kỹ thuật

200 OK
Content-Type: application/json

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

GetPhoneNumber

GetPhoneNumber – Yêu cầu POST đến ECS

Máy chủ xác minh của Google tìm nạp số điện thoại bằng Thao tác GetPhoneNumber.

• Ví dụ: TS.43 v12.0 – Phần 6.4.7 – "Ví dụ về yêu cầu GetPhoneNumber"

Tiêu đề yêu cầu của FPNV

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

Các trường yêu cầu của FPNV

• requestor_id: Xác định dịch vụ gọi hoạt động GetPhoneNumber TS.43
  • UUID xác minh số điện thoại của Firebase: 191fd7cc-f7cd-4bb4-a5d2-455ae1fb9a19
• temporary_token: TemporaryToken từ AcquireTempToken
• access_token: Mã thông báo OAuth để Google xác thực với hãng vận chuyển
• terminal_vendor/model/sw_version: FPNV sẽ điền các trường này bằng các giá trị tuỳ ý
• entitlement_version: Google sẽ định cấu hình phiên bản quyền được gửi đến hãng vận chuyển dựa trên yêu cầu của hãng vận chuyển
  • Thông thường, entitlement_version là 10.0 hoặc 12.0
• app: FPNV sẽ đặt ap2014
• app_name: FPNV sẽ đặt firebase cho tất cả các yêu cầu FPNV
  • Lưu ý: AcquireTempToken sẽ có một app_name là Google-OGI, bất kể bạn dùng trình tổng hợp nào
• operation: FPNV sẽ đặt GetPhoneNumber

GetPhoneNumber – Phản hồi từ ECS

Ví dụ: TS.43 phiên bản 12.0 – Mục 6.6.7 – "Ví dụ về phản hồi GetPhoneNumber"

Tiêu đề phản hồi của hãng vận chuyển

• Content-Type: FPNV dự kiến rằng loại phản hồi sẽ khớp với tiêu đề Chấp nhận của yêu cầu
  • tức là application/json

Các trường phản hồi của hãng vận chuyển

• ap2014.MSISDN: FPNV yêu cầu số điện thoại được trả về ở định dạng E164
  • JSON có phân biệt chữ hoa chữ thường, vì vậy bạn phải viết hoa MSISDN

Mã lỗi TemporaryToken

Tham chiếu từ TS.43 phiên bản 12.0, phần 2.8.6.

Bảng sau đây trình bày chi tiết các phản hồi thất bại mà ECS dự kiến sẽ trả về cho Máy chủ xác minh của Google đối với các yêu cầu GetPhoneNumber:

Lựa chọn 2 – CAMARA

Điểm cuối: Việc truy xuất mã thông báo truy cập CAMARA và truy xuất số điện thoại có thể là các máy chủ/điểm cuối khác nhau. Các điểm cuối này cũng có thể khác với điểm cuối EAP-AKA / AcquireTempToken.

OAuth – Truy xuất mã truy cập CAMARA

Google sẽ chỉ hỗ trợ quy trình truyền tải JWT của CAMARA chứ không hỗ trợ quy trình CIBA.

Mã truy cập CAMARA – Yêu cầu POST đến nhà mạng

Google sẽ tạo một JWT có các trường sau.

• iss: Tổ chức phát hành JWT (còn gọi là Mã nhận dạng khách hàng)
  • tức là firebase (tích hợp FPNV thực tế) hoặc fpnv-carrier-tester-app (ứng dụng kiểm thử của nhà mạng)
• sub: Chủ đề của JWT
  • tức là operatortoken:$TEMP_TOKEN
• aud: Đối tượng; người nhận mà JWT nhắm đến
  • URL điểm cuối của mã thông báo (tức là URL của máy chủ uỷ quyền)
• exp: Thời gian hết hạn tính bằng giây
  • Google sẽ gửi thời hạn hết hạn phù hợp với thời gian mã thông báo truy cập CAMARA có hiệu lực (xem phần Yêu cầu kỹ thuật)
• iat: Được phát hành tại thời điểm tính bằng giây
• jti: Giá trị nhận dạng duy nhất để tránh các cuộc tấn công phát lại
  • ví dụ: UUID được tạo ngẫu nhiên
• scope: Mục đích của yêu cầu
  • tức là 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 sẽ ký JWT bằng khoá riêng tư của chính mình và hãng vận chuyển có thể xác thực JWT bằng khoá công khai tương ứng. FPNV sẽ cung cấp khoá công khai bằng cách sử dụng một điểm cuối JWKS. Các hãng vận chuyển nên thường xuyên thăm dò điểm cuối JWKS này để lấy khoá công khai (ví dụ: Mỗi ngày một lần), vì FPNV sẽ xoay vòng các khoá công khai theo tần suất thường xuyên (ví dụ: Mỗi 30 ngày một lần).

Tiêu đề yêu cầu của FPNV

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

Các trường yêu cầu của FPNV

• grant_type: urn:ietf:params:oauth:grant-type:jwt-bearer
• assertion: JWT được tạo ở trên và được ký bằng khoá riêng tư của FPNV
  • Đáng chú ý là JWT này chứa 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

Mã truy cập CAMARA – Phản hồi từ nhà mạng

Tiêu đề phản hồi của hãng vận chuyển

• Content-Type: FPNV dự kiến rằng loại phản hồi sẽ khớp với tiêu đề Chấp nhận của yêu cầu
  • tức là application/json

Các trường phản hồi của hãng vận chuyển

• access_token: Mã thông báo truy cập CAMARA, sau này có thể được trao đổi để lấy số điện thoại
• token_type: bearer
• expires_in: Thời hạn của mã truy cập OAuth tính bằng giây
  • Google sẽ xác thực rằng thời gian hết hạn của mã thông báo OAuth đáp ứng Yêu cầu kỹ thuật
• scope: Mục đích của yêu cầu
  • tức là 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 phiên bản 2

Sau đó, Google sẽ trao đổi mã truy cập CAMARA đó bằng cách gửi một yêu cầu GET đến điểm cuối /device-phone-number của nhà mạng.

CAMARA NumberVerification – Yêu cầu GET đến nhà mạng

Tiêu đề yêu cầu của 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 – Phản hồi từ nhà mạng

Tiêu đề phản hồi của hãng vận chuyển

• Content-Type: FPNV dự kiến rằng loại phản hồi sẽ khớp với tiêu đề Chấp nhận của yêu cầu
  • tức là application/json

Các trường phản hồi của hãng vận chuyển

• devicePhoneNumber: Trả về số điện thoại ở định dạng E164

200 OK
Content-Type: application/json

{
 "devicePhoneNumber": $PHONE_NUMBER
}