Multiple Authentication types in ASP.NET Core 3

[gvsrini]

For Web Users, I am doing Cookie based authentication and for IOT devices, JWT Auth. But I also have several APIs which are used by BOTH Web and IOT users.

If a Cookie exists, I am expecting it to use Cookie/Identity Auth and if bearer exists, JWT Auth. Effectively it may have to try BOTH.

I can get them to work individually i.e., EITHER Cookie Auth or JWT Auth, but not both together!

Following is my code snippet from .Net Core 2.2 application which works exactly the way I need it.

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)  
                .AddCookie() 
                .AddJwtBearer(cfg =>
                {
                    cfg.RequireHttpsMetadata = false;
                    cfg.SaveToken = true;
                    cfg.TokenValidationParameters = new TokenValidationParameters
                    {
                        ValidIssuer = Configuration["JwtIssuer"],
                        ValidAudience = Configuration["JwtIssuer"],
                        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(Configuration["JwtKey"])),
                    };
                });

services.AddMvc(config =>
                {
                        var defaultPolicy = new AuthorizationPolicyBuilder(new[] { JwtBearerDefaults.AuthenticationScheme, IdentityConstants.ApplicationScheme, CookieAuthenticationDefaults.AuthenticationScheme })
                                        .RequireAuthenticatedUser()
                                        .Build();
                        config.Filters.Add(new AuthorizeFilter(defaultPolicy));
                 });

Can someone help we with what changed in .Net Core 3 and how I can resolve this issue.

[blowdart]

• When you say "both together" what do you mean?
• How are you applying authorization to your endpoints?
• Are there policies involved anywhere?

[gvsrini]

When you say "both together" what do you mean?

• Say, for example, the server gets two requests simultaneously, for the same API endpoint - One from IOT device and other request from browser. Server should be able to first try CookieAuth and if it fails then try JWT Auth. Only when both tries fail it should send Unauth response. This way there doesn't have to be any special handling for different types of user agents.

• In this particular scenario, IOT request and Browser request will both succeed, if they send correct JWT and correct Cookie respectively.

• A loose analogy is like that of a firewall rule chain

How are you applying authorization to your endpoints?

• Just using Authorize attribute. No Authentication schemes/policies defined in here.

Are there policies involved anywhere?

• There are no additional policies involved.

[blowdart]

Just using Authorize attribute. No Authentication schemes/policies defined in here.

That's the problem. You need to specify the schemes in the Authorize attribute, in the , otherwise it's just going to use the default one, and not anything else. Use the AuthenticationSchemes property to set a comma separated list of schemes you want to try

[gvsrini]

• Is this a change specific to 3.0 as it was working without these additional attributes in 2.2?
• Is there no alternative mechanism to tell that all schemes should be tried for all Controllers/APIs having Authorize attribute?
• Is this somehow a bad practice, especially because most of our APIs are used by both kinds of users.

[blowdart]

• Is this a change specific to 3.0 as it was working without these additional attributes in 2.2?

No I don't believe so. It changed from 1.0 where it was all kinds of weird. it was certainly the intent in 2.x

• Is there no alternative mechanism to tell that all schemes should be tried for all Controllers/APIs having Authorize attribute?

You could use virtual schemes and then branch based on the request or path, see slides 24, 25

• Is this somehow a bad practice, especially because most of our APIs are used by both kinds of users.

This is now opinion. I don't like having both on an API endpoint because what happens if the cookie and the JWT are both delivered, or the user database backing the JWT issues a token for a username that is an admin in the cookie backed database. My opinion, and it's just an opinion, is to have two separate endpoints, which act as facades into a common codebase, once the identities have been verified.

[blowdart]

As this was a discussion, and it's been a couple of weeks with nothing new, closing.