Identity.Server
Your own authorization server, deployed into your AWS — permissions declared in code, checked at build time, enforced on every request and synced to DynamoDB.
Fine-grained authorization for every action.
Permissions in code
Put [Module] on a controller and [RequiresPermission] on each action. Keys come out as orders.write, granted per group.
[RequiresPermission("read")] Checked at build time
Analyzer rules fail the build when a guarded controller has no [Module], or a name has spaces or runs past 50 characters.
PERM001 – PERM005 Enforced per request
Each guarded action checks the caller’s groups against its key and answers 403 before your code runs.
403 Forbidden Synced to DynamoDB
One call switches authorization on. With SyncPermissions set, every module and its permissions are written at startup.
UseServerlessAuthorization() A catalogue to build on
List every module with its permissions, status and last sync, paged. It’s the data a role-editor screen needs.
GetSystemModulesAsync() Pairs with Identity
Implements the same user and group contract as Kanject.Identity, so your services call both the same way.
IUserIdentityService Inside your service.
On Lambda or in any container.
Identity.Server is a .NET library, not a service you call. Add the package, register it in Program.cs, and it runs inside your own service, in process. Ship that service as a Lambda function or as your own container on ECS, EKS or App Runner — the module goes wherever your code goes.
- ✓ In process: your code calls the module directly — no sidecar, no extra network hop
- ✓ Built from your code: your image or Lambda package, patched on your schedule
- ✓ Configured in
Program.cs, with values from your own settings
Kanject.Program.cs, and exposes a typed API the rest of your service can use immediately.
Want in early?
Identity.Server is in private beta. Tell us what you'd build with it and we'll bring you in as places open — and you'll help shape it before general availability. No purchase, no sales call.