aspnet identity invalid token on confirmation email

Question

I'm trying to confirm an account but I'm getting "invalid token." error.

Here's what I'm trying:

var code = await UserManager.GenerateEmailConfirmationTokenAsync(user.Id);
var callbackUrl = Url.Action("ConfirmacaoEmail", "Usuario", new { userId = user.Id, code = code }, protocol: Request.Url.Scheme);

await UserManager.SendEmailAsync(user.Id, "Ativação de Conta", user.GetEmailAtivacao(model.Nome, callbackUrl));

if I call UserManager.ConfirmEmailAsync after this code, I can confirm the account. However, if I open the link that it's inside the variable callbackUrl and try to confirm through that action, I'm getting the error.

I thought it could be something with OwinContext, so I've decided to call HttpContext.GetOwinContext().GetUserManager<MyCustomUserService> but I'm getting the same error.

Any clues?

Solution 1

Most likely that the code in transit is modified by browser. Try doing UrlEncode on the token:

var code = await userManager.GenerateEmailConfirmationTokenAsync(userId);
code = System.Web.HttpUtility.UrlEncode(code);

Otherwise browser messes with the special symbols that can be present in the token.

Solution 2

I have experienced the same problem. I solved the problem with the following code.

Sample:

var emailToken = _customManager.GenerateEmailConfirmationToken(userId);
emailToken = emailToken.Base64ForUrlEncode();

Extension Methods => Name Space : System.Text,System.Web

public static class UrlEncoding
{
        public static string Base64ForUrlEncode(this string str)
        {
            byte[] encbuff = Encoding.UTF8.GetBytes(str);
            return HttpServerUtility.UrlTokenEncode(encbuff);
        }

        public static string Base64ForUrlDecode(this string str)
        {
            byte[] decbuff = HttpServerUtility.UrlTokenDecode(str);
            return Encoding.UTF8.GetString(decbuff);
        }
}

Solution 3

In case these solutions aren't working for you - I ran into the problem in a Asp.Net Core project because I had added the following configuration in Startup.cs:

services.Configure<RouteOptions>(options =>
{
  options.LowercaseUrls = true;
  options.LowercaseQueryStrings = true;
});

The second setting was causing the confirmation code to get converted to lowercase, which caused validation to fail. Ideally I'd like to keep query string parameters lower case, and not alter the query string values, but I'm not finding a way to do that, so I just removed the query string setting:

services.Configure<RouteOptions>(options =>
{
  options.LowercaseUrls = true;
});

Solution 4

Ok, this wasted hours - no, days - of my life. After trying all other suggestions in this thread an in Asp.NET - Identity 2 - Invalid Token Error I found that instead of calling

await SignInManager.SignInAsync(user, isPersistent: false, rememberBrowser: false);

in the Register-method just before the GenerateEmailConfirmationTokenAsync-block

await SignInAsync(user, isPersistent: false);

was called which is defined as

private async Task SignInAsync(ApplicationUser user, bool isPersistent)
{
        AuthenticationManager.SignOut(DefaultAuthenticationTypes.ExternalCookie);
        AuthenticationManager.SignIn(new AuthenticationProperties() { IsPersistent = isPersistent }, await user.GenerateUserIdentityAsync(UserManager));
}

I think this was caused by scaffolding the application with an older ASP.Net MVC Version. The described method can be found in http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity from 2013.

Solution 5

Serdar's solution was the key to the solution for empty spaces and + simbols using Angular as client web application.

But sometimes I was getting random "invalid token" error messages. AFter some queries to the user's database I've found that those errors were only with those users having spaces o dashes in their UserName.

Solution was configure the User Manager to allow those characters in UserNames. Meant to say that my user database was migrated from Druppal directly to SQL Server and many of those users avoided the default policy from UserValidator at User Manager.

You can find how-to configure the UserValidator to allow non-alphanumeric characters at the end of this thread:

Asp.NET - Identity 2 - Invalid Token Error

View more solutions

Comments

[Thiago Custodio]

I don't know why, but I've changed from POST to GET and it works.

[Giox]

@ThiagoCustodio what does mean you have change from POST to GET, what and where? Please be more specific to help other people...

[Thiago Custodio]

@Giox It was a problem with the confirmation token. When I was reaching the action using POST, the code did'nt work. So I've changed the code, to achieve the action using GET and it worked. For me it doesn't make sense, but I could solve the problem with this little change.

[Giox]

@ThiagoCustodio Thanks. Yes I can't see much sense in it me too!! BTW after struggling on it for hours I discover that my Invalid Token was dued by different app name set in Microsoft.Owin.Security.DataProtection.DpapiDataProtectionPr‌​ovider(...appName) in the ApplicationUserManager.Create() method.

[Eric Carlson]

I had to add UrlDecode(code) to the ConfirmEmail action for this to work.

[ProfNimrod]

@ezycheez UrlDecode may have been needed for an earlier version, but adding the UrlDecode broke it for me in MVC5.2.3. The code is automatically decoded, and doing it again introduced differences.

[tymtam]

This can still cause trouble because the token contains '/' which may mess up routing.

[trailmax]

@Tymski Url encoding converts / into %2F

[tymtam]

@trailmax Yes but this affects angular routing, for example. Base64 is the way.

[trailmax]

@Tymski Token comes in Base64 from the framework. Yet Base64 can contain symbols + and / (faqs.org/rfcs/rfc4648.html scroll to "Table 1: The Base 64 Alphabet") - both have a special meaning in URI. Hence you need to url-encode it

[trailmax]

@Tymski Unless you are talking about Base64Url. But token still comes in standard Base64 and you still need to do operations to make it URL safe.

[tymtam]

Yes, I meant bas64 for url. HttpUtility.UrlEncode'd token will still contain forward slashes (as %2F) and this will interfere with routing if you use it to generate a URL in the format of /x/y/:token.

[trailmax]

@Tymski in this case your solution deserves a separate answer. I suggest you write it up and get some upvotes -)

[tymtam]

@trailmax, Serdar Çatalpınar's answer provides the solution which addresses the problem :)

[mgPePe]

That doesn't work, it gives me "The request filtering module is configured to deny a request that contains a double escape sequence"