What is CookieAuthenticationOptions.AuthenticationType used for?

Question

In my Asp.Net Identity Auth middleware setup application I have

app.UseCookieAuthentication(new CookieAuthenticationOptions { LoginPath = new PathString("/Login/"), //AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, Provider = new CookieAuthenticationProvider { OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<MyUserManager, MyUser>( TimeSpan.FromMinutes(30), (manager, user) => manager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie) ), }, }); 

I copied this from another application, and I just noticed that if I uncomment the AuthenticationType line, the login will succeed (I get a success message in my registrar written from my controller), but it always redirects back to the login screen.

The documentation for CookieAuthenticationOptions says:

The authentication type in the parameters corresponds to the IIdentity authentication property property. A different value may be assigned to use the same type of middleware to authenticate more than once in the pipeline. (Inherited from AuthenticationOptions.)

I really don’t understand what this means, why it will lead to a redirection of my login request (after successful login at least), and also that this parameter will be useful.

Answer 1

This is a string and can be anything. But this is an authentication type identifier. And you can have several types of authentication: your database with users, Google, Facebook, etc. As far as I remember, this is added as a claim to the generated cookie during registration.

You need to know the authentication provider when you sign up the user. If your authentication middleware is defined as follows:

  app.UseCookieAuthentication(new CookieAuthenticationOptions { LoginPath = new PathString("/Login/"), AuthenticationType = "My-Magical-Authentication", // etc... }, }); 

then for the user’s signature you will need the same magic line: AuthenticationManager.SignOut("My-Magical-Authentication")

This string is also passed to ClaimsIdentity when the principal is created. And without AuthenticationType principal cannot be authenticated because :

 /// <summary> /// Gets a value that indicates whether the identity has been authenticated. /// </summary> /// /// <returns> /// true if the identity has been authenticated; otherwise, false. /// </returns> public virtual bool IsAuthenticated { get { return !string.IsNullOrEmpty(this.m_authenticationType); } } 

This IsAuthenticated method IsAuthenticated used across the entire MVC codebase, with all authentication mechanisms relying on this.

Also, theoretically, you can log in through several providers and simultaneously release only one of them, leaving the remaining providers still authenticated. Although I have never tried this.

Another use I just found is if you do not provide CookieName in the middleware configuration, then Options.CookieName = CookieAuthenticationDefaults.CookiePrefix + Options.AuthenticationType; ( see the second if statement in the constructor ).

I am sure there are more places where it is used. But the most important thing is to ensure it and match the name, or you will get subtle errors in the authentication system.

Answer 2

I do not know the whole answer, but I have an example for which it would be useful.

I have a site with several tenants: the site works as a single instance, to which several domains are attached. Each domain is a separate tenant (with a separate set of users). To implement Facebook login for each tenant, I needed a Facebook application for the tenant. To set this up, I had to set a unique CallbackPath and a unique AuthenticationType for each tenant:

 var facebookOptions = new FacebookAuthenticationOptions { AuthenticationType = "Facebook-{tenantID}", CallbackPath = new PathString($"/signin-facebook-{tenantID}") } 

I thought it was also used as the name of the cookie, but this is not the case for external login like FacebookAuthentication. I noticed that this AuthenticationType value appeared on request:

• IdentityUserLogin.LoginProvider through authenticationManager.GetExternalLoginInfoAsync ()
• AuthenticationDescription.AuthenticationType through authenticationManager.GetExternalAuthenticationTypes () (seems logical ;-))
• IdentityUserLogin.LoginProvider for each user. Login (similar to 1)

Last, but not least, the AuthenticationType value is stored in the AspNetUserLogins.LoginProvider database column.

Answer 3

If you set up a new asp.net solution, the standard setup code (unlike the code you copied from another application) in Startup.Auth includes the line AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,

This creates a cookie (with the default name .AspNet.ApplicationCookie) that you can see if you look in your active browser cookie list, which is used (among other things) to check if the user is authenticated for each request. If the cookie does not exist (or the User is not authenticated in some way), the middleware redirects the route specified in your line LoginPath = new PathString("/Login/"),

The fact that this line is commented out in your code and your application work shows that there is some other non-standard configuration for user authentication in your code. If you uncomment this line and the login is successfully completed, but redirects back to the login, this indicates a conflict between the non-standard code and the middleware, which leads to the middleware determining that the user is not authenticated and redirecting back to LoginPath .

I would like to find out if your application has a non-standard authentication code and determine what exactly it does, and there should be a response to the conflict. The general advice is not to change the standard authentication code unless you know exactly what is meant (and it can get complicated, with a lot of traps for the careless).

In particular, this question is not only useful, it is fundamental to the standard work of Identity middleware. Your application has non-standard code. If so, you should fully determine what it is doing (and it matters) with respect to the security of logging in, or return to the standard identification code if you can.