The AspNetUserLogins table Identity

Question

What is the AspNetUserLogins for? Is It to store the logins from the user? How can I then update this table with that data?

Solution

What is the AspNetUserLogins for? In Asp.net Identity, the Identity system uses the AspNetUserLogins table to hold information about 3rd party/external logins, for example users who login into your site via Google, Facebook, Twitter etc. The AspNetUsers table is the primary table to store user information, this is linked to AspNetUserLogins via UserId -> AspNetUsers.Id.

For example if the user logs into your site via Facebook, then the LoginProvider is the name of the service which provided the login, so in this case "Facebook", the ProviderKey is a unique Facebook key associated with the user on Facebook.

This table is used by the Asp.net external authentication providers.

Is it to store the logins from the user? No not really, it is used as explained above

How can I then update this table with that data? You don't update the data in this table, usually when a user logs in via external provider, after user has been authenticated, the provider returns a ClaimsIdentity, which has users claims and one of those is a unique id of the user in the external provider, this gets automatically updated in this table.

read more about external providers here

Comments

[Steve Greene]

That table is part of the Identity system. You will want to use an Identity UserManager to maintain that data. asp.net/identity

[aruno]

If you do want to manually add data to the table you can do so with : userManager.AddLoginAsync(user.Id, new Microsoft.AspNet.Identity.UserLoginInfo("Facebook", id)). This will be needed if you're using the Facebook Javascript API to login via the Facebook login button and need to associate FB user id id with the user id in ASPNet Identity user.Id (which is a guid by default)

[Mayyit]

I'd really like a way to be able to have multiple UserLogins from different providers for the one user, so that they can choose whichever way they like, including local passwords, as long as everything comes back to an email address that resides uniquely in Users. This doesn't seem to be a supported or discussed scenario at all. Upon confirmation, the scaffolded pages will case a complaint that the user already exists.