Xen.Utils.AspnetAuthorizationHelper.Minting 4.1.1

dotnet add package Xen.Utils.AspnetAuthorizationHelper.Minting --version 4.1.1
                    
NuGet\Install-Package Xen.Utils.AspnetAuthorizationHelper.Minting -Version 4.1.1
                    
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Xen.Utils.AspnetAuthorizationHelper.Minting" Version="4.1.1" />
                    
For projects that support PackageReference, copy this XML node into the project file to reference the package.
<PackageVersion Include="Xen.Utils.AspnetAuthorizationHelper.Minting" Version="4.1.1" />
                    
Directory.Packages.props
<PackageReference Include="Xen.Utils.AspnetAuthorizationHelper.Minting" />
                    
Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package.
paket add Xen.Utils.AspnetAuthorizationHelper.Minting --version 4.1.1
                    
#r "nuget: Xen.Utils.AspnetAuthorizationHelper.Minting, 4.1.1"
                    
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
#:package Xen.Utils.AspnetAuthorizationHelper.Minting@4.1.1
                    
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package.
#addin nuget:?package=Xen.Utils.AspnetAuthorizationHelper.Minting&version=4.1.1
                    
Install as a Cake Addin
#tool nuget:?package=Xen.Utils.AspnetAuthorizationHelper.Minting&version=4.1.1
                    
Install as a Cake Tool

Xen.Utils.AspnetAuthorizationHelper.Minting

Joins Xen.Utils.ApiKeyMinting to Xen.Utils.AspnetAuthorizationHelper. The minting core deals in plain strings and knows nothing about claims or ASP.NET; this package makes those strings into app-internal claims, and back.

What it does

Type Does
StandardApiKeyHasher<TApiKeyStandard> Hashes keys with whatever the api key standard uses.
PolicyRequirementCatalog<TStandard, TPolicyContainer> Your policy definitions, flattened to permission strings.
MintedKeyClaimExtractor<TStandard, TApiKeyStandard> Grants app-internal claims to requests carrying a minted key.
SubjectSelectorExtractor The subjects a caller holds — the things grants are written against.
InternalPermissionClaims<TStandard> Permission string to claim, and back.

The part that earns its keep

StandardApiKeyHasher derives the hash from the api key standard rather than naming an algorithm. A stored hash is then, by construction, the exact value SpecApiAuthHandler will put in the claim when someone presents that key. Hard-coding the algorithm on both sides works right up until one of them changes, and the failure — keys that authenticate perfectly and then match nothing — looks nothing like its cause. There is a test pinning it.

Registering

builder.AddSpecialApiKeyAuthentication<SpecApiAuthStandardsV2026>();

builder.AddApiKeyMinting<MyInternalAuthStandard, SpecApiAuthStandardsV2026, MyPolicyDefinitionSet>(
    scope: appInstanceKey,
    configureMinting: o => { /* lifetimes */ },
    configureSubjects: o => o.SubjectClaimTypes = ["roles"],
    keyPrefix: "ptk_");

You still register IMintedKeyStore and IMintingGrantStore yourself — persistence is deliberately not this package's business either.

The admin-like claim of TStandard, if it declares one, is added to the never-mintable deny list automatically. It belongs in code rather than in a grants table, so that no amount of later data entry can hand out permanent admin.

Keys minted with KeyValidity.FollowsMinter (personal delegations, see Xen.Utils.ApiKeyMinting) also need an IMinterSubjectSource, registered as a singleton (the authorizer is one). Without it those keys carry nothing.

Subjects default to app roles

Grants are written against a claim type and value, and the default allow-list is roles alone. Roles are named by your application rather than the directory, they do not fall off a token when someone belongs to a great many groups, and a whole group can be assigned to one — so department-wide delegation still works. Without the allow-list a grant could be written against something every caller carries, such as an audience or an issuer, and would then be held by everyone.

Product Compatible and additional computed target framework versions.
.NET net8.0 is compatible.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed.  net9.0 was computed.  net9.0-android was computed.  net9.0-browser was computed.  net9.0-ios was computed.  net9.0-maccatalyst was computed.  net9.0-macos was computed.  net9.0-tvos was computed.  net9.0-windows was computed.  net10.0 is compatible.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
4.1.1 144 10/24/2026
4.1.0 107 10/24/2026