Sigra

Production-minded authentication for Phoenix 1.8+ — sessions, passwords, email flows, OAuth, MFA, passkeys, optional organizations and admin tooling — without treating security-sensitive code as throwaway scaffolding.

TL;DR

• Problem: Pow does not support Phoenix 1.8+. Rolling your own auth across crypto, sessions, MFA, and OAuth is slow and risky.
• What Sigra is: A library of hardened primitives plus generators that emit normal Phoenix modules into your repo — you patch UX and policy; you mix deps.update the sensitive core.
• When to leave: You want a hosted identity product (Auth0-as-app) or a framework that hides all auth code from the repo entirely — different tradeoffs.

Pick your lane

Use this in production

Sigra v1.20.0 marks the project's General Availability. The authentication primitives have been proven through extensive automated testing and documented security attestations.

1. Add {:sigra, "~> 1.20"} to your mix.exs.
2. Follow Getting started to generate your host application's auth surface.
3. Review the Production checklist for scheme, cookies, LiveView origins, and mail delivery posture.

For production confidence and audit evidence:

• v1.20 GA evidence: Comprehensive User Acceptance Testing results and deployment artifacts.
• Phase 9 C-1 PASS attestation: Proof of audit atomicity for all major auth actions.

Milestone planning (maintainers): Product north star and scope boundaries for GSD live in .planning/PROJECT.md under North Star (milestones) (with Core Value and Out of Scope).

Where code lives

flowchart LR
  subgraph SigraPkg [Sigra_hex_package]
    directionTB
    LibCore[Crypto_tokens_MFA_OAuth_plugs]
    LibBehaviours[Behaviours_and_options]
  end
  subgraph HostRepo [Your_application]
    directionTB
    GenCtx[Generated_contexts_schemas]
    GenWeb[Generated_routes_LiveViews]
  end
  SigraPkg -->|"call_into_Sigra"| GenCtx
  SigraPkg -->|"call_into_Sigra"| GenWeb
  GenWeb -->|"you_edit_copy_and_policy"| GenWeb

• Left: ships on Hex; security fixes ride mix deps.update.
• Right: plain Elixir under lib/my_app/ and lib/my_app_web/ — code review and product iteration happen there.

First integration

flowchart TD
  A[mix_deps_get]
  B["mix_sigra_install_Context_Schema_table"]
  C[mix_ecto_migrate]
  D[mix_phx_server]
  A --> B --> C --> D

1. Dependency (mix.exs):

   {:sigra, "~> 0.2"}

2. Scaffold (from app root; names must match your domain):

   mix deps.get
   mix sigra.install Accounts User users
   

3. Database + run:

   mix ecto.migrate
   mix phx.server
   

Branching installer flags (--no-live, --admin, --api, …) are summarized below; every switch and default is documented in source (lib/mix/tasks/) and, when published, on HexDocs alongside the API reference.

Prerequisites

Installer at a glance

What ships in the box

One clause each — depth lives in HexDocs and the guides linked in the next section.

Topic map → guides

Security posture (headlines)

For threat-model detail and per-flow guarantees, use HexDocs and the guides above — the README stays a map, not a spec.

Release evidence (maintainers and auditors)

Sigra keeps an evidence hub (what we ran versus waived for GA cuts, how CI maps to human UAT rows, and pointers to planning artifacts on GitHub). That material is not a compliance certificate for your application — integration and deployment risk stay with the host.

• GA evidence and audit posture — router page; same content ships on HexDocs.
• UAT versus CI coverage — machine versus human boundaries.

Coordinated disclosure: SECURITY.md.

Reference host: test/example

The test/example tree is a real Phoenix app living inside this repo: it tracks what mix sigra.install (and friends) emit, compiles under --warnings-as-errors in CI, and backs Playwright browser smoke (golden path, org flows, admin checkpoints, GA shift-left specs). It is not a second product — it is the executable contract that installer drift tests and reviewer artifacts refer to. When in doubt about “what does the generator actually produce?”, read that tree or the HexDocs task reference.

Contributing & issues

• Workflow & CI — CONTRIBUTING.md (Playwright artifacts, installer audit jobs, Pages mirror).
• Local parity — CLAUDE.md on GitHub (Postgres one-liner, mix test expectations).
• Bugs & ideas — GitHub Issues.

License

MIT — see LICENSE.