In order to avoid users from using VOIP numbers as Phone MFA. I need Azure AD B2C PhoneFactor-InputOrVerify to verify Phone only. We have a check while registering the user to not allow VOIP.But when user is prompted for MFA, AD B2C allow to use the VOIP numbers. Any suggestions
https://github.com/azure-ad-b2c/samples/tree/master/policies/mfa-email-or-phone allows to both input and verify. I want to restrict user from entering the Phone number.
The PhoneFactorProtocolProvider technical profile protocol definition (used by the starterpack that the mfa-email-or-phone example builds off of for phone MFA) allows for a metadata field to determine whether the user is allowed to enter a new phone number on the MFA UI or not. You can see this if you look at the starterpack's base policy file for the version including MFA logins: check the technical profile PhoneFactor-InputOrVerify and you will see a metadata item:
<Item Key="ManualPhoneNumberEntryAllowed">true</Item>
If your phone number input technical profile has this key set to false instead of true as in the example, the MFA UI will display the phone number provided as an input claim as static text instead of creating an entry form, and the user will not be allowed to edit it. This does mean that if the claim provided for the phone number is empty at runtime, you will get an exception.
With this metadata value set to false, you can provide the user's registered, verified-to-not-be-VOIP phone number to the technical profile as an input and they will not be allowed to enter a different number.
You can also see the documentation for PhoneFactor technical profiles to see more information about the available metadata fields.
Related
I am making an app with firebase that should allow a user to authenticate their identity when they get to a certain physical place in order to be let into the place. I want staff at the place to be able to use their own phones to securely verify the user's identity and let them in.
My first idea was to make the user's phone present a QR code with the uid of the user for the designated staff members to scan. The problem with that is that the uid is not a valid means of authorization in firebase because it is not a secret, which makes me worry that this approach may not be secure.
Is there any secure way for one phone to authenticate the identity of a user who is logged in on another phone?
EDIT: My question has nothing to do with logging in to the same user account using multiple authentication methods, it is about using a physical device connected to one user account to authenticate that a different physical device is connected to a different user account.
We have an application utilizing Alexa skill with account linking for user details.
According to Alexa's account linking documentation:
Our skill is set up for Account Linking which in turn refers to a 3rd party (or it could be internal) Identity Management System (IMS) for user authentication. Our application (as well as our organization) does NOT internally maintain the app's user identities.
Let's say the user enabled our skill on her device, at which point (according to the above docs) she was issued an Alexa generated userId, something like:
"userId": "amzn1.ask.account.AFMWOL5WIGQZLYYEMM2IJL2BJ26ICPQHBPR2DSLRX46CHW36R6CPVH7RZTUZMBCHHJLQQNU3YO2BWZWNIRTM3PCAGTNZKILK33PM2XVI36H4RSINFH2A26OLURAIB2RVPV6GMK56BR5BLBIFNJKT64EANASM7IDTQJBQLGDIEUZHUIM6VSHTTOUPVPITIPOIOPESUK53TSALU5I"
Consequently, upon further interaction with the skill, she wanted to access some more personalized information which triggered account linking so her identity was confirmed and re-established via provided account linking details (OAuth 2 Authorization Code Profile), which, while doing so, as mentioned before contacted the 3rd party Identity Management System (not LWA) to verify the user identity:
the user is presented with a login screen,
she enters her credentials, say: "alice"/"password123"
she answers the relevant questions to permit certain actions that our app can do on her behalf and
is allowed to further interact with the system on a more personalized basis
Let's say that inside our app, we want to be able to identify the user by her real userId: alice and NOT the one auto-assigned by Amazon, as described above.
Does Alexa allow for this?
Upon successful account linking, does Alexa overwrite in its JSON request (or can it somehow pass it through, along with now embedded accessToken field) the userId it receives from the 3rd party Identity Provider) so that that "real" userId (is it called subjectId in OAuth parlance?)can then be used to identify the user actions during her further interactions with the app?
If yes, how can we obtain the user details from JSON via Alexa Java API?
If no, what would be possible ways to facilitate such ability?
Can the real userId be obtained from the accessToken that Alexa puts in its request after authenticating a user? If so, how?
I'm not sure if it's related to this, seems to be a similar request, has it been put on Alexa's roadmap or became a feature already?
This seems to be a detailed version of How to obtain userId specified by Alexa user during account linking
Generally speaking, after the user complete the OAuth authentication, the application (i.e. Alexa in this case) would receive a access_token and refresh_token. If you want any additional data, e.g. username alice, email, phone, address...etc., you would need to check with your OAuth provider and see if they have an API to retrieve those based on the access_token with the appropriate scope.
I try to implement sign up AWS Mobile Hub process in an iOS app. I chose "How are your users going to login?" only email option. But the test app (downloaded from 'Integration Steps' page after User pool creation) have required Username field on a sign-up and log-in screens.
Can I implement this flow with user email and password fields only?
It should be possible, though you might have to autogenerate a fake username on the first sign up. You should make sure email is then passed in as an attribute and is set as an alias for the pool.
One possible sticking point: if email and phone are both given to be confirmed, phone overrides email. In that case, you'd have to ensure manually that emails are confirmed.
Using Parse.com, I want my users to login only with their phone number, just like WhatsApp.
Enter your phone number, get a verification code by SMS, enter the code - you are logged in and stay logged-in!
I can see how I can use Twilio to send a verification code.
My problem is how to tie it in with the Parse authentication framework.
When to use signUp vs login?
What is the password?
What to do the second time the app is launched?
What to do when the application is re-installed?
I don't think you should use the predefined Signup and login classes provided by parse as they do not allow you to create a user without a password,
Nor should you use the Anonymous Users as the data will be lost once the user sign out/uninstall.
For Signup, Use another object to store the numbers , Implement a onSave hook in cloud code to ensure that all the username"phone nos" are unique during Signing in.
For each device, perform an OPT(one time password) to the phone of the user by using the installation class's id
Perform a query and load the data connected to the number during Login
To keep the user logged in , use the local data store , pin a Boolean variable that indicates the status of a user, either logged in or out.
In the parse DB , You can use the phone num as the link to the other data of the user.
In this way, no password , only OTP
You will need to store something on the user settings/profile to pin that user, I do not recommend using a boolean but rather something that ties that device with the user so that if someone decides to copy that file and paste it into a rooted phone you will be able to determine if the app install corresponds to that user.
I would recommend using the a unique token to create a password for a user in Parse.com - you can use the token that RingCaptcha generates for this, ensuring it will never collide with other users and that every phone number will only be able to verify one time for each device. RC is a new service that helps you onboard verified users into your apps in seconds via SMS. Integration is a breeze with all the available plugins for web, APIs, and SDKs of all flavours.
[Disclaimer: I'm part of the team behind RingCaptcha]
In an ASP.NET MVC 4 application using the .NET 4.5 framework in conjunction with Azure Access Control Service (ACS), I want to provide the users multiple authentication possibilities (i.e. Google, Facebook, Windows Live, etc.). What is the "best practice" for associating a single user to multiple identity providers?
For example, say the user logs in with Google one day, then goes to another browser the next day and logs in with Facebook. How would I know to associate the Facebook login with the previous Google login to the same user?
Look no further than stackoverflow itself for a good example of this. Click your user profile and then select "my logins".
When a user creates their account, they select which identity provider you want to use to sign in. Under the hood, your application creates a new site-specific unique user ID, and links it with a 3rd party provided unique ID. (You might use email, but most identity providers will also provide a unique user ID claim that doesn't change, even if the user changes their email)
Now, after the user has signed in, they have an account management control panel through which they can establish additional links to other identity providers.
I see two options for achieving this:
Have your MVC application persist account links. When a user signs in, you query your account link store using the 3rd party unique ID claim and resolve your site specific unique user ID.
Use the ACS rules engine. You would create one rule per account link. For example, lets say I can sign in with either gmail or liveid and my unique id is 1234. Two rules look like this:
google + me#gmail.com --> output user ID claim 1234
liveId + me#live.com --> output user ID claim 1234
For the unique ID output claim type, you can pick from the available claim types or designate your own. ACS has an OData based management service which you can use to create these rules programmatically from your MVC application. Here's a code sample.
If you are using ACS, you can translate the information from each IdP (e.g. Gogle, Yahoo!, FB, etc) to a common handle using claims transformation on ACS. A common handle people use is the users e-mail. But if you want to accept many e-mails mapping to the same user, then you'd introduce your own unique id (as a claim) and map IdP supplied claims into it:
myemail#gmail.com (e-mail - Google) -> (UserId - YourApp) user_1234
myotheremail#yahoo.com (email - Yahoo!) -> (UserId - YourApp) user_1234
64746374613847349 (NameIdentifier - LiveId) -> (UserId - YourApp) user_1234
You can automate this through ACS API. You should also probably handle the first time user logs in into your site (e.g. asking user for an e-mail and sending a confirmation message that will trigger the mapping).
Presumably, you are using this information to retrieve data from a local database in your app, otherwise, you could just encode everything in claims and not worry about any equivalences. Claims are often a good place to encode common profile data. (e.g. Roles, etc)