Open source · MIT code · CC-BY 4.0 spec
The design tool for authentication flows
Login and sign-up flows get sketched in whiteboards and generic diagram tools. These boxes don't know what an MFA challenge is, can't be checked, and usually drift from what ships. Authprint is a canvas editor that speaks auth natively, backed by a typed DSL. Your flow is data that validates itself, not a drawing.
Auth flows deserve better than generic boxes and arrows
Everyone in the room redraws the same flow: the PM in slides, the architect on a whiteboard, the engineer in a wiki that's stale by Friday. None of those drawings can answer the questions that matter. What happens when the OTP fails? Does every path reach an outcome? Authprint treats a flow as what it really is: a typed, auth-aware state machine.
Auth-native, not generic
Screens, decisions, actions and outcomes, with the auth vocabulary built in: identifier-collect, mfa-challenge, passkey-enroll. The words practitioners actually say, not the words a spec author writes.
Flows are data
The canvas is one view of the flow, not the artifact. Underneath is a portable, diff-friendly DSL you can commit, review and generate from; layout stays out of the semantics.
Checked, not executed
Structural validation catches dead ends and missing error paths as you draw. Scenario walk-throughs replay a user's journey step by step against the model, before anyone writes code.
A flow you can read, review and version
Every flow serializes to a .authprint file: strict YAML with a
typed schema. The goal is to make the authentication flow itself a first-class
artifact that lives in your repo, shows up in PR diffs, and round-trips through
any tool that speaks the spec.
- Typed, auth-aware state machine Six structural node types with open "kind" tags: closed enough to validate, open enough to model your stack.
- Scenarios are part of the flow Expected journeys ship in the same file and are checked against the model. A test suite for a flow that doesn't exist yet.
- Semantics stay clean Node positions live in a separate layout layer, so the diff your reviewer reads is purely about behavior.
nodes:
- type: screen
id: s-passkey
name: Sign in with passkey
kind: passkey-auth
fields:
- name: passkey
type: passkey
required: true
- type: decision
id: d-user-exists
kind: user-exists
predicate:
slot: user.exists
op: equals
value: true
# expected journeys ship with the flow
scenarios:
- name: Returning user signs in with a passkey
initialContext:
user.has_passkey: true
expectedOutcome:
outcomeId: o-authenticatedDirect manipulation, with the rules built in
Nobody wants to hand-write YAML to move a box. The editor is the daily surface: draw flows by dragging from handles, and the canvas only offers connections the model allows. An action node won't let you forget its error path. Validation runs live, scenarios replay on the canvas, and screens render as real mockups with your flow's own branding.
- Valid by construction Typed edges and per-handle affordances; unconnected handles double as a completeness signal.
- Scenario walk-throughs Step through a journey in read-only mode; divergence from the expected path shows up in red.
- Everything is ⌘K away One command palette for navigation, examples, patterns, themes and export. No menu spelunking.
- Private by architecture
Flows open and save as
.authprintfiles on your machine. No account, no cloud storage, no tracking: nothing leaves your browser.
The editor and the DSL are yours
The whole toolchain is open: the canvas editor and the parser/validator library under MIT, the DSL specification under CC-BY 4.0. Self-host it, fork it, build codegen or linters on the spec. A Dockerfile ships in the repo.
Alejo Fernandez
Engineer turned product manager in the identity industry. After years of watching login flows get designed in tools that don't understand them, Authprint is his answer: built independently, in the open, as the tool he wished every identity team had.