Choose the package that matches your target operating model, not just your current prototype. Breeze is suited to simple session-based login, Jetstream adds richer account features, Fortify supplies headless auth, Sanctum fits first-party SPAs and mobile apps, and Passport is for full OAuth2 requirements. The best choice is the one that avoids a rebuild when enterprise needs arrive.
Why This Matters for Security Teams
Choosing between Breeze, Jetstream, Fortify, Sanctum, and Passport is really a decision about identity boundaries, session shape, and how far the application must scale into enterprise controls. A lightweight package may be fine for a prototype, but it can become a liability when teams need SSO, API authentication, mobile clients, or delegated authorisation. That is the same pattern NHI programs see when secrets, service accounts, and workloads are designed for convenience first and governance later. NHI Mgmt Group research shows that only 5.7% of organisations have full visibility into their service accounts, which is a useful warning sign for identity design that assumes limited future growth. The broader guidance in the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 both point to the same operational truth: identity architecture should be chosen for the operating model you are moving toward, not the one you have today. In practice, many security teams encounter migration debt only after product and compliance requirements have already outgrown the original auth stack.
How It Works in Practice
The package choice usually maps to three questions: do users need browser sessions, do they need API tokens, and do they need third-party delegated access? Breeze is usually the simplest option when standard session login is enough. Jetstream adds more account management structure, which helps when teams want profile management, team workflows, or starter scaffolding without designing every screen from scratch. Fortify is the right fit when the team wants headless authentication and plans to own the frontend separately. Sanctum is typically the pragmatic choice for first-party SPAs and mobile applications because it supports session-based and token-based patterns without the heavier OAuth2 surface area. Passport is for cases where OAuth2 is a requirement, especially when the application must issue or accept delegated access across systems.
Security teams should also think about how the package shapes secrets handling and lifecycle control. Static credentials and broad tokens create the same failure mode seen in NHI environments where long-lived access lingers beyond its original purpose. The Ultimate Guide to NHIs notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, and that is a reminder to prefer auth flows that reduce token sprawl and make rotation feasible. For design and control mapping, the NIST Cybersecurity Framework 2.0 is useful for tying package selection back to access control, logging, and recovery expectations.
- Choose Breeze when the requirement is a straightforward web app with standard login and minimal custom auth logic.
- Choose Jetstream when product teams need built-in account features and collaboration workflows.
- Choose Fortify when the frontend is separate and authentication must stay headless.
- Choose Sanctum when first-party SPAs or mobile clients need a lighter token and session model.
- Choose Passport only when OAuth2 delegation, client credentials, or third-party integrations are unavoidable.
These controls tend to break down when multiple application types share one auth layer because each client class needs different token lifetimes, trust boundaries, and revocation logic.
Common Variations and Edge Cases
Tighter auth control often increases implementation overhead, requiring organisations to balance simplicity against future interoperability. That tradeoff is most visible when a team is deciding between Sanctum and Passport, or when Fortify is paired with a separate SPA or mobile frontend. Current guidance suggests avoiding OAuth2 unless the application truly needs delegated authorisation, because Passport adds complexity that many internal systems do not need. At the same time, a “simple now, migrate later” approach can backfire if the product is likely to integrate with partners, support machine-to-machine access, or adopt cross-domain identity later.
There is also no universal standard for this yet when teams are aligning app auth with autonomous workflows, service accounts, or agentic components. In those cases, the conversation shifts from user login to workload identity, JIT credentialing, and intent-aware access decisions. The important lesson is to avoid picking a package only because it is the easiest scaffold. Mature identity programs treat the auth stack as part of the control plane, not just a login screen, and the same discipline is reflected in NHI governance guidance from Ultimate Guide to NHIs and zero trust planning in the NIST Cybersecurity Framework 2.0.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-1 | Identity proofing and access architecture choice affect authentication design. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Long-lived credentials and poor rotation create the same risk this choice can amplify. |
| NIST AI RMF | Autonomous or dynamic workloads need governance beyond static login patterns. |
Treat identity choice as a governance decision and define runtime accountability up front.
Related resources from NHI Mgmt Group
- How should security teams authenticate AI agents in enterprise environments?
- How should security teams implement Client ID Metadata Documents?
- How should security teams choose between RBAC, ABAC, and PBAC for NHI access?
- How should security teams choose between basic, predefined, and custom GCP IAM roles?
