SESAME Download

Identity your application owns. Not a server you have to trust.

SESAME is a headless authentication and authorization engine. It opens no port and ships no UI — your application owns every listener and drives the engine over a versioned protocol on stdin and stdout. Sessions, tokens, policy, and audit stay inside your own stack, in any of 10 languages.

go install github.com/d31ma/sesame/cmd/sesame@latest copy
✓ No network listener ✓ One direct dependency ✓ Default deny, always ✓ Apache-2.0
84
protocol operations
10
language SDKs
1
direct dependency
0
ports opened
What it does

One place for who, what, and why.

Principals, credentials, sessions, tokens, policy, and audit — with the decision boundary in the same engine as the identities it decides about.

Authenticate

Passkeys first, passwords properly

WebAuthn passkeys with sign-counter clone detection, Argon2id passwords with a parameter-upgrade path, TOTP, and single-use recovery codes. A code is spent durably, so a replay fails inside its own window and across a restart.

Authorize

Decisions you can explain

Default deny over roles, grants, groups, and bounded context conditions. Every decision returns a stable reason and the policy version it was made under, so an audit answers "why" and not just "no".

Single sign-on

OIDC provider, with PKCE mandatory

Authorization code flow, rotating refresh families that revoke the whole family on reuse, discovery, introspection, revocation, consent, and RP-initiated logout. There is no grant-types field, so implicit and password can never be switched on.

Federate

Inbound OIDC and SAML 2.0

Bring identities from an existing provider. SAML verification refuses every ambiguous document rather than choosing between readings, which is what defeats signature wrapping.

Provision

SCIM 2.0 users and groups

A directory can create, patch, and deprovision principals and group membership. Reconciliation is idempotent, because directories re-send full state rather than diffs.

Account for

A ledger, not a log file

Every security-relevant change is a hash-chained event on FYLO. Projections are rebuildable, snapshots are verified, and revocation survives a restart with a defined propagation bound.

How it fits

A subprocess, not a service.

Most identity servers ask you to run one more thing on the network and trust it with your users. SESAME is a binary your application starts. It has no listener to expose, no admin console to leak, and no origin to be confused about.

Your application Owns every listener, TLS boundary, route, and middleware chain. Nothing about that changes.
SDK shim One dependency-free file. Owns the subprocess, timeouts, cancellation, and typed errors — never a security decision.
SESAME engine NDJSON on stdin and stdout. Every protocol decision, every policy evaluation, every audit record.
FYLO Documents are authoritative. Indexes, caches, and projections are derived and rebuildable.

The architecture is enforced, not documented: a test inspects the linked dependency graph of the shipped binary and fails the build if an HTTP package, a template engine, or an unexpected module ever appears in it.

In your language

Ten languages, one engine.

Copy one file into your project. It spawns the engine, speaks the protocol, and gets out of the way. There is no registry to depend on and no lockfile entry to resolve — and with SESAME_DEPLOYMENT set, no path in your code either. 

// SESAME_BINARY and SESAME_DEPLOYMENT come from the environment.
client, err := sesame.Start(ctx, sesame.Options{})
if err != nil {
    log.Fatal(err)
}
defer client.Close()

decision, err := client.Decide(ctx, sesame.DecisionRequest{
    TenantID:    tenantID,
    PrincipalID: principalID,
    Action:      "doc:read",
    Resource:    "project:alpha",
}, nil)

fmt.Println(decision.Decision, decision.ReasonCode)
// deny deny_no_grant
Features

Everything it does. And everything it does not.

A security project that overstates itself is worse than one that ships less. On the left is what exists — each of them with code, negative-path tests, operator documentation, and recovery evidence behind it. On the right is what does not exist yet, written down here rather than left for you to find out in production.

OAuth 2.0 / OIDC provider

Authorization code flow with mandatory PKCE, rotating refresh families with reuse detection, discovery, introspection, revocation, consent, and RP-initiated logout.

Device grant, PAR, and DPoP

RFC 8628 for inputs a browser cannot reach, RFC 9126 to move the authorization request onto an authenticated back channel, and RFC 9449 to bind an access token to a key its holder proves per request.

Authentication

Argon2id passwords with a parameter-upgrade path, TOTP with durable replay prevention, single-use recovery codes, and WebAuthn passkeys with clone detection.

Authorization

Deterministic default-deny decisions over roles, grants, groups, and bounded context conditions, with stable reasons and a versioned policy snapshot.

Federation and provisioning

Inbound OIDC federation, SCIM 2.0 users and groups, and inbound SAML 2.0 with an in-tree XML canonicalizer that refuses every ambiguous document.

Durability

A hash-chained security ledger on FYLO with rebuildable projections, verified snapshots, and restart evidence run against a real FYLO runtime.

Ten drop-in clients

One dependency-free file per language, each holding the whole operation surface. A contract test resolves every operation against every shim, so a capability cannot ship in one language and quietly miss another.

OpenID certification

The provider surface is driven over real TLS by a relying party in test/interop — discovery, PKCE, ID-token claims, single-use codes. Certification is self-certification against the OpenID Foundation suite, and that submission has not been made, so SESAME is not certified.

SAML interoperability

Proven end to end against a real Keycloak in test/interop — which is how a namespace defect no fixture had ever produced was found and fixed. Okta, Entra ID, Google Workspace, and Shibboleth are still unproven; treat any provider not listed as untested.

Production support

This is a developer preview. A repeatable restore, upgrade/rollback, and soak evidence runner exists, but no release has passed its 72-hour native gate or an independent security review. No version is supported for production use.

Every attack case in SESAME's adversarial suite runs against a real compiled binary over the shipped protocol, against a real deployment with real keys — because a defence that only exists inside a package boundary is not a defence.

Read the code before you trust it.

SESAME is Apache-2.0 and every security claim on this page points at a test you can run. Start with the project plan — it records what is proven, what is deliberately not, and why.

← Docs Guide

Authorization

Default deny over roles, grants, groups, and bounded conditions. Every answer carries a stable reason and the policy version it was decided under, so an audit can say why and not just no.

Asking a question

A decision names the tenant, the principal, the action, and the resource. Nothing is implied: with no matching grant, the answer is deny with deny_no_grant. 

# Default deny: without a matching grant this is a refusal.
decision = client.decide({
    "tenant_id": tenant_id,
    "principal_id": principal_id,
    "action": "doc:read",
    "resource": "project:alpha",
})
# {"decision": "deny", "reason_code": "deny_no_grant", "policy_version": 4}

Actions and resources are opaque strings that you choose. The convention in the examples — doc:read on project:alpha — is only a convention; SESAME never parses them for meaning, which is what keeps your model out of its vocabulary.

Granting

Create an immutable role, then grant it. A role's permissions are action–resource pairs, and either side may be the wildcard *. 

# A role is immutable: changing what it means in place would silently
# rewrite the meaning of every grant pointing at it.
role = client.role_create(tenant_id, "editor", [
    {"action": "doc:read", "resource": "project:*"},
    {"action": "doc:write", "resource": "project:alpha"},
])

grant = client.grant_create(tenant_id, principal_id, role["role_id"])

# Revoking is immediate and durable; the next decision reflects it.
client.grant_revoke(grant["grant_id"])

A wildcard matches one segment or the whole value, and it never matches across a boundary you did not write — project:* covers project:alpha, not projectile.

Groups

Grant a role to a group and every member inherits it. Membership is resolved at decision time, so adding someone to a group takes effect on their next request rather than their next login. 

group = client.group_create(tenant_id, "engineering")
client.group_member_add(group["group_id"], principal_id)

# Grants attach to the group exactly as they attach to a principal.
client.grant_create(tenant_id, group["group_id"], role["role_id"])

# An allow through a group is reported as such, not as a role grant.
# {"decision": "allow", "reason_code": "allow_group_grant", ...}

The reason distinguishes allow_role_grant from allow_group_grant deliberately: when you are working out why someone has access they should not have, the difference between a direct grant and an inherited one is the whole question.

Conditions

A permission may carry equality conditions on context. The caller supplies context with the request; every condition must match for the permission to apply. 

role = client.role_create(tenant_id, "regional-editor", [{
    "action": "doc:write",
    "resource": "project:*",
    "conditions": {"region": "eu"},
}])

decision = client.decide({
    "tenant_id": tenant_id, "principal_id": principal_id,
    "action": "doc:write", "resource": "project:alpha",
    "context": {"region": "eu"},
})

Two refusals are worth telling apart. A supplied value that does not match denies with deny_no_grant — from the caller's side that is simply no applicable grant. An attribute that was never supplied denies with deny_missing_context, and that code names the missing attribute only when every value you did supply already matched. Naming it otherwise would be false advice: it would suggest adding a key that still would not grant access.

Trusted context, and why you cannot supply it

Some context is too important to accept from the caller. Pass a session instead of a principal and the engine verifies it and derives context itself under the reserved session. prefix — currently session.assurance. 

# Pass the session instead of a principal. The engine verifies it and
# derives context under the reserved "session." prefix, so a caller cannot
# assert its own assurance level.
decision = client.decide({
    "tenant_id": tenant_id,
    "session_id": session["session_id"],
    "session_secret": session["session_secret"],
    "action": "billing:change",
    "resource": "account:acme",
})
# A permission conditioned on session.assurance == "mfa" denies a
# password-only session with reason_code "deny_no_grant".

A caller-supplied key beginning with session. is rejected, not ignored. That refusal is the whole reason the condition is worth trusting: if the engine quietly dropped such a key, a caller could not tell whether its own value had been used. An unusable session denies with deny_session_invalid.

All ten SDKs can express this. Python, Node.js, and Go take a request object, so a session is just another key; the other seven carry a named decideForSession beside their positional decide. A contract test asserts every shim can reach the capability, because a shim that cannot is the same kind of drift as a missing operation.

Batches and repeatability

Rendering a page usually means asking many questions at once. A batch answers them under a single policy version, so a policy change mid-render cannot produce a half-old, half-new page. 

decisions = client.decide_batch([
    {"tenant_id": t, "principal_id": p, "action": "doc:read", "resource": "project:alpha"},
    {"tenant_id": t, "principal_id": p, "action": "doc:write", "resource": "project:alpha"},
])

# Pin an earlier version to reproduce a past answer exactly.
replay = client.decide(request, policy_version=4)

Where to enforce

SESAME decides; your application enforces. A decision is advice until your code acts on it, and the engine cannot stop a handler that never asked. Put the call at the boundary that owns the resource — not in a UI layer, which only controls what is offered rather than what is reachable.

What to read next