This is an authentication flow, which logs in the user with only the phone number provided (Whatsapp style). The Steps are:
User enters phone number and sent to server.
Server generated 4 digit random key, and save the pair (phone,key) in DB.
Server asks 3rd party SMS service to send key to phone.
SMS service sends message.
User enters the key from sms, and together with phone, sent to server.
Server checks the pair against the DB.
If pair exists, server sends back a token for further calls.
What I am trying to understand is where services like Twilio and Nexmo fit in (or replace parts of the flow).
From what I understand, looking at Nexmo for example,
I can replace steps 2 and 3 with an API call to:
https://api.nexmo.com/verify/
and save the request_id from the response in the DB as pair (phone,request_id).
And now, when the user enters a 4 digit code and sends it back,
I need to call:
https://api.nexmo.com/verify/check/json
providing it with request_id and code.
But where do I get the request_id?
Do the server needs to send it back to the client, the moment it gets it from Nexmo?
I can't see the benefits of using Nexmo here, what will it save me?
Answer to your first question: the request_id is part of the response to the first verify API call. See: https://docs.nexmo.com/index.php/verify/verify
As to what are the benefits of Nexmo here, I believe you have two options:
Generate your own code, use Nexmo to text it to your user, have the user submit the code back to your application, verify code against your own database.
Use Nexmo verify service to generate and send the code to the user, store the returned request_id in your db, have user submit code to your application, call Nexmo verify API to validate code.
In some ways the first option is easier as it is less API calls. However the benefit of the second option, using Nexmo Verify, is that they provide a whole lot more capabilities into the service to fall back to a voice call if SMS isn't working, filter out virtual phone numbers to prevent spam, you don't have to pay for failed SMS attempts, reporting/analytics, etc. etc.
Hopefully that helps a little.
Related
I am using an Identity and Access Management(IAM) vendor who provide a Multi-Factor Authentication (MFA) Service (using SMS and other channels). They use Twilio as their SMS service provider and what I see currently is a behaviour (described in the scenario below) from my IAM provider which is strange and wondering what the underlying Twilio API's behavior is.
I am unable to see this info from the Twilio API docs hence seeking assistance.
Scenario:
Customer uses IAM to login and my IAM provider using Twilio sends a OTP
The OTP comes through but in my test case, I trigger the resend OTP process
In both the steps, I get the right message (the template and senderID that we have configured in the IAM tool)
If I now trigger the OTP resend process a second time (3rd OTP in total for the same number), we receive a message which has AUTHMSG as the senderid and uses a default template message (which is different from what we have configured).
I am working with my IAM vendor to understand what is happening here and I am trying to see if Twilio is playing a part in this (trying to do some smarts as they think that there is some SMS delivery issue - which is the message I am in a way communicating by hitting the resend OTP multiple times)
Is AUTHMSG a senderID that is owned by Twilio? I don't believe so but I am trying to better understand this space.
SenderID is a construct that varies from country to country. Some Contries mandate that users register it with the local regulators while in other countries there is no explicit registration process.
I am worried that if my customers receive this message, they are going to be confused and suspect a Spam/Phishing kind of an activity.
I attempted a similar exercise with PayPal and they were consistent in their SMS OTP Resend. The message was always the same. Unlike my IAM provider, PayPal sends OTP from multiple mobile numbers. In my tests I observed them sending OTPs from two distinct mobile numbers.
Would be glad if someone could assist and provide info in this space.
I will continue to work with my IAM provider and their support channel to see what is happening here.
When using Twilio Verify in a country that supports alphanumeric sender IDs, Twilio uses the AUTHMSG sender ID and registers it with countries around the world that require this, to ensure the best deliverability of OTP messages.
I think you will need to work with your IAM provider, and work out how they have implemented sending OTP messages to see what is going on here. If it is unclear, then you or the IAM provider may also have to contact Twilio support.
So I am testing out Dialogflow and one of the first questions I have is: how does my bot know who it is talking to? I need to identify a user and keep that information for as long as I can. The basic scenario being:
User starts his/her first conversation.
Chatbot send a fulfillment request to the server trying to match a user within its own database.
The user is found, the information (as a JWT or some other token) is sent back to Dialogflow and stored there for further communication. In reality, this part would involve asking for user email, sending a verification code to that email and then verifying the user with the code.
User then starts chatting with a bot and all fulfillment requests get the unique token stored for this very user, so that my REST API knows which user is being served with the response.
Couldn't find anything about it in the docs (maybe I am looking in the wrong places).
There will be several integrations, like Messenger, Viber, Telegram. I dunno, maybe those APIs add some unique information on the user?...
Thanks for the help!
Sorry, I know it's been a while, but maybe this will help someone else.
The right solution here is a user id, not a session id. A user id is provided by the chat platform (Facebook, Slack etc) and is consistent across sessions for the same user.
To get the user id, go to the Fulfillment tab, enable the editor and use a function like so:
let r = request.body.originalDetectIntentRequest
//this makes sure that you're on an integration
if (r["source"]){
return r.payload.data.sender.id;
}
To tie together ids from different platforms, you probably have to have some kind of log-in process every time you encounter a new id on a platform.
Pop,
Sessions are built in already into DialogFlow requests to your fulfilment service, if you check the payload you will find a sessionId, it remains the same for the same client until it expires.
However if you want to identify the user from any of the clients that you can connect to DialogFlow like Messenger then from the same request payload to you you will notice that there is an object named originalRequest that is only available when requests are coming from those clients.
You can personalize those users response eg using their FB firstname in a message to them.
Tried searching for this in Amazon's docs but couldn't come up with anything.
Assuming that both email and phone number are checked in the verification section of the user pool. If the client app wants to allow the user to choose how they receive the code (assuming they've forgotten their password) - how do we get Cognito to handle that? Is there a way of getting the forgotPassword method to select a route (email or SMS)?
From some early testing, it seems like it always goes one route if both are available. I do see that Amazon themselves have made this available on their site though, so hoping that it should be possible?
For this example, we can assume that we've got a verified email address and phone number for that user.
I am on the Cognito team. Currently the behavior is that if both phone number and email are verified, the code goes to the phone, hence phone number is given preference and there is no way to select where the code actually goes. However, we have heard this request in the past and I will add a +1 to the feature request on your behalf.
I'm not sure where to begin, but got a case I need help from others where and if possible to solve.
Thing is, got a new alarm system at home, this system uses sms function so I can send a short code to my alarm asking for status if it`s ON or OFF, or i can turn it on/off from an sms.
Since both the sms number and code is strictly personal, I would not like to tell my carpenter the codes, but in the mean while he is working at my home, I can give him a login to my site, where he can see if the alarm is turned on or even turn it on/off by him self.
I would like to build me a website, that does the same.
Got a login to my site, when logged in, i would like the website to send an sms automatically, then retrieve the answer and display it on the website.
Is this even possible ? If so, anyone can past me in the right direction here ?
Thanks in advance =)
You can send an SMS from a website. Most mobile operators will gladly offer you an apropriate API.
For instance Deutsche Telekom has an API called "Developer Garden" that allows you to send SMS via a WebService and much more.
see here for an example: www.developergarden.com
Other providers may also offer such services.
you need an sms gateway ( we use these guys : http://inteltech.com.au/, but nearly any will do )
Your easiest option is to find one where you can insert SMS'es for sending via a URL, eg in our case the URL looks like this:
http://inteltech.com.au/secure-api/send.single.php?username=[user]&key=[longcode]&method=http&senderid=[id]&sms=[phonenumber]&message=[here's the message]
it's extremely simple to use. If your site handles the login otherwise, then you can use this for the rest.
Now, how to receive SMS'es is a bit tricker :)
But this provider, for example, offers you options to;
Send the reply as an email to a nominated email address.
Send the reply as an email to the original user who sent the message.
Send the reply as an SMS to a nominated mobile number.
POST the reply to your website or application . e.g. We can call a http/https request to your script
as you can see, both the email and the POST options are providing great ways to integrate.
I'd say if you don't handle incoming email already, then stick to the POST method.
voila :)
I'd like to develop a tracking system using an API of course (like the famous Orange API).
the idea is simple:
I send a SMS (from my Web interface) to the person i want to track
The person's mobile terminal (GPS like this) send me back automatically
the coordinates by SMS.
The sent information are displayed on the user's web interface.
The questions are simple:
How the terminal can send automatically the response?
How to indicate in the message that the information is for "user4655"?
How to make connection between the information and the database?
Thanks,
Regards.
* How the terminal can send automatically the response?
Ans: You set the gateway and the time intervals you want the device to send the sms to on the device itself.
* How to indicate in the message that the information is for "user4655"?
Ans: The gateway you use will have the API to determine that the number it is sent from. The device will use a registered phone number from either a sim or enabled by one of those cell providers.
* How to make connection between the information and the database?
Ans: I dont understand this. But I'm guessing you will have a database to keep track of the user data. You'll just probably need another table that is a child of the user, which has a list of the data and the time they came in.