An ASP.NET Core based authentication and authorization middleware for HTTP triggered Azure Functions (In-Proc and Isolated)
Deprecating DarkLoop.Azure.Functions.Authorize and renaming it DarkLoop.Azure.Functions.Authorization.InProcess
Starting from 4.0.0, support for Azure Functions V4 Isolated mode with ASPNET Core integration is added. The package is now split into two separate packages, one for each mode.
The package for Azure Functions V3+ In-Proc mode is now called DarkLoop.Azure.Functions.Authorization.InProcess and the package for Azure Functions V4 Isolated mode with ASPNET Core integration is called DarkLoop.Azure.Functions.Authorize.Isolated.
Starting with version 4.0.0, the package is now targeting .NET 6.0. This means that the package is no longer compatible with .NET 5 or lower. If you are using .NET 5 or lower, you should use version 3.1.3 of the package.
This package is published but is now deprecated in favor of DarkLoop.Azure.Functions.Authorization.InProcess. All it's functionality remains the same. It's just a way to keep package naming in sync.
The IFunctionsAuthorizationProvider interface is introduced to allow for custom authorization filter provisioning to the framework.
By default the framework relies on decorating the function or type with [FunctionAuthorize]. You could skip this decoration and provide the middleware with an authorization filter sourced from your own mechanism, for example a database.
At this moment this can be done only with Isolated mode even when the interface is defined in the shared package.
Support for In-Process will be added in a future version, once source generators are introduced, as the in-process framework relies on Invocation Filters to enable authorization.
Replacing the service in the application services would break the authorization for in-process mode at this point.
Final preview version before release of v4.0.0
Includes:
Refactoring project to welcome Azure Functions Isolated model with ASP.NET Core integration
FunctionAuthorize effect at the application level.Adding support for disabling the effect of [FunctionAuthorize] attribute at the application level.
This is useful when wanting to disable authorization for a specific environment, such as local development.
Azure Functions recently added configuration for issuer and audience validation for the default authentication flows, not the one supported by this package through FunctionAuthorizeAttribute, which interferes with token validation when using our own Bearer scheme token configuration.
In prior versions, this package has functionality to clear Functions built-in configuration, but it was not enabled by default when using AddJwtBearer(Action<JwtBearerOptions> configure, bool removeBuiltInConfig = false). Since the use of this package is commonly used for custom JWT token, the default value of removeBuiltInConfig is now true.
Azure Functions recently added configuration for issuer and audience validation for the default authentication flows, not the one supported by this package through FunctionAuthorizeAttribute, which interferes with token validation when using our own Bearer scheme token configuration.
In prior versions, this package has functionality to clear Functions built-in configuration, but it was not enabled by default when using AddJwtBearer(Action<JwtBearerOptions> configure, bool removeBuiltInConfig = false). Since the use of this package is commonly used for custom JWT token, the default value of removeBuiltInConfig is now true.
Bug fixes
Bug fixes