Consider having the UserValidator ensure that SecurityStamp != null

[shima20]

When I called var principal = await _signInManager.CreateUserPrincipalAsync(user); , I was receiving an ArgumentNullException and had no idea what the issue was. Kevin from Openiddict told me to register UserClaimsPrincipalFactory to step in and see what field was null. This led me to find that my SecurityStamp was null and therefore caused the exception. Is this a bug?

if (UserManager.SupportsUserSecurityStamp)
            {
                id.AddClaim(new Claim(Options.ClaimsIdentity.SecurityStampClaimType,
                    await UserManager.GetSecurityStampAsync(user)));
            }

[HaoK]

SecurityStamps should never be null for a store that supports user security stamp.

[kevinchalet]

SecurityStamps should never be null for a store that supports user security stamp.

Except it was, in this case (using the default EF Core store).

It's also worth mentioning that there's nothing that prevents setting SecurityStamp to null: https://github.com/aspnet/Identity/blob/dev/src/Microsoft.AspNetCore.Identity.EntityFrameworkCore/UserStore.cs#L1242-L1252

[HaoK]

Typically this usage is updated by the manager, I mean sure you can set it to null directly but things will blow up.

https://github.com/aspnet/Identity/blob/dev/src/Microsoft.AspNetCore.Identity/UserManager.cs#L421

We could consider adding validation in the default user validator for this since this does seem to trip more than a few people up.

[kevinchalet]

@shima20's case is obviously an atypical case, as he somehow managed to get a null security stamp.

FWIW, I don't think the principal factory should shock on null values. It should be a bit smarter and ignore null claim values.

[HaoK]

Not for something like this, the security stamp is critical well for 'security' :) Its a major error if its null... similar to having no user id/name etc, its the user validators job to make sure the user is in a good state

[kevinchalet]

Critical seems a bit excessive (it's only used for cookies/tokens invalidation), but okay. As long as there's a check somewhere that prevents this illegal case, I'm fine 😄