0

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:

  1. 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.
  2. 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?

Sahil Sharma
  • 3,847
  • 6
  • 48
  • 98
  • Seems like option 2 would make most sense, the API behaviour would change based on the presence of the cookie. – James May 21 '18 at 10:33
  • But I need the same API to achieve both based on client's requirement i.e. do device specific verification OR do only number based verification. Should I pass query string to modify this behavior on server side? – Sahil Sharma May 21 '18 at 11:03
  • wouldn't the presence of the cookie be enough to determine that the user should do device verification? If not, and it's an optional parameter, then you could have explicit URLs but still use the same API e.g. `/api/users/verification/start/:mode` so `.../start/mobile` and `.../start/device` (if that makes sense). The API can extract the mode from the URL and decide how to process the verification. – James May 21 '18 at 11:29

3 Answers3

0

I would modify the existing API to fit the new requirement and here is the important thing I would do while modifying.

  1. 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.

  2. 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.

halfer
  • 19,824
  • 17
  • 99
  • 186
Harshal Bulsara
  • 7,898
  • 4
  • 43
  • 61
0

Hope this would help you, you can modify code and follow some client and server steps.

CLIENT SIDE

Step 1.

SERVER SIDE

Step 2.

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.
Mithilesh Kumar
  • 92
  • 1
  • 2
  • 13
0

There are different options.

  1. 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.

  2. 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.

  3. 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.

mentallurg
  • 4,967
  • 5
  • 28
  • 36