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

Before production

Public HTTPS hosts need aligned origins, proxy-forwarded TLS, session cookies, and a deliberate mail-delivery posture before you take real traffic. Treat the deployment recipe as the single checklist hub — skim it once per environment.

• Production checklist (read first) — scheme, cookies, LiveView origins, staging parity.
• Mail: inline vs Oban (TL;DR) — when background delivery is worth the operational cost.

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, "~> 1.0"}
   

   This is the selected 1.0 contract line. If Hex package metadata advertises a newer installable line, treat Hex as the current package truth and use the version constraint appropriate for your target. For version, stack, ownership, and non-goal boundaries, read the Sigra 1.0 contract.

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, SECURITY.md, and the Sigra 1.0 contract for the full invariants and non-goals — 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.

• Sigra Hex 1.0.0 launch announcement — canonical launch narrative, audience guidance, proof links, and first-14-day triage pointer.
• Sigra alternatives comparison — boundary-first comparison against phx.gen.auth, Pow/Guardian/Ueberauth-style composition, hosted auth, and Sigra's hybrid model.
• Sigra launch evidence bundle — attachable release proof router with post-publish placeholders and proof boundaries.
• 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.