Aspnetcore.docs: Explain the Authentication flow

[John0King]

This section of document should be about how to do authentication process, but now , this section is about Identity !👎
Where can I learn how to write a Authentication Handler ?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 94bfd895-d2af-390b-0801-428b36a27ff4
• Version Independent ID: 0e0d870e-e49a-e16c-c259-68d58e701b8f
• Content: Introduction to Identity on ASP.NET Core
• Content Source: aspnetcore/security/authentication/identity.md
• Product: aspnet-core
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

[Rick-Anderson]

Why do you want to write an authentication handler? Why not let Identity do that for you? See

[John0King]

@Rick-Anderson It's not about using Identity or not, It's about understand the Authentication flow, Microsoft.Identity is just a member system that use the Cookie Authentication flow.

This section of document (the Security->Authentication) should explain how authentication work Eg. IAuthenticationService IAuthenticationSchemaProvider, IAuthenticationHandler ,
then introduce the build in implement Cookie OAuth JwtBearer
at the last introduce Identity as a integration solution

Microsoft.Idenity is not a standard, it's just an implemention ,
I believe that many developer try asp.net/asp.net-core and stuck in the authentication/authorization part.

and another reason is about implement a third party authentication nuget library.

[MattNCI]

Yep I agree with John0King as to I've been stuck forever in refactoring between app upgrades because the Authentication flow and its dependencies are not sufficiently documented. "developers developers" got lost trying to figure it out :''D

[MattNCI]

Also, there is no such thing in Visual Studio for Mac :/

[Rick-Anderson]

https://visualstudio.microsoft.com/vs/mac/

[kurtisdunn]

@John0King +1 for authentication flow docs as well proprietary identity structure.

[bensongathee]

I think I also have an issue related to the work flow

When is the Authentication cookie bound to the current authenticated user and How does the bind happen?
Hey guys, so I'm working on an asp.net web application and I'm having trouble figuring out:

1.) When is the Authentication cookie bound to the current authenticated user?

2.) How does the bind happen?

Though it works, I find it weird that the (Login method), accessible via (// POST: /Account/Login) does not in anyway bind the Authenticated user to the Cookie after confirming that the user exists in the database.

Can anyone give a simple and easy to understand explanation why this is the case!!! Haven't found any good documentation yet after a sleepless night

I'm using the default [ASP.NET Web Application(.NET Framework)] template,

Here is the configure sign in cookie,

app.UseCookieAuthentication(new CookieAuthenticationOptions

{

AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,

LoginPath = new PathString("/Account/Login"),

Provider = new CookieAuthenticationProvider

{

// Enables the application to validate the security stamp when the user logs in.

// This is a security feature which is used when you change a password or add an external login to your account.

OnValidateIdentity = SecurityStampValidator.OnValidateIdentity(

validateInterval: TimeSpan.FromMinutes(1),

regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))

},

SlidingExpiration = false,

ExpireTimeSpan = TimeSpan.FromMinutes(2)

});

And here is the Login post form which confirms and authenticates a user with no cookie reference
// POST: /Account/Login

[HttpPost]

[AllowAnonymous]

[ValidateAntiForgeryToken]

public async Task Login(LoginViewModel model, string returnUrl)

{

if (!ModelState.IsValid)

{

return View(model);

}

// This doesn't count login failures towards account lockout

// To enable password failures to trigger account lockout, change to shouldLockout: true

var result = await SignInManager.PasswordSignInAsync(model.Email, model.Password, model.RememberMe, shouldLockout: false);

switch (result)

{

case SignInStatus.Success:

return RedirectToLocal(returnUrl);

case SignInStatus.LockedOut:

return View("Lockout");

case SignInStatus.RequiresVerification:

return RedirectToAction("SendCode", new { ReturnUrl = returnUrl, RememberMe = model.RememberMe });

case SignInStatus.Failure:

default:

ModelState.AddModelError("", "Invalid login attempt.");

return View(model);

}

}

[Rick-Anderson]

Thanks for contacting us.
We don’t have the resources to invest in this area, so we are closing the issue. Should your request generate enough 👍 responses, we’ll reconsider.