Number Verification APIs (1.0.0)
Service Enabling Network Function API to verify that the provided mobile phone number is the one used in the device. It verifies that the user is using a device with the same mobile phone number as it is declared. It also makes it possible for a Service provider to verify the number itself by returning the phone number associated to the authenticated user's access token.
In this API phone number term refers to the mobile phone number
This enables a Service Provider (SP) to verify the phone number of the mobile device being used to access their service where the mobile device is accessing the service provider over a mobile network (WiFi connections are out of this API scope). This can happen either by getting the comparison result or receiving the phone number of the device that is used, so they can verify it themselves.
This API currently provides two endpoints where both require a 3-legged token and authentication via mobile network (excluding for example by SMS/OTP or user/password as an authentication method):
- The first one checks if the user mobile phone number matches the phone number associated with the mobile device. It can receive either a hashed or a plain text phone number as input and it compares the received input with the authenticated user's phone number associated to the access token in order to respond true/false.
- The next one retrieves the phone number associated to the user's token and returns it so the verification can be made by the service provider.
Number Verification API uses the standard OAuth2 Authorization Code grant. The following diagram will help to clarify the end-to-end process, including previous steps prior to this API call.
Additional details:
(1): Authentication must be automatic without any user interactions. Authentication methods such as SMS OTP or user/password are incompatible, as the goal is to validate the mobile phone number that is accessing the App. So it is required to be authentication via mobile network and without the user being involved. the use of parameter prompt=none, as described in OIDC Connect, ensures no user interaction.
(2): The way in which the phone_number is retrieved depends on the implementation. For example, access token may be a self contained encrypted JWT, so API can decrypt and identify phone_number. Some other implementations might request the phone_number associated to the token from Authserver.
https://developers.opgw.u.com.my/_mock/number-verification/number_verification/
https://silent-auth.u.com.my/
https://api-sandbox.opgw.u.com.my/
Request
The Application Client makes a request to Fronttend Authentication Endpoint to ask for end-user authorization. UM-OPG validates that the MSISDN is a valid MSISDN and checks for consent. If successful, it passes the request for further processing. Once UM-OPG processing is successful, a “code” is provided in the response to the Application Client.An authorization request must include either a signed request parameter or the standard parameters:client_id, redirect_uri, scope, and response_type.
Signed JWT that encapsulates the authorization request parameters. It should contain client_id,response_type,scope,prompt,redirect_uri,iss,aud,iat and exp.
The callback URL where the authorization server redirects the user after authentication. This must be pre-registered with the authorization server to prevent malicious redirections
A random unique value generated by the client and sent to the authorization server. Used to maintain session state and prevent CSRF attacks.
- Mock server
https://developers.opgw.u.com.my/_mock/number-verification/number_verification/ac/auth-service/openIDConnect/deviceinitiated/v1/authorize
- Testbed Authentication
https://silent-auth.u.com.my/ac/auth-service/openIDConnect/deviceinitiated/v1/authorize
- API Sandbox server (uses test data)
https://api-sandbox.opgw.u.com.my/ac/auth-service/openIDConnect/deviceinitiated/v1/authorize
- curl
- JavaScript
- Node.js
- Python
- Java
- C#
- PHP
- Go
- Ruby
- R
- Payload
curl -i -X GET \
'https://developers.opgw.u.com.my/_mock/number-verification/number_verification/ac/auth-service/openIDConnect/deviceinitiated/v1/authorize?client_id=string&code_challenge=string&code_challenge_method=string&login_hint=string&nonce=string&prompt=string&redirect_uri=string&request=string&response_type=string&scope=string&state=string' \
-H 'x-correlator: string'Found Redirect uri of client
in Location Header:
Included in success and error scenarios:
- The “redirect_uri” as provided in the request parameter
- “state”, as a query parameter
In success cases a 302 response would contain a code to be used in the token api request
https://www.example.com/?code=gRIk9pak&state=9c4b31dd-0d79-4489-993a-97e48ec37eaf
In failure cases a 302 response would contain error and error_description fields in query parameter
https://www.example.com/?error=login_required/
No content