Start here

What is Sentinel

A batteries-included, embeddable, code-first identity provider, authentication and authorization platform for .NET — the identity store for your apps and a standards-compliant OIDC/SAML/SCIM server for everyone else's.

Sentinel is an identity platform that lives inside your ASP.NET Core application as a family of fine-grained NuGet packages — and, when you want it standing alone, ships as a thin container-imaged reference host composed from the exact same packages. That combination — embeddable and runnable — is the gap Sentinel exists to fill.

What it is, concretely

One platform, four simultaneous roles:

  1. The identity store and token authority for your first-party apps — users, realms, organizations, teams, groups, sessions, passkeys, MFA, recovery codes.
  2. A standards-compliant OAuth2/OIDC authorization server for third-party and machine clients: authorization code + PKCE, client credentials, refresh tokens, discovery, JWKS, introspection, revocation, RP-initiated and back-channel logout — implemented in-house, no OpenIddict or Duende dependency.
  3. A SAML 2.0 endpoint on both sides: SP for inbound enterprise SSO against external IdPs, and IdP so legacy service providers can SSO against you.
  4. A SCIM 2.0 provisioning server — Users and Groups, per-organization bearer tokens.

Around that core sit the concerns every identity system eventually needs and most teams bolt on late: an RBAC+ABAC authorization engine with a formal permission grammar, refresh-token families with reuse detection, deterministic risk signals, four layers of abuse protection, signed webhooks, a tamper-evident admin audit chain, impersonation and break-glass workflows, GDPR export/erasure with per-user crypto-shredding, and importers for the systems you are leaving.

The shape of the code

Sentinel follows the same engineering discipline as its sibling Relay: hexagonal architecture with a framework-free Sentinel.Core, TryAdd-idempotent AddSentinel* DI extensions, mountable MapSentinel* minimal-API endpoint groups, options POCOs with exhaustive XML docs, and store ports with EF Core as the first persistence adapter.

builder.Services.AddSentinelEfCoreStores(o => o.UseNpgsql(connectionString));
builder.Services.AddSentinel();
builder.Services.AddSentinelAuthentication(o =>
{
    o.Issuer   = "https://id.example.com";
    o.Audience = "example-api";
});

var app = builder.Build();
app.UseAuthentication();
app.MapSentinelAuth();
app.MapSentinelProfile();

Every endpoint group is opt-in: MapSentinelAuth(), MapSentinelProfile(), MapSentinelPasskeys(), MapSentinelFederation(), MapSentinelOidc(), MapSentinelSaml(), MapSentinelScim(), MapSentinelAdmin(), and more. Mount what you need at the prefixes you choose. There are no hosted login pages — login UI belongs to your app; Sentinel gives you headless endpoints and a documented interaction contract for the OIDC authorize flow.

Design commitments

A few positions Sentinel takes deliberately, because identity systems fail at the defaults:

  • Fail closed. Authorization is default-deny with deny-overrides. Signing keys fail fast outside Development if unconfigured. Verification always enforces token typ and audience — type-confusion checks are not opt-in.
  • One evaluation path. List visibility is derived from the same evaluation pass as point checks, so what a user can list can never be broader than what a per-row check would allow.
  • Provably consistent clients. The permission matcher ships in the .NET evaluator and the TypeScript client, and both consume one golden-vector suite — the browser’s can() and the server’s Evaluate cannot silently disagree.
  • Attribution is not authorization. API keys authenticate as the key (subjectId) while attributing to the human owner (credentialOwner), and effective permissions are the owner’s live snapshot ∩ the key’s scopes — demote the owner and every key they minted shrinks with them.
  • Multi-org from day one. A user belongs to one realm and any number of organizations; org context is chosen at token-mint time and carried in the org claim.

Where Sentinel fits

You are Sentinel gives you
Building a .NET SaaS and dreading auth Embedded IdP: login, MFA, passkeys, sessions, orgs, permissions — inside your app
Outgrowing ASP.NET Core Identity A real authorization engine, OIDC server, SCIM, audit — same EF Core habits
Priced out of Duende An MIT-licensed OIDC authorization server with a conformance program
Running Keycloak next to a .NET stack The same capabilities as packages in your process — or the Sentinel Server container if you want the topology you already have
Migrating off Auth0 Importers, foreign-hash coexistence with rehash-on-login, shadow-mode authorization to gate the cutover

For the honest comparison — including where the alternatives are better — see Sentinel vs the alternatives.

Where to go next