Should we rework the authentication implementations provided in Arcus.WebApi.Security ?

[fgheysels]

First of all, I'd like to say that the current authentication implementations that are available in Arcus work well and are easy to use. (I'm talking about these [outdated docs] ).

However, it looks to me that they do not play well with the authentication mechanisms that are provided by Microsoft in ASP.NET Core.
If you'd like to use the Authorizeattribute for instance, you'll need to register one (or more) authentication-scheme's and corresponding authentication handlers. (See this info).

Shouldn't we rework our auth implementations so that it is compliant with the mechanisms that ASP.NET Core already provide ? We could do that by implementing our own AuthenticationHandler for shared accesskey / API key authentication and Certificate authentication. (The AddJwtBearer extension method inside Arcus already uses these mechanisms).

Any ideas or opinions @stijnmoreels , @gverstraete, @meersschautarnaud ?

[stijnmoreels]

I think I see your point. You would want to use [Authorize] and behind the scenes, it would use shared access token, certificate.... right?
The authentication filters here were always made to use independently from that. Our custom authentication mechanisms all have their separate attributes with optional / required options to provide, and ways to bypass them.
I'm not sure if we move fully towards the ASP.NET Core approach as described, if we would still have all the available features as we have now.

Ps.: the reason JWT token already has that, is bc we provide an extension on the existing one; the JWT authorization we have in place (and implemented ourselves) is also using the filters.

[stijnmoreels]

I think we will also lose our now-available fine-grained control.

[gverstraete]

I'm not sure what you mean with "fine grained control", but I do like the general idea of this. But this makes me think we cannot be the first ones doing this. I think we first need to do some investigations...

[stijnmoreels]

We allow comsumers to specify on operation and controller level what authentication system they want to use, and what this includes. That's what I mean with finr grained control. If we move towards the proposal, we lose that and it would all be on a global level. We do recommend the global level, but that doesn't mean we should discard our current fine grained control of authentication.

We could indeed look for something else, but it was definitely one of the first since we started this couple years ago.

[meersschautarnaud]

I do like the idea of being compliant with the mechanisms provided by ASP.NET Core. I also get the point of @stijnmoreels that fine-grained control can be useful, but if I understand the docs correctly you can also use attributes to specify which authentication scheme you want to use.

[fgheysels]

Indeed. When using the ASP.NET Core mechanisms, you can also define which methods require authentication and which not.
However, what you cannot do -as far as I know- , is specify that operation A must be secured via authentication method A (jwt token f.i.), and operation B must be secured via an api key. However, I don't think this is a situation that is likely to occur.

[stijnmoreels]

If we are clear about everything and provide a migration guide, this would be ok, I guess.

[stijnmoreels]

If I read the docs correctly, it would mean that our shared access key/certificate/jwt will correspond with a certain custom schema, and that the consumer should register our custom IAuthenticationHandler for that custom scheme. This, for sure, will benefit from extra extensions to make this process less prone to errors.

[fgheysels]

So, what would be the conclusion of this discussion ?

[stijnmoreels]

Already did some but couldn't figure out yet what authentication result we should return as these new authentication handlers forces us to use claims and authenticated users, and in our case with shared access key authentication and the like, there's no such concepts (I think)?

[stijnmoreels]

@fgheysels response on this:

With shared access key authentication, you indeed do not require a user or a claim.
However, I once did something similar, a long time ago (2018) in asp.net core 2.
Basically , I implemented an AuthorizationHandler which took care of the verification of the required access key header. When login was successfull, an AuthenticateResult was returned which returned a dummy 'ClaimsPrincipal'.

Maybe you can consider this overkill for such a 'simple' feature.

[stijnmoreels]

Aha, that's an idea. Wouldn't mind if we had to do that. We just have to make sure that moving to this new authentication system is worth the effort. The default [Authorize] attribute support seems like the most major benefit?