Identity Email Confirmation fails when token generated in a different assembly

[dotcom9]

Describe the bug

An ASPNET Identity email confirmation token generated in a different assembly fails when used in the UserManager.ConfirmEmailAsync method.

To Reproduce

1. Clone https://github.com/dotcom9/email-confirmation-token-bug
2. Open in Visual Studio
3. Run EF migrations
4. Register a user
5. Copy the UserId field value for the new user and paste in the _userId literal at the top of Mvc.HomeController
6. Run the Mvc and Api projects
7. Click on "Get token from Api" button
8. Observe error "invalid token"
9. Click on "Get token locally" button
10. In database, observe user account has been confirmed

Further technical details

• ASP.NET Core version: 3.1

• Include the output of dotnet --info
  dotnetinfo.txt

• The IDE (VS / VS Code/ VS4Mac) you're running on, and it's version
  vs-info.txt

[blowdart]

@HaoK do email tokens get wrapped up in data protection somehow?

[HaoK]

Yeah by default they use dataprotection

[blowdart]

@dotcom9 What's happening here is data protection, we take tokens and encrypt and sign them. However your applications are configured to share the keys used for this, so one app can't decrypt tokens encrypted with the other.

There are a couple of things to do, first configure the apps to share a keyring, and second set the apps to have the same application identifier.

How you share depends on your configuration, if, for example, both the api and web site are on the same machine you can use the file system. If they're in azure you can use blob storage. You can see the configuration options in the docs, these are the Persist* functions. Note that when you configure shared locations you also need to consider how the keys are protected in storage, these are the Protect* functions.

Once you have the keys shared you also need to configure the application name otherwise application isolation is going to kick in

[dotcom9]

This is great information, and with it I have solved my problem. Many thanks. I was unaware of Identity's dependency on DataProtection, though of course it makes sense. I couldn't find an obvious reference to it in the Identity documentation. Did I miss something, or is it an omission? I would have thought my use case was a common one.

[blowdart]

To be honest your use case isn't that common. I don't think I've actually seen it before, hence there being no documentation. Usually identity is self contained within the app, so it the use of data protection is handled automatically :)

I'm going to go ahead and close this now, because your problem is solved, but it you encounter more problems please feel free to reopen.

[dotcom9]

Ok, thanks for the help.