Blackwall · www.blackwall.cx
An OAuth 2.1 and OpenID Connect authorisation server where every human signs in with a passkey — and every action leaves a trail that can prove it was not altered.
Blackwall is an authentication service for organisations that want a single, auditable, passwordless front door. It speaks the standards your applications already expect — authorisation code with mandatory PKCE, ID tokens, JWKS, UserInfo, introspection, revocation — and authenticates every user with WebAuthn.
Passwords are not merely discouraged. They cannot be enabled. There is no reset flow to socially engineer, no credential-stuffing surface, and no shared secret sitting in somebody's notes app.
Four decisions that shape everything else about how Blackwall behaves in production.
Every assertion requires both User Present and User Verification. PIN-less authenticators are rejected, and a regressed sign counter is treated as a cloned credential and refused outright.
A single statically linked Go binary over PostgreSQL. No service mesh, no scheduler tier, no daemon zoo — background work runs in goroutines beside the HTTP server. The schema migrates itself on start-up.
Three admin roles, per-request scope computed from organisation membership, and an approval workflow for sensitive mutations. An out-of-scope URL returns 403 rather than 404, so guessing is a deliberate signal.
The audit log is SHA-256 chained under a transaction-scoped lock, so concurrent writes serialise and tampering is detectable. Exports finish with an HMAC-signed manifest line.
An identity provider, an administration console, a licensing service and a secure-sharing tool — all in the same deployment, all under the same audit trail.
Standards
Authorisation code with mandatory PKCE (S256), refresh tokens that are single-use with token-family revocation, and ID tokens carrying at_hash, auth_time and enforced max_age reauthentication.
Authentication
CBOR and COSE attestation parsed and checked in-process, ES256 and RS256 supported, platform authenticators, roaming security keys and synced passkeys all welcome.
Claims
Custom OIDC claims merged at four layers — organisation, project, user, and user within a project — landing in every ID token and UserInfo response without a bespoke integration.
Administration
Organisations, projects, privilege ladders and per-user assignments, with super-admin, operator and auditor roles — and an approval workflow standing between an operator and anything sensitive.
Licensing
Ed25519-signed licence envelopes bound to an exact hostname, issued to a person or a business, carrying feature and instance claims — with online verification, revocation and key rotation built in.
CryptBin
End-to-end encrypted blob storage: payloads are encrypted in the browser with AES-256-GCM, and the server only ever holds ciphertext and a wrapped key it cannot use alone.
Federation
A SAML 2.0 identity provider for legacy applications, SCIM 2.0 provisioning from your HRIS, and outbound webhooks with exponential backoff for everything that needs to react.
Operations
Prometheus-compatible metrics, optional outbound push of every audit event, server-backed sessions, scheduled maintenance jobs and documented backup and recovery.
Automation
A JSON admin API with bearer-token authentication, a Terraform provider, and CI/CD patterns for keeping identity configuration in the same repository as the applications that depend on it.
Self-service
End users manage their own passkeys — add a second device, retire a lost one, see what is enrolled — without an administrator touching a credential or an approval queue filling up with routine work.
Blackwall documents what it implements today, what the known gaps are, and how to run the OIDC conformance suite against your own deployment. We would rather tell you where the edges are than let you discover them during an integration.
The same flow your framework's OIDC client already speaks — with the password step replaced by something that cannot be phished.
The user follows a one-time link and registers a passkey. The database stores a hash of the token, never the token itself.
Your application redirects to /oauth/authorize with a PKCE challenge. Blackwall asks for the passkey; the authenticator asks for the finger, face or PIN.
The code is exchanged at /oauth/token for an access token and an ID token — with your custom claims already merged in from all four layers.
Every step lands in the chained audit log. Months later, an auditor can export it, verify the chain and see exactly who did what and who approved it.
01You want passwords gone, not merely behind a second factor.
02Your auditors want proof the log was not edited afterwards.
03You ship licensed software and need signed, revocable entitlements.
04You are paying per-user rates for an identity platform you barely use.
05You need a SAML shim for one stubborn legacy application.
06You would rather run one binary than operate a fleet of services.
They authenticate with another enrolled passkey and retire the lost one from the portal themselves. Where no second credential exists, an administrator issues a fresh one-time enrolment link — a capability that is itself gated and audited, rather than a quiet reset.
No. Blackwall speaks standard OAuth 2.1 and OpenID Connect, so most frameworks need a client ID, a secret and a discovery URL. The manual carries worked examples for Node with Express, Python with Flask, PHP, Go and a vanilla-JavaScript single-page app, plus guidance on choosing between server-side, SPA and backend-for-frontend patterns.
A single Go binary, or the supplied container image, against PostgreSQL 14 or later. TLS terminates at a reverse proxy you already run; reference nginx and Apache configurations and a systemd unit are included. An empty database is fine — the baseline schema installs itself on first start.
Entries are SHA-256 chained, each committing to the one before it, written under a transaction-scoped advisory lock so concurrent writes serialise correctly. Alter a row and the chain no longer verifies. CSV exports end with an HMAC-signed manifest line, and periodic checkpoints give you fixed points to verify against.
Yes — that is what project licences are for. Licences are Ed25519-signed envelopes bound to an exact hostname and carrying your feature and instance claims. There is a normative verification guide with PHP, Go, Rust and Java examples, and it is emphatic on one point: decoding a licence is never the same as verifying it.
Independent products, built because they should exist.
4ensics Leviathan
A complete binary analysis, reverse-engineering and digital-forensics workbench, running inside a browser tab with your artefacts kept local.
See LeviathanFury
Hybrid lattice key agreement, identities that cannot be written unprotected, and files that stay private long after today's cryptography stops being enough.
See FuryTell us about your applications, your users and the audit obligations you are working to — we will tell you honestly whether Blackwall is the right fit.
[email protected]