RESTful Device specific Authentication of Phone Number - rest

Question

We have an API that sends a verification code to user's mobile number. The API is:
POST /api/users/verification/start/
{
"mobile": "9849735434"
}
The above API returns following response:
{
"isVerified": false
}
If the response is "isVerified": true, we don't send a verification code to user's mobile. If it is false, we send a code.
Currently, all this works on the just mobile number. We want to make it based on (mobile + device) to make it more secure.
To achieve this, we store a user-identification cookie on the client machine and we are planning to identify the device on basis of that. How should API be modified for this new requirement? Few approaches:
Create different API that works on basis of (mobile + cookie) and sends isVerified: true only if both matches with the value stored in our database.
Modify existing API to achieve this - Since this support for device-specific OTP is not required always, we will have to pass some flag to make it only mobile-based OR (mobile and cookie).
How should we design such API to verify users based on mobile and device?

Answer 1

Hope this would help you, you can modify code and follow some client and server steps.
CLIENT SIDE
Step 1.
Get mobile no and country from user
GET UUID from user device. ( UUID :Is Secure.ANDROID_ID unique for each device?)
Hit Own Api with this params.
SERVER SIDE
Step 2.
Get Validate it, is this mobile no is Valid https://github.com/googlei18n/libphonenumber (we can do it from Client side too)
Step 3.
Generate OTP between 0001 - 9999 or more
Send OTP api call to send on Mobile no as per OTP service provider’s API.
Save OTP no into database along with Mobile no And UUID.
CLIENT SIDE
Step 4.
get mobile no and OTP and hit api
check OTP from DB same OTP then response success else Wrong OTP message you can send.

Answer 2

There are different options.
When you want to use cookies, why do you need a separate API at all? If the client has a cookie, let the client send this cookie as a cookie. Your service can analyze the cookie when needed and decide about further steps.
If you cannot send cookies and the 1st approach is not an option to you:
Device should not know, what type is it from the point of view of your service. That is why I'd suggest to use two services - one without cookies and one with cookies.
You say "RESTful". In the current form your service is not RESTful.
A) Using verbs makes the service NOT RESTful. Rename it for instance to
"POST /api/users/verification/"
B) Two operations are mixed within a single one: Check if client is authenticated and starting authentication process. Split it into two:
To check if the client is authenticated:
"GET /api/users/verification/mobile/9849735434"
To start authentication:
"POST /api/users/verification/mobile/9849735434"
For the POST you don't need a body in this case.

Answer 3

I would modify the existing API to fit the new requirement and here is the important thing I would do while modifying.
Whenever you create any API always have a "version" passed from the client this way you would know which section of the code to execute.
e.g Assume your mobile users have 2 different version of the app, once before this release another after. To have both the user running versioning is helpful.
Pass "Device Type" from client to check whether the client is mobile/tab or other, this will have multiple advantages firstly you will know how much user base is in phone/web, another advantage is you can customize the output size accordingly as web will have more information compared to the mobile app.
Now that you have device and version information you just have to write condition in your existing API. Once you feel there is no old version usage we can retire that portion of API.