HAAPI, or Hypermedia Authentication API, is an approach for exposing authentication journeys through API responses that describe the next available action. It helps clients render forms and handle state transitions dynamically, which is useful when authentication flows need flexibility across web, mobile, and integrated applications.
Expanded Definition
HAAPI, or Hypermedia Authentication API, is a pattern for exposing authentication as a navigable set of API responses that describe what the client can do next. Rather than hard-coding every step of a login or verification journey, the server returns state-aware actions, which lets web, mobile, and integrated applications adapt their rendering and behaviour dynamically. In NHI and IAM contexts, this is useful when authentication must support changing trust conditions, device posture checks, step-up challenges, or delegated flows without forcing a rigid client implementation. HAAPI is not a credential type, a protocol replacement, or a standalone security control. It is an interaction model, and usage in the industry is still evolving because implementations vary across vendors and architecture styles. The most common misapplication is treating HAAPI like a complete authentication standard, which occurs when teams expose hypermedia actions but omit server-side enforcement, auditability, or strong session controls.
For a standards-oriented comparison, teams often contrast HAAPI with broader API security guidance such as NIST Cybersecurity Framework 2.0, which frames identity-aware services inside a wider governance and risk program.
Examples and Use Cases
Implementing HAAPI rigorously often introduces client complexity, requiring organisations to weigh flexibility in authentication journeys against the cost of building stateful UI logic that follows server-directed actions.
- A mobile app receives a hypermedia response that instructs it to show password entry, then a one-time code step only after the server detects risk signals.
- A partner portal uses HAAPI to render different authentication paths for employees, vendors, and service accounts without separate hard-coded flows.
- An identity platform emits next-action links for registration, recovery, or step-up verification so the same client can adapt across channels.
- A product team models a login flow after API-driven navigation rather than fixed screens, reducing client coupling when policy changes.
- Security engineers test HAAPI responses against failure paths to ensure hidden actions do not reveal unauthorised transition options.
In practice, HAAPI becomes easier to understand when paired with real identity failures. The McDonald’s McHire AI Chatbot Default Credentials case shows how exposed authentication surfaces can fail when defaults and weak session handling intersect, while the broader NHI risk picture documented in Ultimate Guide to NHIs shows why flexible journeys still need strict governance. For implementation teams, the key comparison is not whether the client is “smart,” but whether the server remains the source of truth for every state transition.
Why It Matters in NHI Security
HAAPI matters in NHI security because non-human workflows often depend on authentication events that are short-lived, conditional, and highly automatable. When these journeys are exposed through APIs, poor design can turn convenience into attack surface: unauthorized clients may infer available actions, sensitive steps may be skipped, or session state may be replayed across tools and channels. That risk is amplified in environments where service accounts, API keys, and delegated agents already outnumber human identities, and where NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. The lesson is not that hypermedia is unsafe, but that authentication journeys must remain policy-driven, logged, and tightly bound to the current trust decision. HAAPI also aligns conceptually with zero trust thinking because the client should never assume the next step without server confirmation. Organisations typically encounter the operational need for HAAPI only after authentication flows break under channel expansion, at which point the term becomes operationally unavoidable to address.
For policy mapping, the NIST view of identity-aware control alignment in NIST Cybersecurity Framework 2.0 helps teams connect authentication design to access governance, monitoring, and response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic clients often follow dynamic auth actions returned by APIs. | |
| OWASP Non-Human Identity Top 10 | NHI-06 | Dynamic auth flows affect service account and API client access paths. |
| NIST CSF 2.0 | PR.AC-1 | Authentication state transitions support access control enforcement. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero Trust requires every step to be re-evaluated, not assumed. |
| NIST AI RMF | GOVERN-5 | Adaptive auth journeys need governance over design and oversight. |
Document HAAPI decision logic, audit transitions, and review failure handling regularly.