Just to provide an update, we are close to launching a private preview. We are in the final testing stages for this feature. We will have another update in the next few weeks with instructions on how to join the private preview.
I've waited literally years for items on this backlog to be completed.
Given the rate of progress on this item, it's reasonable to assume that we will see more delays rather than an on schedule delivery.
Gotta go with what works now, and that's Google.
Evidently there are no third party packages, so this could be the only way. Don't care for firebase, love azure.
We have started the planning for this feature and hope to have a preview by the end of the calendar year. In the meantime, could you respond to email@example.com with the answers to the following questions:
- In which scenarios do you plan to force the user to change his/her password?
- What kind of information (if any) would you like to get back if the user goes through the reset flow?
- Do you currently or plan to track which users have reset their password?
We were hoping the onboarding process would consist of us registering their name and their email address and then force a password change at the next login. This would simplify the process for one user "inviting" another user to join. User A invites User B from User A's contact list. User B gets an email to signin (instead of signup) and at that point becomes a new user. We'd need the newUser claim, subject, object, email and display name. Initial password changes would not be tracked, subsequent changes maybe, but not if B2C would do it for us.
This really open up the onboarding options for us.
We are planning to do this in the next 6 months, however it will only be possible through the Graph API.
This is a great leap forward for us. Thanks!
Graph is OK, I've already set up other graph access, but not having to do all of this by hand would be great.
This actually cuts right to the heart of a huge support issue. We are developing a financial app. That means that when a customer forgets their email (or loses it because they lose their job, etc.) they are completely blocked out of their account. That's a show stopper.
At the very least, do what Google does and allow us to collect multiple alternate emails which can be verified as part of the signup process. Then recovery emails can be sent to multiple emails and any one can recover the account.
I don't sign up for any service today where I don't specify multiple recovery emails. And it's saved my butt plenty of times.
Please implement this. Thanks.
We’ve put out a new version of the sign in policy called sign in v2. This is available through the new portal experience and we have rebranded policies as user flows. Please give this a try and give us feedback through this link: https://microsoft.qualtrics.com/jfe/form/SV_0Gu45RkBy2YR1kh
But to be clear, you hope to release by May or just have a more accurate timeline by May?
More customization woes: I suppressed the Sign Up prompt, but if I list social providers on a Sign Up / Sign In page, I need to find out if they don't exist before B2C allows the user to add themselves. I am doing this to link multiple social providers under a single account in my system. With a "susi" policy, they get added before I can stop them. Works great with a pure sign in page with all the providers on it. It throws a 990002 which I can trap. Just can't customize it the page. :(
Based on someone else's suggestion, using CSS, I figured out how to suppress the "Sign Up" prompt on a sign up/sign in policy so I could customize the experience for just signing in. Thought I had a plan.
If you use the GraphAPi to set forceChangePasswordNextLogin to true, then trying to sign in on a sign up/sign in policy simply tells you that username/password doesn't exist. If you use a pure sign in policy, it works fine. Of course we can't customize a sign in policy.
I've reworked the identity section of my product more times than I can count trying to get some combination working with B2C. Every time I think I've got it, some other piece simply doesn't work.
We're going on a YEAR since Guillermo made this suggestion. That's a lifetime in this business.
David - couldn't agree more. ADAL doesn't work, MSAL doesn't work with Azure Mobile Apps, and I can't even customize the local sign in page. The signup/signin policies don't seem to respect the branding settings. Even the signin policy doesn't respect the branding settings if you pass in a login_hint.
I want to use this product so badly but man, are they making it hard.
If there's some magic that I don't know about, please tell me. Or give us some direction on timing.
/Jose Rojas comment is 7 months old.
While the company branding feature for local accounts is handy, we are looking for more control, like the other ui customization feature. Thanks.
The signup/singin policy does not automatically redirect to password update by design.
I’m leaving this item open though, to capture the ask to streamline this experience so as not to require the application to do this detection of the error code and subsequent redirection to the password reset policy.
This sounds great, but if you're using Azure Mobile Apps with B2C it doesn't work. You don't have the option to capture the error code. That means on a mobile device - using 'client.LoginAsync(...)' - when you select 'forgot password' the user sees the 'Unauthorized' response page. It works on sign-in, but when you pass 'login_hint' to a sign-in policy, the company branding quits.
You can use the login_hint parameter for this.
This is currently not on our roadmap. You can retrieve this value by making a call through the Graph API. If this is needed for your scenarios, please continue voting and we will review at a later date.
you can do this by calling the Graph API (I know, a pain) but it works.
I’ve gotten a few questions about this item recently, so I just wanted to give a more detailed status. We still have this on the backlog; it hasn’t been forgotten. But we don’t have a clear timeline for when we would get to it right now. The “unplanned” status just means that it can’t be tied to a timeline, but we do think this is a valid request that we would like to have in the product.
I'm using B2C to front end my Azure Mobile App from which I issue my own tokens. I have to add claims and other handle refresh directly.
I have no intention of ever having an identity store and the liability that goes with it.
I would like to be able to add Functions over time, but need to be certain that all endpoints are secure. Haven't looked at AF just yet, but seems almost certain it will be useful.
For applications that require cross document join, please consider the Gremlin API: https://docs.microsoft.com/en-us/azure/cosmos-db/create-graph-dotnet, which has primitives for joins, traversals, and other graph operations.
We are evaluating expanding the SQL grammar to support graph functionality, which will provide the ability to perform cross-document JOINs. Please upvote this item to help us prioritize this work.