In project I'm working on we use IdentityServer which is identity server for lots of clients (mostly websites)
I have such problem:
1. User creates account using registration page that's within website X.
2. After registration verification email is being sent. This link contains guid that is user specific and based on that I can get user data from user store
3. When clicking verification email user should be automaticaly logged in with IdentityServer.
Is it possible to perform step 3 using IdentityServer? If yes - could you give me some hints on how to do that?
Related
I'm working on my first MERN fullstack project (an e-commerce demo). I have almost finished the authentication part, but I am having doubts about how to manage the users who have the same registration email both through custom sign-in and google login on the MongoDB database.
While doing various researches, I noticed that one of the methods used is the following:
1- If the email of the user who logs in via google login is already saved in the database as the same user had already registered via traditional sign-up, a new user will not be created in the database, but with both methods of signing -in we will point to the same user already saved with that email.
2- If there are no users saved in the database with that email (as the user logged in for the first time with google login and did not first register traditionally), once the user logged in with google login, it will be saved to the database for the first time.
However, this method presents problems with regard to the second type of users mentioned above.
In fact, if we merge the accounts with the same email on the database, if the user logs in for the first time with google, no password will be saved on the database. Therefore, if the same user decides in the future to log in in the traditional way, he will not be able to do so because he will not be able to fill in the password field.
How to solve this problem?
Usually sites with the "first Google login immediately creates an account" have 2 solutions to this problem:
As part of the "immediately create an account", they directly ask the user to choose a password.
Alternatively, their "Change password" section allows creating a password should there be none yet. Therefore the account is indeed passworld-less at the beginning, but the user can opt to add a password.
For the 2nd solution, there's the small problem that if the user loses access to their Google account and didn't set a password, they're locked out. Rare case which might not be worth looking out for. And perhaps your Customer Service can still help them out.
Hoping someone can shed some light on the following matter;
I got an Angular & .Net core Web API application that uses Azure B2C to authenticate users.
User accounts are created by the users themselves via the signin/signup custom policy or administrator can create accounts via the app using the Graph API.
Due to the requirements, the app uses usernames (as opposed to email addresses) to log into the application. So far I've managed to get everything working except for the following scenario:
When an account is created via the Graph API, the owner of that account cannot reset the account's password. The error is "An account could not be found for the provided user ID".
This isn't the case for accounts that get created via the custom signup policy so I did some comparison and found that for those account that get created via the Graph API, the Email is missing (which can be found under User -> Authentication Methods). I looked at populating that field, but it appears the "Mail" attribute is 'read only' (not sure if that's the right attribute anyway).
At the moment I'm having to manually set the email via Azure so those account's passwords can be reset by their owner if necessary. This is obviously not ideal and wanted to see if there is anyone that might have gotten around this issue, or a least get confirmation that this is indeed a limitation of the Graph API.
Thanks in advance for your help
So I managed to get this working using the approach outlined by Jas Suri. These are the steps that I went through
Created a custom attribute in my B2C tenant to hold the account email address
Included the custom attribute claim type (extension_emailAddress) as well as the strongAuthenticationEmailAddress in the TrustFrameworkBase.xml
Updated my apps's custom policies to include the technical profile for local account discovery. I basically just copied the necessary bits and pieces from here
Updated the local account discovery to perform the comparison against the extenstion_emailAddres instead of strongAuthenticationEmailAddress.
Added an extra step to the Sign up user journey so that the value in strongAuthenticationEmailAddress is copied to extension_emailAddress
Updated my Web API / Graph API "create user" function so that it sets the extension_appidguid_emailAddress
That's it. Now it doesn't matter how the account gets created, the email address will be stored in the extension attribute and the password reset will be able to find the account using that attribute.
happy to provide more details if anyone comes across this.
The problem is as you’ve identified, the Sign Up policy uses the strongAuthEmail attribute to store the verified email for a username based account. The Password reset policy will use this to verify the user owns the username. When creating the user with graph api, you can’t populate this field, it’s not exposed. The only option is to use a custom policy which stores this secure email in an extension attribute, and your graph api created users can then also target the same attribute to allow the stars to align.
Mail attribute is not the same as the Email under Authentication Methods, and currently there is no such graph api to set the Email value under Authentication Methods.
By the way, there is no need to create Azure AD B2C user for a user as users can sign up themselves.
I setup a password reset flow using Azure B2C and local Azure accounts that uses the user's email address and verification code. However, my client would like to have a password reset email sent to the user based on the user name, not email address. The user email would be looked-up behind the scenes and an email sent that would include a link to the password reset page as shown in the flow below.
After reading a gazillion articles on custom Azure B2C policies, I'm struggling to convince myself if it is possible to do what the client is asking for using Azure B2C.
In the sample password reset flow shown below, some of the areas I'm struggling with include:
Is it possible to create custom pages in the password reset flow such as the page in Step 4 that displays the user's masked email address, or the information page in Step 7?
Is there built-in functionality to look-up a user's email address and Active Directory Object ID based on their user name or would I have to call out to a custom Azure Function and use the Graph API to do this?
Is it possible to create and send a custom email that includes a hyperlink to the password reset page that includes the user's Active Directory Object ID as a query string parameter so the password reset page knows which user's password is being reset?
At the moment, it seems like it would be easier to create a completely custom ASP.NET MVC app to handle the requirements than it would be to use Azure B2C custom policies, but that isn't really a path I want to go down.
Is it possible to create custom pages in the password reset flow?
Yes you can create your own custom password reset user flow using azure active
directory B2C
In your case if you want to figure out your custom page you could
refer here
Is there built-in functionality to look-up a user's email address and
Active Directory Object ID based on their user name or would I have
to call out to a custom Azure Function and use the Graph API to do
this?
Using Microsoft Graph REST API you could fetch your user
information.
In your case you could use
List users
Get a user
To access user information you could also refer here in a great
details
Is it possible to create and send a custom email that includes a
hyperlink to the password reset page that includes the user's Active
Directory Object ID as a query string parameter so the password reset
page knows which user's password is being reset?
You can use the company branding feature to customize the
content of verification emails for resetting password.
Note : For better clarity you could check the Azure AD B2C: Frequently asked
questions (FAQ) before final work around Which definitely guide you to
define ultimate go ahead.
Update
As per Microsoft document right now you cannot create according to your sample exactly. See the screen shot there is and important remarks.
Thank you.
This GitHub project covers the case you describe. Still needs a lot of understanding about custom flows to get it working.
https://github.com/yoelhor/aadb2c-verification-link
I'm building a web application for two different types of users, with a different registration form for each of them. I could split up those forms and send a verification e-mail after the form is validated.
But I'd prefer to have one general small form where the user enters his/her e-mail address and user type. The server then sends a verification e-mail with a link to further complete the profile, depending on the chosen user type.
Now my question is: should I include a password field in the small registration form? I have seen it before on many websites, but I can't see why I would include it. My plan is to make the user choose his/her password on profile completion. Nothing about the user will be stored until he/she completes the profile (I would securely hash the e-mail address with a timestamp in a url).
In general, the developers ask all the details including password at the time of registration and they allow to login using the same password. However, there is an open risk of unverified user can access all or some of the feature of the application. Sometimes the application also provides time frame of 24-72 hours to activate the user account, within this period user can access account with some restrictions.
For sensitive applications, you can ask for the password once the user verify the email address. So, that you are assured about the verified user.
If you are providing the feature to access the user accounts without being verified, make sure that the unverified account users can access the account with restrictions according to your application context.
I'm new to azure (used to "default" ASP.NET apps) and giving it some tries I learned that:
a.) it is very easy to add mobile logins (using FaceBook, Twitter, MS-Account...)
b.) that I can't see any database storing this data (user IDs an so)
My needs are the following:
Enable users of a Win10 Universal / Mobile app to login with FB,... (works so far)
use these users (via ID or so) to assign custom database entries to them (profile or so)
assign (via some kind of management interface) the user to a role (for permissions)
merge different logins (let the same user login with different providers=
To explain this imagine a forum (driven by apps (UWP, Android, ...)):
The user logs in via Facebook.
After (example) 10 moderated posts he will be able to write posts without moderation. (assign to role)
Users can be manually added to roles (moderators)
Last not least if the preferred service is not available (some corporate networks for an example restrict Facebook access) - the user shall be able to use (for an example) Google to login with "HIS account".
I understand that "merging" may need to be done while both providers are available.
Something like - "you are logged in with FB - to you want to add Google login to your account - if yes pleas additionally login with Google now while your are logged in with FB...
Two extra points:
1. I don't want to have "username / password" (only social logins)
2. I want to store the users email (for notification purposes)
--used from the social provider if available - or manually entered
Is this possible with "Azure Mobile" or would it be better to create a "Web App" and add (somehow) add "Mobile capabilities" (login, push notifications..) to it?
Yes, you can absolutely do this. The token information (which is equivalent to the claims that you request when you set up the authentication within the Authentication / Authorization Settings blade in the Azure Portal) is available on the /.auth/me endpoint of your app. It's also available internally - for ASP.NET, that would be the MobileAppUser class. This is the IPrincipal for the request given an ASP.NET TableController decorated with the [Authorize] decorator.
You can adjust the information stored by the table controller. There is some sample code commented out of the FieldEngineer sample on GitHub for this.