Generating token for email validation and registration security

Question

My boss gave me a list of 8K users in csv format and asking me to create accounts for them. The list have users with gmail, hotmail, and organization email addresses.

I am using MVC 5 and ASP.NET identity 2.

As I am reading CSV file, I am creating the user, and generating a token for them as below:

var userManager = new ApplicationUserManager(new UserStore<ApplicationUser>(_db));

var dataProtectionProvider = new DpapiDataProtectionProvider("Sample");
userManager.UserTokenProvider = new DataProtectorTokenProvider<ApplicationUser>(dataProtectionProvider.Create("ASP.NET Identity")); 

string code = userManager.GenerateEmailConfirmationToken(appUser.Id);
var callbackUrl = "http://localhost:2595/Account/Verify?t="+appUser.Id+"&c="+HttpUtility.UrlEncode(code);
SendMail(callbackUrl, appUser.Email);

Once I create a callback URL, I send an email to the user. When the User clicks on the link I sent, user goes to a password registration page, creates password and then logs in with the password he/she created.

Does this approach has any security flaws?

public async Task<ActionResult> Verify(string t, string c)
        {
            if (User.Identity.IsAuthenticated)
            {
                AuthenticationManager.SignOut();
                return RedirectToAction("Index","Home");
            }

            if (t == null || c == null)
            {
                return View("Error");
            }

            var user = UserManager.FindById(t);

            if (user == null)
            {
                return View("Error");
            }

            if (user.EmailConfirmed)
            {
                return View("AlreadyConfirmed");
            }

            var result = await UserManager.ConfirmEmailAsync(t, c);
            if (result.Succeeded)
            {
                user.EmailConfirmed = true;
                UserManager.Update(user);

                ViewBag.Id = t;
                return View("ConfirmEmail");
            }

            AddErrors(result);

            return View();
        } 

Answer 1

It looks secure enough considering the details you commented about, but I think the best course of action would be to cut the user ID out of the callback and have the user login normally to proceed with authentication if they are not logged in already. The exposure is not too bad as is, so if it is a pain to redirect back to auth page after login then I would say it's fine.