Hi,

Please refer the below blog post for creating custom logins using facebook and google oauth.

https://docs.microsoft.com/en-us/aspnet/mvc/overview/security/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on

Thanks

Ravindra

I would also recommend the EPiServer.Cms.UI.AspNetIdentity. Because, as internally CMS accounts are also stored in the same table (dbo.AspNetUsers). Even if in future you install and use the commerce you can import your user into contacts using script.

And, the blog shared by Ravindra very well fits for your requirement.

Thanks

Praful

Thanks Praful, one question.

Are there any security issues with combing the cms users and the website users in the same system? I can imagine that mixing these can give some website users more rights then they need.

Hi Holden

The solution Ravindra points at supports both regular users (username and password), external users and linked users (those with password and external key).

All those users will be created in the same user table in the database, and are equal in terms of how they can be used. External-only users will get a NULL password and an external login key reference.

In the Episerver Admin section, you can then list and assign roles to them. And technically, if you choose to assign such backend rights to a user with an external claim, you will actually be able to login to Episerver with external OAuth providers, like Facebook or Github.

Thanks Stefan, can you also explain what the purpose of EPiServerProfile is?

I think the EPiServerProfile is for internal use (personalization) purpose and we should not mix it with the user managment. You can read more about it on developer guide

https://world.episerver.com/documentation/developer-guides/profile-store/

Thanks.

Storing user extended profile in Profile store is only helpful if you want to do any personalisation on this data. 

EpiserverProfile is used internally by Episerver to store some editor user preferences, like preferred language of the editor UI etc.

Historically, it has also been used for storing user metadata data (like first name, last name, time zone, company etc.) for Membership users.

You can still use it for this. Even with ASP.Net Identity available. But I prefer to extend the Identity SiteUser object with the custom properties I need.

In Commerce solutions, I always opt to add most of the custom user properties to the Contact entity type.

Performance-wise, beware that Contact objects are cached, but profile and Identity objects are not. So if you make a popular website with profile or Identity data, consider whether you need to look up and print the user's first name on all pages (for example). 😉