We currently have a solution where we implement 2FA ourselves over Twilio Programmable SMS.
We're also using Twilio Verify for Payment PSD2 authorization.
We're now looking to migrate everything to Authy to make use of the Authy app and I have the following questions that I'm hoping you can help me with.
User Migration. I understand in authy, users need to be registered to our application. How can I register all our current users? Is there any way to bulk upload them, or do I have to write a script that calls the API to register them one by one?
User Number phone update. Sometimes our users will update their phone or email in our system. If that happens, how do I update that info in Authy? I couldn't find anything in the docs about that. Do I need to call the api to remove the user and readd with the new info?
Migrating from Verify PSD2 to Authy PSD2. Is the implementation very different? Is there any sample I can look through, as the documentation seems to mainly be talking about QR codes, while what we want to do, is to send it over SMS or Authy depending on the user's choice.
Thanks for your help
Sam
Twilio developer evangelist here.
You will need to write a script to register your users. When you have registered a user, you will receive an authy_id for the user, which you will need to store with your user record.
If a user updates their phone number then you should update the Authy user. To do so, you will want to delete the old user and re-register with the new phone number. You will then receive a new authy_id and you should re-confirm the user can authenticate by challenging them for a new code before you complete the update. If the user updates their email then you can do the same process of deleting and creating a new user though you should receive the same authy_id back if the phone number hasn't changed (though this will add the email address to Authy's representation of the user).
Check the documentation on PSD2 compliant authentication with Authy here. If you are sending SMS messages, then you should set the action and action_message parameters, which tie the message to the authentication. For the app based authentications you can do it via Push Notifications (in which you can include transaction details in the push). If you don't want to implement push, then you do need to get your user to scan a QR code in order to tie the transaction to the authentication (the regular code generated by the app is not connected to a transaction, so is ineligible for PSD2 authentication).
Let me know if this helps at all.
Related
Looking for the best course of action that would have the least impact on users to be able proactively message users with teams app (bot) installed but where they have not messaged the bot and the conversation reference was not captured at time of install.
The scenario is that have an enterprise bot that has been operational for over 3 years servicing 10s of thousands of employees. The bot is auto installed for all users in the tenant, but conversation references were only being stored in the last 2/3's of the applications life, and the install event was not being captured until recently. This was not an issue in past as all proactive functionality was predicated on some interaction with the bot.
I now have a need to be able proactively messages all users within tenant regardless of if they have messaged the bot or not, or if they last messaged the bot before conversation references were being stored. There are only a small subset of users the fall into this category.
Hoping some way to generate a conversation update, be it through graph or other means. The installationUpdate event through app update seemed promising as can update the application but seems only triggered if bot is added or removed
Review the information provided here: https://learn.microsoft.com/en-us/microsoftteams/platform/graph-api/proactive-bots-and-messages/graph-proactive-bots-and-messages?tabs=dotnet
Here is what we do
If we have the conversation ID in our cache/persistent store, we use
it to send the message
If we dont have, we use GET
https://graph.microsoft.com/v1.0/users/{user-id}/teamwork/installedApps/{teamsAppInstallationId}/chat
to get the chatid (the app id here is not the bot application ID, but the ID generated when the app is installed in the org app store and is available from the Teams Admin interface)
If the user does not have our app installed, we
install the app using the teamsAppInstallationId ID. This automatically generates a event without user intervention that
is sent to the bot which you can then use to capture the conversation ID.
POST /users/{user-id | user-principal-name}/teamwork/installedApps
This approach does require an Application Permission: TeamsAppInstallation.ReadWriteSelfForUser.All
You might look into using the List Teams functionality in the Graph API. You can use Graph to get teams and list their members, assuming you can grant your bot the necessary permissions. There are many features in the Graph API which might help you accomplish this.
To send a proactive message to user the bot requires the conversation reference. The conversation can be only retrieved when bot installed.
Without conversation reference you cannot send a proactive message using bot.
You can use Send message in a chat API to send message to chat with delegated permissions.
Could you please raise a uservoice for your case
I am using Twilio's verify API for TOTP services (Authy, Google Authenticator, etc).
I am trying to figure out how to handle the case where a user has lost access to their phone and cannot get past the TOTP 2FA challenge. Can I create a new Factor for that user and somehow "invalidate" the previous one?
Anyone know how to do this?
You can delete a factor, which would remove it from the entity. You can then create a new factor.
How to handle how you re-enable access to the user's account in your system is up to you though. Presumably after the user has convinced your support team that they are the rightful owner of the account, you could turn off 2FA verification for their account, allowing them to log in, and then have them go through 2FA set up again themselves. You might also want to consider generating back up codes which they can use in the case that they lose their device again.
I have a Slack App (source code) where I want to send reminders to channels where a certain piece of text has been mentioned the most on a schedule. It works, but there's a limitation:
The search.messsages API method only supports user tokens. I want this to run in the background, without interaction. Approaches that have come to mind:
Store my personal user token
Con: Would allow others with access to the token to be able to see my private messages
Create a fake user whose only purpose is that user token
Con: Have to pay for that fake user indefinitely, manage shared credentials, etc.
Any other ideas?
Here is what you can do:
Switch on distribution of the Slack app.
Have the admin, or an existing user on the Slack channel install the app. During the time of installation, you can ask for permissions with user token and search:read scope.
Now you can make all the searches using this user's token. You'll need to plan for the scenario where this user is deleted from the Slack workspace, your user token will stop working.
I don't think there is a way to control it from searching for your personal messages. Search functionality is dependent on the user token.
I'd like to integrate the new login framework from Facebook, Account Kit (which among others provides phone login), to my iOS app, which uses Parse.
I was able to integrate the framework successfully; i.e., I was able to complete the flow: user inputs his phone number -> gets an SMS with a code -> enter it and successfully get a token.
What I’m not sure is what do to next — how to follow up with the integration to Parse?
Other related questions which came to my mind are:
1. Do I need also some Cloud code to deal with it?
2. How do I check if the current user is a new or existing user?
I’d love for any help...
Not only Cloud Code, I guess. You need to integrate this in your Parse Server.
Another way
If you can't do server stuffs, there is lazy, crappy and bad way to implement the integration. But this solves the problem.
The method is
Get the user's phone number after user has logged-in with phone number.
Develop an Algorithm that will generate password from the given phone number.
NSString generatePassword(NSString phone)
After the user has logged-in with accountkit, check if his phone number is already at Parse
If the user's phone number is not at Parse, signUpInBackground(phonenumber, generatePassword(phonenumber), callback)
Unless, logInInBackgroud(phonenumber, generatePassword(phonenumber), callback)
Hope this would help :)
I am building a mobile-focused web application, to later convert to hybrid, and I would prefer new user registrations confirm the user's phone number versus their email address.
I would like to send a new user an SMS with a unique code. When they first log in, they must enter that code to activate their account.
I have a custom SMS service that is sending SMS fine, and would like to know how to integrate this into the Identity registration process.
Please note that I do not wish to use SMS for routine two-factor authentication.
You can use create additional actions in your account controller
and use methods from Microsoft.AspNet.Identity.Core
UserManager.GenerateChangePhoneNumberToken
Send sms with token
UserManager.VerifyChangePhoneNumberToken
Add custom logic to authorization
There are several ways to accomplish this.
Cheap but not reliable or enterprise ready is to build an app on a device you own and have those other devices send an SMS to it. You can process the SMS and reply however you like. With unlimited texting plans, it would be fine. It's just not redundant or reliable (the phone battery could die, you may need to do updates that could interrupt service, etc.)
Work with a company like Twilio (https://www.twilio.com/) and use their SMS gateway, API and services to build, quickly and cheaply (for the most part) the type of service you are looking to provide. There are competitors to Twilio and I'm not endorsing them, just providing them as an example.
Obtain your own SMS gateway (https://en.wikipedia.org/wiki/SMS_gateway) and then do heavily integrated and customized services.
If this is just a proof of concept at the enterprise level or you don't know what your user adoption rate will be, then #1 is probably fine until you need #2. #3 is rarely the best option.