I understand how to brand my login form but how to customize the workflow that Azure provides?
Currently the Sign-up form looks like this:
Which is really unlogical. The text boxes under 'Verificatiecode verzenden' (Send verification code) are only useful after the code has received and filled in.
How to customize this part to create a better working workflow:
Add email address -> Send code -> Fill in code and verify --> Fill in additional user details.
Edit:
As recommended by Brad I dived into Identity Experience Framework. An 'intimidating' framework is a big understatement ;(
I watched these videos: https://www.youtube.com/playlist?list=PL4svy-vB4AaxRunWQkxOe8h3zP9jAzS5Z and followed the steps mentioned here:
https://github.com/azure-ad-b2c/azureadb2ccommunity.io/wiki/LocalAndSocialAccount-Sign-In-and-Sign-Up-policy
https://github.com/azure-ad-b2c/samples/tree/master/policies/split-email-verification-and-signup
I'm just at the point that I only want to mimic what I currently have using the 'normal' user flows:
Log-in using Email
Log-in using Facebook
Log-in using Google
The login screen looks the same, I have the email and password buttons and the Facebook and Google buttons, but when I log in with Google I get an error about grant-type not set.
And this is all without trying the split.xml.
I'm so lost in understanding AAD B2C. It should make live easier for developers but I find it very complicated, hard to modify and hard to get the profile data I need and to keep the data in sync.
In order to achieve this with User Flows, you must use the Custom User Interface features, and Javascript to control how and when those fields are displayed.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/javascript-and-page-layout?pivots=b2c-user-flow#enable-javascript
Optionally, you can conduct a similar flow using the Identity Experience Framework (Custom Policies) with either Javascript or where you use two different Self Asserted profiles to move from screen to screen.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-trust-frameworks
Taking the leap from User Flows to the Identity Experience Framework can be intimidating, but would give you the most control in your user experience.
Related
I'm currently working on a project where I need to use a mfa with email on every login. I found signin-email-verification policy example which is perfect except for the fact that I can't seem to find a way to change the email being sent to the user. It currently uses Microsoft's personal domain and says on behalf of "xxx". I alrdy have a send grid template. And I've tried using what Microsoft azure b2c documentation has on custom mails. (their docs focuses on sign up / forgot password) which is very different from the "signin-email-verification" example I'm using.
Just need help where start looking for the right example to follow.
Links**
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-email-sendgrid?pivots=b2c-custom-policy
https://github.com/azure-ad-b2c/samples/tree/master/policies/signin-email-verification
I've followed one of the provided samples to add TOTP multi factor authentication supported by a phone app:
https://github.com/azure-ad-b2c/samples/tree/master/policies/custom-mfa-totp
I'm therefore able to offer users the ability to enter a TOTP code:
One of the things I'm considering is ensuring users still have access to their accounts if something goes wrong during the TOTP MFA process which we're using by default. I'd therefore like to be able to add an extra link to this page to send users through an alternative MFA route without successfully completing this one in case they encounter issues: "send a code via email instead".
As far as I can tell, the B2C screens expect users to only go forward through clicking continue. The best alternative instead of a link I can think of is a checkbox which sets a boolean claim to enable an email MFA OrchestrationStep. I find this a little less user-friendly than a simple link though as it adds an unnecessary extra click.
Ideal user flow:
Login --> Display TOTP MFA screen --> Enter MFA code OR click link to go to email MFA screen
Any help's appreciated!
This sample demonstrates how to use a display control to provide multiple options (Email or MFA) for a user to continue:
https://github.com/azure-ad-b2c/samples/tree/master/policies/pwd-reset-via-email-or-phone
You could use the same idea here, except instead of invoking the MFA technical profiles as part of the samples display control, you can invoke the call to the REST API technical profile to verify the code.
You will need to use some CSS/JS to make the page look nice so users can toggle what option they want to use.
I am working on a project which needs User Authentication. The "Clients" are iOS (Swift) or Android (Kotlin) native applications. The original form of the API (NodeJS) used Facebook and Account Kit for OAuth and Phone authentication respectively. Since Account Kit shutdown, we moved to Firebase Phone Authentication for Phone but left Facebook in its original form. Now, we're wanting to consolidate our Authentication providers (to Firebase) but I can't seem to find a way to "convert" or "import" Facebook users to Firebase-based Facebook users.
So far, I've read through the Documentation, including the category about importing users, but it doesn't seem to indicate an ability to maintain backwards compatibility, while also moving forward to Firebase. What I mean is, it has an ability to set information, but it doesn't indicate that the same information will be used to authenticate that user as the same unique visitor.
What I am looking for is either transitory logic, which will handle this during login, or preferably, a "bulk-insert" type migration. Essentially, I want to have it setup so that the API only needs to keep a single authentication UID, and use only a single third party (even if they then use another subsequent third party) while maintaining user uniqueness (so that it doesn't create a new user for the same Facebook account).
Part of my problem in creating a temporary patch (not necessary if the main question is answered) is that I don't know of a way to differentiate between a Facebook UID and a Firebase UID to fork the logic. Again, this is only relevant if there isn't a solution for migration.
Feel free to request any more details that would be useful.
Update #1
I realized my question was open ended in what I was asking. I've been digging further and can better define my question:
I need a way to bulk insert users into Firebase's Authentication with a provider of Facebook. I know I can import them, via admin.auth().importUsers([...]) and that I can create accounts via admin.auth().createUser({...}) but when I do the former I can't seem to get back the user's UID, and the latter doesn't seem to allow specifying a provider. Am I missing something?
I want login system in my capsule so that i can provide user more recommendation based on their profile of interest. So far, neither I am able to find any document related to login facility nor any example. It would be appreciated if will get any document or example.
Bixby supports logging in through OAuth 2.0, and this is the best way to guide your users through a login flow.
You will need to provide your own service to handle this OAuth flow, as Bixby Developer Center does not offer any web hosting services.
https://bixbydevelopers.com/dev/docs/dev-guide/developers/actions.using-oauth
Also is there a possibility that user can user can use app as a guest
user if no login credentials?
When you define your endpoints, you can define Actions that require OAuth and other Actions that do not require OAuth and the latter ones will define the "guest user" flow that is capable within your capsule prior to logging in.
If you don't need all the features of OAuth, and only need to store a few things between sessions with the same user, you may use the $vivContext.bixbyUserId value as an anonymous, but unique identifier for a user, and store their preferences using that id as a key, in a 3rd party database that you maintain.
I've done this with the "My Brain" capsule, to store quick memories/notes for users, without any requirement that they login or establish an account. I've created a tutorial version of the My Brain capsule that outlines the steps you need to use AWS for this purpose. Please feel free to clone or fork it and customize it for your needs.
I have a running website, where users already have accounts. And I am trying to create a Google Assistant agent, accessible on Android, to help users access their information.
My issue is that I can't detect returning users on Android Smartphones, each time they have to sign in.
I tried Anonymous User Identity, but it is soon to be deprecated.
Is there an other way to keep track of users?Using some kind of userId that I can store, so I can make "my own Acount Linking" linking the person/Smartphone with already existing user accounts.
There are a few angles to your question.
Is there any way to keep track of users?
Yes... but...
You can store a userId that you generate in the user storage area. You do need to treat this like you would a cookie, so some jurisdictions might impose restrictions on this, but this is one approach to moving from the anonymous ID that is being turned off soon.
But...
How do I let them log into my service through the Action?
That is the problem. The General Policies states the following limitation for collecting user data:
Authentication Data
(including passwords, PINs, and answers to security questions)
Don't collect authentication data via the conversational interface (text or speech).
After a user's account has been linked, PINs or passwords may be used as part of a second verification process.
So you need to use Account Linking to connect to the existing account on your service.
How can I do Account Linking if I don't require Google Sign-In?
You can still use Google Sign-In for Assistant if it will (or may) provide the information as part of the profile that match what you have. So it doesn't need to use the same account - just have the same email (for example).
But that still may not be enough.
For other cases, you can look into setting things up to work with an OAuth server that you control.
So why use Google Sign-In if I setup an OAuth server that uses Google Sign-In?
Google Sign-In is good for a more streamlined flow, if you can use it. It can be done completely with voice, such as with a smart speaker, instead of requiring the user to go to a phone to complete the login. So if you have the user's email address in your account system, and you also get this from Google Sign In, then you can connect the two accounts.
In some cases, such as if the user is expected to have logged into the account on your website first, they won't even need to do that. If both the voice client and web client use the same Google project, then authentication will take place automatically.