@opengroundplan/core 0.1.1

package/catalog/sources/auth.yaml

@@ -0,0 +1,618 @@
+# Groundplan template source catalog — category: auth
+#
+# Research date: 2026-07-18
+# Adversarially re-verified: 2026-07-18
+#
+# Verification method (the GitHub REST API quota was exhausted for this IP, so every
+# fact below comes from a stronger or equivalent primary source instead):
+#   license     — the repository's own LICENSE / LICENSE.md / LICENSING.md file fetched
+#                 at HEAD from raw.githubusercontent.com. This is the authoritative text,
+#                 not the API's heuristic spdx_id guess.
+#   stars       — exact count from the repository page star counter.
+#   lastCommit  — the latest commit on the DEFAULT BRANCH, from the repository page.
+#                 Note this is deliberately stricter than the API's `pushed_at`, which is
+#                 bumped by pushes to any branch and so overstates activity.
+#   archived    — repository page checked for the "Public archive" banner. None are archived.
+# All `approx` flags from the previous pass were resolved to exact verified values.
+#
+# licenseClass gate:
+#   vendorable      MIT, Apache-2.0, BSD-2/3, ISC, Unlicense, CC0, 0BSD — copy + adapt,
+#                   carrying the NOTICE/attribution where Apache-2.0 or BSD requires it.
+#   reference-only  MPL-2.0, LGPL, EPL, or split/unclear licensing — read for ideas, do not copy files.
+#   excluded        GPL/AGPL/SSPL/BUSL/source-available/unlicensed — never copy.
+
+category: auth
+
+sources:
+  # ---------------------------------------------------------------- simple
+  - name: lucia-auth/lucia
+    url: https://github.com/lucia-auth/lucia
+    stack: typescript
+    complexity: simple
+    stars: 10460
+    spdx: MIT AND 0BSD
+    licenseClass: vendorable
+    licenseNotes: >-
+      CORRECTED. The previous pass recorded `0BSD` and claimed the API reported it; the repo
+      has NO root LICENSE file, so the API cannot report 0BSD and almost certainly returns
+      NOASSERTION. Verified from primary source: two files at HEAD, LICENSE-0BSD and
+      LICENSE-MIT, and the README disclaimer, which reads "All example code in the site is
+      licensed under the Zero-Clause BSD license... Everything else this repository is
+      licensed under the MIT license." Both terms are permissive so the vendorable class
+      still holds, but the split matters in practice: the attribution-free 0BSD grant is
+      scoped to example code shown in the documentation site, NOT to the whole repo. Treat
+      any file you copy as MIT — carry the copyright notice — unless you have confirmed it
+      is site example code.
+    maintained: false
+    lastCommit: "2025-07-13"
+    maintenanceCaveat: >-
+      Last default-branch commit verified as 2025-07-13, roughly 12 months stale. Under the
+      18-month staleness bar, but `maintained: true` was misleading for what is by design a
+      frozen reference implementation, so it is now false. Nothing here is being patched.
+    whatToBorrow: >-
+      Lucia is no longer a library — since March 2025 it is a reference implementation of
+      session auth you copy into your own project, which is exactly what a scaffolder wants.
+      Borrow the session primitive: generate a random token, store only its SHA-256 hash in
+      the `session` table, return the raw token in the cookie, and slide `expires_at` on
+      validation. The example projects carry the full ladder — email/password, email
+      verification, password reset, TOTP 2FA with recovery codes, passkeys/WebAuthn, and
+      login rate limiting — each as plain framework code with no adapter layer to strip out.
+      Copy these as MIT-licensed material and carry the notice; the attribution-free 0BSD
+      grant covers the documentation site's inline snippets, not the example projects.
+      Pair with the author's `oslo` (crypto) and `arctic` (OAuth2 clients, ~50 providers,
+      MIT) for a dependency-light auth layer.
+    whatToAvoid: >-
+      Do not depend on the `lucia` npm package — v3 is formally deprecated and will not get
+      security fixes. The repo is docs plus examples, so there is no upgrade path: you own
+      the code the moment you copy it. Examples pin specific framework versions and will
+      drift. `pushed_at` is 2025-07-13, roughly 12 months stale — fine for a frozen learning
+      resource, but it means nobody is patching the examples for you.
+    proposedLayerIds:
+      - auth-session-cookie-scratch
+      - auth-password-argon2
+      - auth-2fa-totp
+      - auth-passkeys-webauthn
+      - auth-oauth-arctic
+
+  - name: MasterKale/SimpleWebAuthn
+    url: https://github.com/MasterKale/SimpleWebAuthn
+    stack: typescript
+    complexity: simple
+    stars: 2286
+    spdx: MIT
+    licenseClass: vendorable
+    licenseNotes: >-
+      MIT verified by reading master/LICENSE.md directly ("MIT License, Copyright (c) 2020
+      Matthew Miller"); single license, no carve-outs.
+    maintained: true
+    lastCommit: "2026-06-24"
+    whatToBorrow: >-
+      The cleanest reference for passkeys as a standalone concern. Two packages:
+      `@simplewebauthn/server` (generateRegistrationOptions / verifyRegistrationResponse /
+      generateAuthenticationOptions / verifyAuthenticationResponse) and
+      `@simplewebauthn/browser` (startRegistration / startAuthentication). Borrow the
+      four-endpoint ceremony shape, the credential table columns it implies (credentialID,
+      publicKey, counter, transports, backed-up flag), and the challenge-in-session pattern.
+      Runs on Node, Deno, Bun and edge runtimes, so one passkey layer serves every JS target.
+    whatToAvoid: >-
+      It is deliberately only WebAuthn — no sessions, no users, no account recovery. Shipping
+      it as the sole factor strands users who lose their authenticator, so any template using
+      it must also scaffold a fallback factor. RP ID and origin are environment-specific and
+      are the most common misconfiguration; they must be config values, never literals.
+    proposedLayerIds:
+      # Was three ids splitting one concern into server/browser halves — those are two
+      # packages of a single layer, not two selectable layers. Collapsed.
+      - auth-passkeys-webauthn
+
+  - name: casbin/casbin
+    url: https://github.com/casbin/casbin
+    stack: go
+    complexity: simple
+    stars: 20255
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    licenseNotes: >-
+      Apache-2.0 verified by reading master/LICENSE directly. CORRECTION: the previous pass
+      called this "an Apache Software Foundation project" — it is not. Casbin is an
+      independent project under its own GitHub org that happens to use the Apache-2.0
+      license; no ASF governance, incubation or trademark relationship exists, and the
+      README makes no such claim. The licence itself is unaffected: Apache-2.0 still
+      requires shipping the attribution/NOTICE with any copied file.
+    maintained: true
+    lastCommit: "2026-06-23"
+    whatToBorrow: >-
+      The `examples/` directory is the payload, not the Go code: model.conf + policy.csv
+      pairs that encode every common authorization shape as data you can drop into a
+      template — `basic_model`, `rbac_model`, `rbac_with_domains` (multi-tenant, the one
+      most SaaS templates need), `rbac_with_deny`, `abac_rule_model`, `keymatch`/`keymatch2`
+      (URL path matching for API routes), `priority_model`, `rebac_model`, `ipmatch`.
+      Casbin has first-party ports for Go, Node, Python, Java, .NET, PHP and Rust, so the
+      same policy files ride along whichever backend layer the user picks.
+    whatToAvoid: >-
+      The PERM model config is its own DSL with real learning cost and poor error messages;
+      for a simple role check it is heavier than an enum. Policy stored in CSV does not scale
+      — production needs a database adapter, and adapter quality varies sharply by language
+      port. Ecosystem sprawl (dozens of casbin-* org repos) means many satellite adapters are
+      stale even though core is not. For relationship-based authorization, OpenFGA is the
+      better modern choice.
+    proposedLayerIds:
+      - authz-casbin-rbac
+      - authz-casbin-rbac-domains
+      - authz-casbin-abac
+      - authz-policy-model-files
+
+  - name: oauth2-proxy/oauth2-proxy
+    url: https://github.com/oauth2-proxy/oauth2-proxy
+    stack: go
+    complexity: simple
+    stars: 14679
+    spdx: MIT
+    licenseClass: vendorable
+    licenseNotes: MIT verified by reading master/LICENSE directly.
+    maintained: true
+    lastCommit: "2026-06-09"
+    whatToBorrow: >-
+      The "add SSO without touching the app" layer. Borrow `contrib/oauth2-proxy.cfg.example`
+      as the config template, `contrib/oauth2-proxy.service.example` for bare-metal systemd
+      deploys, and `contrib/local-environment/` for the compose wiring that fronts an
+      upstream service with an OIDC provider. The forward-auth / auth_request pattern it
+      encodes (reverse proxy calls the auth endpoint, injects X-Forwarded-User and friends)
+      is the right default for protecting internal tools and any non-JS backend.
+    whatToAvoid: >-
+      Header-based identity is only safe if the upstream is unreachable except through the
+      proxy — templates must bind the app to localhost or a private network or the auth is
+      trivially bypassed. Provider-specific quirks (Azure, Keycloak group claims) live in
+      flags that change between minor versions, so pin the image tag. The legacy vs `alpha`
+      config formats are both live and mutually confusing; pick one per template.
+    proposedLayerIds:
+      - auth-proxy-oauth2-proxy
+      - auth-forward-auth-nginx
+      - auth-sso-sidecar
+
+  # -------------------------------------------------------------- standard
+  - name: better-auth/better-auth
+    url: https://github.com/better-auth/better-auth
+    stack: typescript
+    complexity: standard
+    stars: 29222
+    spdx: MIT
+    licenseClass: vendorable
+    licenseNotes: >-
+      MIT verified by reading main/LICENSE.md directly, and packages/better-auth/package.json
+      also declares MIT — root and package licence agree, no monorepo split.
+    maintained: true
+    lastCommit: "2026-06-29"
+    whatToBorrow: >-
+      The default recommendation for any new TypeScript project in 2026, and the richest
+      single source in this category. Borrow the plugin composition model from
+      `packages/better-auth/src/plugins/` — 28 first-party plugins that map almost
+      one-to-one onto Groundplan layers: `organization` (multi-tenant orgs, roles, invitations),
+      `two-factor`, `admin`, `magic-link`, `email-otp`, `phone-number`, `jwt`,
+      `oidc-provider` (be your own IdP), `device-authorization`, `multi-session`,
+      `generic-oauth`, `haveibeenpwned` (breached-password rejection), `access`
+      (permission statements), `mcp`. Also borrow the adapter shape (Drizzle/Prisma/Kysely/
+      raw pg + Mongo) and the `@better-auth/cli generate` flow that emits DB schema from the
+      auth config — the schema stops being hand-maintained. `demo/nextjs` is a working
+      end-to-end reference app.
+    whatToAvoid: >-
+      Fast-moving: a very high release cadence and frequent minor-version breaking changes to
+      plugin APIs, so templates must pin an exact version and the generated schema must be regenerated on
+      upgrade. The plugin surface invites over-adoption — scaffolding ten plugins by default
+      produces tables and endpoints nobody uses. Secrets and base URL must come from config;
+      the docs' inline `baseURL` examples are the exact hardcoding pattern to avoid.
+    proposedLayerIds:
+      - auth-better-auth
+      - auth-better-auth-drizzle
+      - auth-better-auth-prisma
+      - auth-better-auth-organization
+      - auth-better-auth-2fa
+      - auth-better-auth-passkeys
+      - auth-better-auth-magic-link
+      - auth-better-auth-oidc-provider
+      - auth-better-auth-admin
+
+  - name: nextauthjs/next-auth
+    url: https://github.com/nextauthjs/next-auth
+    stack: typescript
+    complexity: standard
+    stars: 28309
+    spdx: ISC
+    licenseClass: vendorable
+    licenseNotes: >-
+      ISC verified by reading main/LICENSE directly ("ISC License, Copyright (c) 2022-2024,
+      Balázs Orbán"). Spot-checked packages/core, packages/next-auth and packages/adapter-*
+      package.json — all declare ISC, so the monorepo is uniformly licensed. ISC is
+      permissive and functionally equivalent to MIT/BSD-2 for vendoring.
+    maintained: true
+    lastCommit: "2026-04-14"
+    maintenanceCaveat: >-
+      SOFTENED — the previous pass asserted a specific date and a "security-patch only, no
+      non-security bug fixes" policy that no primary source states. What is verified: the
+      repo README carries the banner "Auth js is now part of Better Auth. We recommend new
+      projects to start with Better Auth unless there are some very specific feature gaps
+      (most notably stateless session management without a database)." Corroborating signal:
+      the last default-branch commit is 2026-04-14, about three months before this review,
+      which is slow for a repo of this size. Treat the project as low-velocity and
+      upstream-deprecated in favour of Better Auth; do not assert a formal support policy.
+    whatToBorrow: >-
+      The most valuable asset is data, not runtime: `packages/core/src/providers/` holds 80+
+      hand-maintained OAuth/OIDC provider configs (endpoints, scopes, profile-claim mapping)
+      that are tedious to write and easy to lift. Also borrow the 24 `adapter-*` packages
+      (drizzle, prisma, kysely, pg, mongodb, dynamodb, d1, neon, supabase, upstash-redis,
+      unstorage…) — the canonical user/account/session/verificationToken table shape they
+      share is the de facto schema the whole JS ecosystem understands, including Better Auth
+      migrations. `frameworks-express`, `frameworks-sveltekit`, `frameworks-solid-start` and
+      `frameworks-qwik` show the same core adapted per framework.
+    whatToAvoid: >-
+      Do not make this the default for new projects — the README's own banner points new work
+      at Better Auth. v5 sat in beta for years and much published tutorial
+      content targets an incompatible v4. The JWT-session default means no server-side
+      revocation, which surprises teams later. Treat it as an inheritance/migration target
+      and a provider-config quarry rather than a growth path.
+    proposedLayerIds:
+      - auth-authjs-nextjs
+      - auth-authjs-sveltekit
+      - auth-authjs-express
+      - auth-oauth-provider-configs
+      - auth-schema-authjs-compatible
+
+  - name: supabase/auth
+    url: https://github.com/supabase/auth
+    stack: go
+    complexity: standard
+    stars: 2498
+    spdx: MIT
+    licenseClass: vendorable
+    licenseNotes: >-
+      MIT verified by reading master/LICENSE directly ("Copyright (c) 2021-2025 Supabase").
+      Supabase's fork of Netlify GoTrue.
+    maintained: true
+    lastCommit: "2026-07-13"
+    whatToBorrow: >-
+      The self-hostable auth server behind Supabase, and the only credible way to get
+      Supabase-shaped auth without the SaaS. Borrow `migrations/` (the `auth` schema:
+      users, identities, sessions, refresh_tokens, mfa_factors — a battle-tested Postgres
+      identity schema you can adopt wholesale), `example.env` / `example.docker.env` as the
+      config surface, and `docker-compose-dev.yml` for local wiring. The JWT claim shape
+      (`sub`, `role`, `aud`, `app_metadata`, `user_metadata`) is what Postgres RLS policies
+      key off, so adopting it buys row-level security for free.
+    whatToAvoid: >-
+      Strongly coupled to Postgres and to Supabase conventions — the GoTrue name is now
+      misleading since it has diverged far from Netlify's original. Self-hosting means owning
+      SMTP, SMS, rate limiting and CAPTCHA configuration yourself; several features are
+      tested primarily against Supabase's hosted stack. Configuration is entirely env-var
+      driven with a large surface, so the template must ship a validated env schema rather
+      than a copied example file.
+    proposedLayerIds:
+      - auth-supabase-selfhost
+      - auth-gotrue-postgres
+      - db-postgres-rls-auth
+      - auth-jwt-claims-supabase
+
+  - name: panva/node-oidc-provider
+    url: https://github.com/panva/node-oidc-provider
+    stack: node
+    complexity: standard
+    stars: 3775
+    spdx: MIT
+    licenseClass: vendorable
+    licenseNotes: MIT verified by reading main/LICENSE.md directly.
+    maintained: true
+    lastCommit: "2026-07-07"
+    whatToBorrow: >-
+      OpenID Certified™ authorization server you can embed in a Node app — the right answer
+      when the template needs to *issue* tokens rather than consume them. `example/` ships
+      three deployment shapes to lift directly: Koa-embedded, Express-embedded, and fully
+      standalone, plus `my_adapter.js` (the storage adapter contract), `views/` (consent and
+      login screens) and `routes/`. Borrow the interaction/consent flow split and the JWKS +
+      client-registration configuration block; it is the most correct small OIDC reference in
+      the JS ecosystem.
+    whatToAvoid: >-
+      Spec-completeness over ergonomics — the configuration object is large and unforgiving,
+      and it deliberately ships no user store, no login UI and no account model, so a
+      template must supply all three. The default in-memory adapter loses everything on
+      restart and must never survive into a generated production template. Being an IdP is a
+      serious security commitment; most projects should consume an IdP instead.
+    proposedLayerIds:
+      - auth-oidc-provider-node
+      - auth-oidc-provider-express
+      - auth-oidc-provider-koa
+      - auth-jwks-rotation
+
+  # ---------------------------------------------------------- professional
+  - name: ory/kratos
+    url: https://github.com/ory/kratos
+    stack: go
+    complexity: professional
+    stars: 13768
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    licenseNotes: >-
+      Apache-2.0 verified by reading master/LICENSE directly — no Ory-license carve-out in
+      this repo. Carry the attribution/NOTICE with any copied file.
+    maintained: true
+    lastCommit: "2026-03-20"
+    maintenanceCaveat: >-
+      Last default-branch commit 2026-03-20 — about four months before this review. Well
+      inside the 18-month staleness bar, but slower than the previously recorded 2026-07-17,
+      which reflected a push to a non-default branch rather than mainline development.
+    whatToBorrow: >-
+      Headless identity management — the API-first alternative to bolting auth into the app.
+      Borrow `contrib/quickstart/kratos/email-password/kratos.yml` (self-service flow config:
+      registration, login, recovery, verification, settings, with per-flow lifespans and
+      after-hooks) and `identity.schema.json` — declaring the identity model as JSON Schema,
+      with traits marked as credential identifiers, is a pattern worth adopting even outside
+      Kratos. `contrib/quickstart/` also wires Oathkeeper as the request-level authorization
+      proxy. The self-service UI-node JSON contract (server returns form nodes, your UI
+      renders them) is what makes one backend serve web, mobile and CLI clients.
+    whatToAvoid: >-
+      Kratos does identity only — no OAuth2 issuance (that is Hydra), no policy decisions
+      (Keto/Oathkeeper), so a real deployment is three or four services and the operational
+      floor is high for a small team. You must build and host the self-service UI yourself;
+      the reference UI is a separate repo. Ory's cloud offering shapes roadmap priorities,
+      and some conveniences are easier in Ory Network than self-hosted.
+    proposedLayerIds:
+      - auth-ory-kratos
+      - auth-ory-kratos-compose
+      - auth-identity-schema-json
+      - auth-selfservice-flows
+      - authz-ory-oathkeeper
+
+  - name: ory/hydra
+    url: https://github.com/ory/hydra
+    stack: go
+    complexity: professional
+    stars: 17407
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    licenseNotes: Apache-2.0 verified by reading master/LICENSE directly; no carve-out.
+    maintained: true
+    lastCommit: "2026-03-20"
+    maintenanceCaveat: >-
+      Last default-branch commit 2026-03-20. As with Kratos, the previously recorded
+      2026-07-16 was a non-default-branch push, not mainline activity.
+    whatToBorrow: >-
+      A certified OAuth 2.1 / OIDC provider that deliberately owns no users — it delegates
+      login and consent to your app over a documented handshake. Borrow the docker-compose
+      quickstart and, more importantly, the login/consent app contract (`login_challenge` and
+      `consent_challenge` round-trips against the admin API): it is the cleanest separation
+      of "who is this user" from "what token do they get", and it lets a template keep an
+      existing user table while still issuing real OAuth tokens to third parties. Useful when
+      the generated product must expose a public API with client credentials or a partner
+      integration surface.
+    whatToAvoid: >-
+      Pairs with a separate identity service (Kratos or your own), so it is never a complete
+      auth solution on its own — teams routinely underestimate that the login/consent app is
+      code they must write. Admin and public APIs must be on separate networks; exposing the
+      admin API is a total compromise, and it is the most common self-host mistake. Overkill
+      unless third parties actually need tokens.
+    proposedLayerIds:
+      - auth-ory-hydra
+      - auth-oauth2-server
+      - auth-login-consent-app
+      - auth-client-credentials-api
+
+  - name: authelia/authelia
+    url: https://github.com/authelia/authelia
+    stack: go
+    complexity: professional
+    stars: 28318
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    licenseNotes: >-
+      Re-verified: master/LICENSE read directly — plain Apache-2.0, no enterprise carve-out.
+    maintained: true
+    lastCommit: "2026-05-26"
+    whatToBorrow: >-
+      The best single-file example of declarative authorization config: `config.template.yml`
+      covers `access_control` rules (per-domain, per-resource, per-subject policies of
+      bypass / one_factor / two_factor / deny), session config with Redis, storage backends,
+      the notifier (SMTP for verification and reset mail), TOTP + WebAuthn + Duo second
+      factors, password policy, and `regulation` for brute-force lockout. Borrow the whole
+      ACL rule shape and the forward-auth integration snippets for nginx and Traefik — this
+      is the fastest route to "put SSO and 2FA in front of a homelab or internal tool".
+    whatToAvoid: >-
+      It is a portal in front of a reverse proxy, not a library — it cannot secure a single
+      app that has no proxy in front of it, and single-instance deployments are a SPOF for
+      every protected service. The file-based user database is convenient in examples but is
+      not a production identity store (LDAP is the real path). Config keys have moved between
+      releases, so pin the version and never copy a config template without pinning.
+    proposedLayerIds:
+      - auth-authelia-portal
+      - auth-forward-auth-traefik
+      - auth-forward-auth-nginx
+      - authz-access-control-rules
+      - auth-2fa-totp-webauthn
+
+  - name: openfga/openfga
+    url: https://github.com/openfga/openfga
+    stack: go
+    complexity: professional
+    stars: 5451
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    licenseNotes: >-
+      Apache-2.0 verified by reading main/LICENSE directly. The companion
+      openfga/sample-stores repo referenced below was checked separately and is also
+      Apache-2.0, so the borrowed models are safe on the same terms.
+    maintained: true
+    lastCommit: "2026-06-29"
+    whatToBorrow: >-
+      Google Zanzibar-style relationship-based authorization, and the modern answer for
+      anything with sharing, nesting or inherited permissions. Borrow `docker-compose.yaml`
+      (server + Postgres + playground) as the local dev layer, the `.fga` DSL authorization
+      model as a first-class versioned artifact in the repo, and — the underrated part —
+      `.fga.yaml` store tests, which let you unit-test authorization decisions in CI before
+      any app code exists. The sibling `openfga/sample-stores` repo (also Apache-2.0) has
+      ready-made models for GitHub-style repo/org/team permissions, Google Drive-style
+      folder inheritance, Slack workspaces, e-commerce and healthcare.
+    whatToAvoid: >-
+      A separate stateful service on the request path — every permission check is a network
+      call, so templates must scaffold contextual tuples and batch-check usage or latency
+      degrades. Keeping relationship tuples in sync with your primary database is a real
+      dual-write problem the docs gloss over. Genuinely overkill for flat role checks; do not
+      make it the default authorization layer.
+    proposedLayerIds:
+      - authz-openfga
+      - authz-openfga-compose
+      - authz-openfga-model-tests
+      - authz-rebac-zanzibar
+
+  - name: openiddict/openiddict-core
+    url: https://github.com/openiddict/openiddict-core
+    stack: dotnet
+    complexity: professional
+    stars: 5199
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    licenseNotes: >-
+      Apache-2.0 verified by reading master/LICENSE.md directly. The companion
+      openiddict-samples repo was checked separately and is also Apache-2.0. Genuinely free,
+      which is the point — the main .NET alternative, Duende IdentityServer, is commercially
+      licensed (see droppedCandidates).
+    maintained: true
+    lastCommit: "2026-07-15"
+    whatToBorrow: >-
+      The free OAuth 2.0 / OIDC stack for .NET, and the natural companion to ASP.NET Core
+      Identity. `src/` splits cleanly into layers a template can select independently:
+      `OpenIddict.Server` + `.Server.AspNetCore` (issue tokens), `OpenIddict.Validation` +
+      `.Validation.AspNetCore` / `.Validation.ServerIntegration` (protect APIs),
+      `OpenIddict.Client` (+ `.WebIntegration`, `.SystemNetHttp`) for consuming external
+      IdPs, `OpenIddict.EntityFrameworkCore` / `.MongoDb` for stores, and `OpenIddict.Quartz`
+      for token pruning. The companion `openiddict-samples` repo (Apache-2.0) is a
+      flow-per-project catalogue: Velusia and Balosar (authorization code), Zirku
+      (introspection vs local validation), Dantooine (backend-for-frontend), Matty (device
+      flow), Aridka (client credentials over mTLS), Imynusoph (refresh), Mimban (GitHub
+      delegation) — pick the sample matching the layer and adapt it.
+    whatToAvoid: >-
+      Configuration is verbose and unusually opinionated; error messages assume you know the
+      RFCs. Certificates are the trap — development signing/encryption certs must never reach
+      a generated production template, so cert provisioning has to be a config concern from
+      day one. It replaces the token endpoint but not user management, so it still needs
+      ASP.NET Core Identity or an equivalent behind it.
+    proposedLayerIds:
+      - auth-openiddict-server
+      - auth-openiddict-validation
+      - auth-openiddict-client
+      - auth-openiddict-efcore
+      - auth-aspnet-identity-openiddict
+
+  - name: fullstackhero/dotnet-starter-kit
+    url: https://github.com/fullstackhero/dotnet-starter-kit
+    stack: dotnet
+    complexity: professional
+    stars: 6653
+    spdx: MIT
+    licenseClass: vendorable
+    licenseNotes: >-
+      MIT verified by reading main/LICENSE directly ("Copyright (c) 2021-2026 fullstackhero").
+    maintained: true
+    lastCommit: "2026-06-19"
+    whatToBorrow: >-
+      The best worked example of application-level auth in .NET 10 rather than a protocol
+      library. Borrow the JWT issuance + refresh-token rotation pipeline, the fine-grained
+      permission model (permission claims + a policy provider, instead of raw role checks),
+      the rate-limited auth endpoints, password policy and session/impersonation handling,
+      and — the highest-value piece — Finbuckle multitenancy with tenant-isolated
+      `DbContext`s, which is exactly the wiring most teams get wrong. `deploy/` has Docker
+      Compose and Terraform; `clients/` shows the React side consuming the same token flow.
+    whatToAvoid: >-
+      Batteries-included to a fault: modular monolith with vertical slices, Aspire
+      orchestration, multitenancy, billing, webhooks, chat and OpenTelemetry all arrive
+      together, so extracting only the auth layer takes real work. It tracks the newest .NET
+      aggressively, which means churn between major versions. It is a starter kit, not a
+      maintained library — you fork it and own it, and community-starter-kit provenance means
+      the security review is on you.
+    proposedLayerIds:
+      - auth-aspnet-identity-jwt
+      - auth-jwt-refresh-rotation
+      - authz-permission-claims-dotnet
+      - tenancy-finbuckle-multitenant
+      - auth-dotnet-starter-kit
+
+  # ------------------------------------------------------------- enterprise
+  - name: keycloak/keycloak
+    url: https://github.com/keycloak/keycloak
+    stack: java
+    complexity: enterprise
+    stars: 35722
+    spdx: Apache-2.0
+    licenseClass: vendorable
+    licenseNotes: >-
+      Apache-2.0 verified by reading main/LICENSE.txt directly — notable because it is the
+      only full-featured enterprise IdP in this list that is cleanly vendorable (ZITADEL is
+      AGPL-3.0-only, authentik is split-licensed; both re-verified this pass).
+    maintained: true
+    lastCommit: "2026-07-09"
+    whatToBorrow: >-
+      The default when the requirement sheet says SAML, LDAP/AD federation, identity
+      brokering, fine-grained admin delegation or regulated-environment audit. Borrow
+      `quarkus/container/Dockerfile` (the official image build, and the pattern for baking an
+      optimized build at image time rather than starting in dev mode), and above all the
+      realm export JSON — a full realm (clients, roles, scopes, identity providers, flows,
+      required actions) as one importable file is the single most useful artifact for a
+      scaffolder, since it turns "configure your IdP" into a committed file. Custom
+      authentication SPI and the flow builder are the reference for step-up and conditional
+      MFA.
+    whatToAvoid: >-
+      Heavy: JVM, its own database, and meaningful memory floor — disproportionate for a
+      small app. `start-dev` mode appears in every tutorial and must never reach a generated
+      production template. Admin REST APIs and the admin console change shape between major
+      versions, and realm exports are not reliably portable across major upgrades, so pin the
+      version in both image and export. Theming for a branded login page is genuinely painful.
+    proposedLayerIds:
+      - auth-keycloak
+      - auth-keycloak-realm-import
+      - auth-keycloak-compose
+      - auth-saml-idp
+      - auth-ldap-federation
+      - auth-oidc-client-keycloak
+
+  - name: goauthentik/authentik
+    url: https://github.com/goauthentik/authentik
+    stack: python
+    complexity: enterprise
+    stars: 22373
+    spdx: NOASSERTION
+    licenseClass: reference-only
+    licenseNotes: >-
+      Re-verified this pass by reading main/LICENSE directly, and the split is confirmed
+      verbatim: "Portions of this software are licensed as follows: * All content residing
+      under the website/ directory ... Creative Commons: CC BY-SA 4.0 ... * All content that
+      resides under the authentik/enterprise/ directory ..." (separate proprietary terms).
+      MIT applies to the remaining main tree. `NOASSERTION` is retained as the spdx value
+      because no single SPDX id describes the repository. Because the repo is split-licensed, an automated scaffolder
+      must not copy from it — a human can lift specific MIT-tree files after checking the path,
+      but that decision cannot be delegated to a template.
+    maintained: true
+    lastCommit: "2026-07-15"
+    whatToBorrow: >-
+      Read for the blueprint system: `blueprints/` (default, example, system, migrations,
+      plus `schema.json`) expresses the entire IdP configuration — flows, stages, prompts,
+      policies, providers — as declarative, version-controllable YAML with a published JSON
+      Schema. That is the pattern worth reimplementing for any "IdP config as code" layer,
+      and it is a better model than Keycloak realm exports. The flow/stage/policy decomposition
+      of authentication is also the clearest mental model of step-up auth in any of these projects.
+    whatToAvoid: >-
+      Do not copy files — the split license is the whole problem, and features drifting into
+      `authentik/enterprise/` over time means a path that is MIT today may not be tomorrow.
+      Operationally it needs server + worker + Postgres + Redis, so the compose floor is high.
+      Deploy it as a container and configure it with blueprints; treat the source as reading
+      material only.
+    proposedLayerIds:
+      - auth-authentik-deploy
+      - auth-idp-config-as-code
+      - auth-flow-stage-policy-model
+
+droppedCandidates:
+  - "zitadel/zitadel — RE-VERIFIED this pass; LICENSING.md at HEAD states verbatim 'This repository is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0-only)'. AGPL-3.0-only for the server. Apache-2.0 only for proto/ and apps/docs/; MIT only for apps/login/, packages/zitadel-client/, packages/zitadel-proto/. Excluded for vendoring; the MIT apps/login/ Next.js UI and the client SDKs are the sole safely-copyable parts, and running the container as a dependency is fine but the AGPL network clause then binds the operator."
+  - "hexclave/hexclave (formerly stack-auth/stack-auth, 6829 stars, API license NOASSERTION) — LICENSE read directly: MIT for client code and examples, AGPLv3 for server components. Excluded. Also renamed and repositioned in early 2026, so URLs and package names are unstable."
+  - "logto-io/logto — RE-VERIFIED this pass; master/LICENSE read directly and is the Mozilla Public License Version 2.0 text. MPL-2.0. Reference-only, not excluded, but file-level copyleft makes it unsafe for a scaffolder that copies files; deploy the container instead. Strong product otherwise."
+  - "DuendeSoftware/products (IdentityServer) — commercial RPL license requiring a paid key above a revenue threshold. Not open source for our purposes; excluded. OpenIddict is the free .NET replacement and is in the list."
+  - "supertokens/supertokens-core — RE-VERIFIED this pass; LICENSE.md opens 'Portions of this software are licensed as follows: * All content that resides under the ee/ directory ... is licensed under the license defined in ee/LICENSE.md'. Apache-2.0 at the root but an `ee/` directory under a separate Enterprise Edition license. A legitimate self-host option, dropped only to avoid a third split-licensed entry; revisit if a SuperTokens layer is requested."
+  - "clerk/javascript — SDKs are MIT but the authentication backend is proprietary SaaS. Usable as a paid dependency layer, useless as adaptable source material."
+  - "Auth0 / Okta / Firebase Auth / AWS Cognito — SaaS only, no adaptable server source."
+  - "casdoor/casdoor (13970 stars, Apache-2.0, active) — vendorable and a reasonable Keycloak alternative, but overlaps Keycloak and authentik and the project has repositioned toward an 'agent-first IAM / MCP gateway' framing, so its surface is less stable. Hold as a backup enterprise entry."
+  - "ory/fosite (2599 stars, Apache-2.0, pushed 2025-11-20) — excellent Go OAuth2 SDK, but it is the library inside Hydra; adopt Hydra rather than building on fosite directly."
+  - "nextauthjs/next-auth-example (4030 stars, ISC, pushed 2025-09-26) — useful minimal wiring reference, folded into the next-auth entry rather than listed separately."
+  - "pilcrowonpaper/arctic — MIT VERIFIED this pass by reading main/LICENSE directly ('MIT License, Copyright (c) 2023 pilcrowOnPaper'), which matters because the Lucia entry recommends pairing with it. OAuth 2.0 client library (~50 providers) by the Lucia author; noted inside the Lucia entry as the companion OAuth layer rather than as a standalone source."