Closed DeeJayTC closed 2 years ago
I would recommend you to don't implement an authentication. There are many packets out there for different kinds of authentication. The bigger problem is mostly the authorization in special in generated APIs like that. Take a look at authorization requirements. https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies
If that is implemented well you can be create a really great dynamic API.
(Btw. I create internaly at my company also an odata base controller with many things we support there. Like authorization and m to m mappings with ef core 3.1 etc...) So maybe I can inspire you a bit.
@paule96 yea love to chat.
The idea i had is pretty much just the ability to parse JWT's using Microsofts identity packages and allow people to set required scopes for endpoints. This can definitely work quite well but no idea if actually useful.
Without authentication the generated service can only be used behind a proxy etc. which is probably limiting
@DeeJayTC yes I see you have a bit different approche then the package others and I created. You want a standalone solution and then it makes more sense to implement it like that. The solution I reffering to is more integrated in an existing API project. So you add some services and a Middleware and you have a generated odata API. If you then add some packages for authentification and do there required setup is up to you.
The authorisation system we implemented, just uses authorisation requirements, so we a compatible with more or less any Auth packages for asp.net.
But for the standalone thing, I guess your only option is to create for each Auth provider you want to support, an extra package.
This package has a reference to the Auth provider and the logic to integrate it in the services/Middleware pipeline.
Enable authorization + authentication based on policy-based authorization in ASP.NET Core.