Many service accounts, integrations and scripts still authenticate with methods the standards bodies have already deprecated: passwords sent to token endpoints, app passwords that skip MFA, OAuth flows that leak tokens, and static keys where a federated credential was available. OWASP ranks this as NHI4:2025 Insecure Authentication in the OWASP Non-Human Identities Top 10. This guide maps each insecure pattern OWASP names to the modern replacement, the specification that deprecates it, and the evidence that proves it is gone. It is for identity architects, platform and cloud engineers, and application security teams who own how machines prove who they are. Protocol depth on OAuth, mTLS and SPIFFE lives in separate guides linked below.
Key takeaways
- Insecure authentication is a method problem, not a secret problem. NHI4 is about the way a workload authenticates; a perfectly stored password used over a legacy protocol is still NHI4.
- Two OAuth grants are effectively retired. RFC 9700 says clients should not use the implicit grant and must not use the resource owner password credentials grant.
- Credential-less beats credential-based. Instance profiles, managed identities, OIDC federation and SPIFFE issue short-lived, scoped credentials, leaving nothing long-lived to leak.
- App passwords and legacy protocols bypass MFA. Microsoft reports that more than 99 percent of password spray attacks use legacy authentication, and Google states app passwords are not recommended.
- Proof of possession is the next bar. Sender-constrained tokens (mTLS under RFC 8705 or DPoP under RFC 9449) and asymmetric client authentication make a stolen token or client secret far less useful.
What it is and who it applies to
NHI4 is the fourth of ten risks in the OWASP Non-Human Identities Top 10 (2025): NHI1 Improper Offboarding, NHI2 Secret Leakage, NHI3 Vulnerable Third-Party NHI, NHI4 Insecure Authentication, NHI5 Overprivileged NHI, NHI6 Insecure Cloud Deployment Configurations, NHI7 Long-Lived Secrets, NHI8 Environment Isolation, NHI9 NHI Reuse and NHI10 Human Use of NHI.
OWASP's description: developers connect internal and third-party services to SaaS and cloud platforms, those services need credentials, and some of the available authentication methods are deprecated, vulnerable to known attacks or weak. Using them leads to unauthorised access, data breaches and compliance failures. OWASP points teams to methods that follow standards such as OAuth 2.1 and OpenID Connect.
It applies to anyone who builds or operates machine-to-machine connections: SaaS integrations, CI/CD pipelines, mail relays and scanners, data pipelines, microservices, and AI agents calling APIs. It also applies to authorisation server owners, who decide which grants and client authentication methods are allowed at all.
NHI4 sits next to NHI7 Long-Lived Secrets (how long a credential lives) and NHI2 Secret Leakage (where it ends up). Fixing NHI4 usually shrinks both.
Structure and key requirements
OWASP describes five example scenarios and four prevention measures. The table pairs each insecure pattern with what replaces it and the source that says so.
| Insecure pattern (OWASP scenario) | Why it fails | Replacement | Authority |
|---|---|---|---|
Implicit flow (response_type=token) | Access token returned in the authorisation response, exposed in URLs and browser history, open to token injection | Authorisation code flow with PKCE | RFC 9700 section 2.1.2 (should not use); ASVS 5.0 V10.4.4 |
| Authorisation code flow without PKCE | Code interception and CSRF | PKCE with S256, enforced by the server | RFC 9700 section 2.1.1; ASVS 5.0 V10.4.6 |
| Resource owner password credentials grant and proprietary username/password flows | Client handles the password, no MFA, open to interception and replay | Client credentials with asymmetric client authentication, or a delegated code flow | RFC 9700 section 2.4 (must not use) |
| Non-standard OAuth (tokens converted to cookies, JWTs minted on demand) | Custom behaviour that the security analysis behind the specifications never covered | Standard grants and libraries, no custom token endpoints | OWASP NHI4 prevention |
| Long-lived API keys or passwords where federation exists | Leak through repositories, logs and breaches; valid until someone rotates them | Instance profiles, managed identities, OIDC federation, SPIFFE SVIDs | OWASP NHI4; AWS IAM best practices |
| App passwords | Bypass MFA; a stolen app password works even with MFA enabled | OAuth sign-in or app-only certificate authentication | Google Account Help; Microsoft Exchange Online guidance |
The four OWASP prevention measures
- Adopt modern standards: OAuth 2.1 and OIDC, avoiding the implicit flow and PKCE-less code flow. OAuth 2.1 is still an IETF draft; RFC 9700 (January 2025, BCP 240) is the published best current practice that carries the same rules.
- Use ephemeral credentials: scoped, short-lived credentials from instance profiles, OIDC federation or a cloud-agnostic option such as SPIFFE.
- Follow the standards closely: no custom deviations in grants, token formats or session handling.
- Audit regularly: find and remove deprecated or insecure authentication configuration.
Identity and NHI requirements
Choosing the right method depends on where the workload runs and what it calls. The ladder below runs from weakest to strongest; the goal is to move every NHI up at least one rung.
| Rung | Method | Credential lifetime | Typical use |
|---|---|---|---|
| 1 (eliminate) | Basic authentication, app passwords, ROPC, proprietary password flows | Until changed | Legacy mail clients, old connectors, scripts |
| 2 (contain) | Static API key or client secret, stored in a secrets manager, rotated, IP restricted | Days to months | SaaS APIs that offer nothing better |
| 3 (good) | OAuth client credentials with private_key_jwt or tls_client_auth; certificate-based app-only authentication | Access token minutes to an hour; key pair rotated | Service-to-SaaS and service-to-API |
| 4 (preferred) | Platform-issued identity: AWS IAM roles, Azure managed identities, GCP service account impersonation, Kubernetes projected tokens exchanged through workload identity federation | Minutes to hours, issued automatically | Workloads on cloud or Kubernetes, CI/CD to cloud |
| 5 (strongest) | Attested workload identity (SPIFFE SVIDs) with mTLS, and sender-constrained tokens (RFC 8705 or DPoP) | Short-lived, bound to a key | Service mesh, multi-cloud, high-value APIs |
Decision guidance
- Workload on a cloud platform calling the same cloud: use the platform identity. AWS documents that workloads on EC2 or Lambda receive temporary role credentials, so there is no reason to distribute IAM user keys.
- Workload outside the cloud: AWS lists IAM Roles Anywhere (X.509 certificate),
AssumeRoleWithWebIdentity(a JWT from a trusted IdP),AssumeRoleWithSAMLand mTLS for IoT devices. See the Workload Identity Federation Guide. - Service calling a SaaS API: client credentials with a key pair beats a client secret; a client secret beats a username and password. See the Machine-to-Machine OAuth (Client Credentials) Guide.
- Service to service inside your estate: mTLS with workload certificates, ideally from SPIFFE/SPIRE. ASVS 5.0 V12.3.5 asks for strong authentication between internal services. See the mTLS Guide and the SPIFFE and SPIRE Guide.
- Vendor only supports static keys: accept it as rung 2, document the exception with an expiry date, and press the vendor at renewal.
- Small organisations: block legacy authentication at the identity provider and move CI/CD to OIDC federation; those two changes remove most rung 1 credentials. Large organisations: also set authorisation server policy so new clients cannot register deprecated grants or secret-based authentication without approval.
Hardening credentials that must stay static
Some SaaS APIs and appliances offer nothing beyond an API key or a basic username and password. NHI4 does not disappear there, but it can be contained:
- One credential per consumer: a dedicated key per integration, never a shared service account password (see the OWASP NHI Top 10 NHI9 NHI Reuse Guide).
- Network binding: restrict the credential to known source addresses where the platform supports it, so a copy is useless from elsewhere. The Snowflake intrusions show what happens without it.
- Transport: TLS only, never credentials in query strings or URLs, where they end up in proxy and web server logs.
- Retrieval at runtime: pull the credential from a secrets manager at start-up instead of baking it into images, pipelines or configuration files.
- Rotation you can prove: scheduled, automated rotation with a recorded last-rotated date. See the Secrets Management Guide.
Where AI agents fit
AI agents and MCP servers are new NHIs that repeat the same choices. An agent given a user's password or a long-lived personal token to call an API is a rung 1 or rung 2 design. Prefer delegated OAuth with PKCE when the agent acts for a user, token exchange to narrow scope per downstream call, and platform identity when the agent runs as a workload. See the OAuth Token Exchange and Delegation Guide.
For the protocol detail behind OAuth 2.1 and sender-constrained tokens, see the OAuth 2.1, GNAP and FAPI Guide.
Implementation steps
- Discover authentication methods, not just identities. For each NHI record the protocol and grant type it uses. In Microsoft Entra ID, filter sign-in logs on the Client App column for legacy protocols on both the interactive and the User sign-ins (non-interactive) tabs, or use the Sign-ins using legacy authentication workbook. On authorisation servers, list clients by allowed grant types and token endpoint authentication method.
- Block legacy authentication in report-only first. Microsoft's template Conditional Access policy targets the Exchange ActiveSync clients and Other clients conditions with Block access. Run it in Report-only, review impact, then switch to On by group. Exclude break-glass accounts. Note that Conditional Access does not apply to service principals; Microsoft points to Conditional Access for workload identities and to managed identities for scripts.
- Retire deprecated OAuth grants. Disable the implicit and password grants for every client that does not need them (ASVS 5.0 V10.4.4 asks the authorisation server to allow only the grants each client needs), require PKCE with
S256on all code flows, and enforce exact redirect URI matching. - Remove app passwords and basic authentication. Exchange Online basic authentication is already disabled for EAS, POP, IMAP, EWS, Remote PowerShell and Outlook clients; Microsoft has announced retirement of basic authentication for SMTP AUTH client submission on an updated timeline, so check the current date before planning. Move unattended Exchange PowerShell to app-only certificate authentication and mail-sending apps to OAuth or Microsoft Graph.
- Move workloads to platform identity and federation. Replace IAM user keys with roles, Azure secrets with managed identities, and CI/CD cloud keys with OIDC federation. Run old and new credentials side by side for one release, confirm through access-last-used data that the old key is idle, then deactivate it before deletion so rollback is a re-enable rather than a reissue.
- Strengthen client authentication. Where client secrets remain, move to
private_key_jwtor mTLS client authentication (ASVS 5.0 V10.4.16), and for high-value APIs issue sender-constrained tokens (V10.4.14, V10.3.5). - Lock the door behind you. Add policy checks so new app registrations, connected apps and CI pipelines cannot reintroduce deprecated methods, and review exceptions on a fixed cycle.
Evidence and assessment
What to log and monitor
- Identity provider: sign-ins by client app and protocol, especially legacy protocols on non-interactive sign-ins, and password spray patterns against service accounts.
- Authorisation server: token requests by grant type and client authentication method; any implicit or password grant use is an alert once retired.
- Cloud: API calls signed with long-term access keys (AWS access keys beginning AKIA) versus temporary credentials, and new access keys created for IAM users.
- Configuration drift: re-enabled basic authentication, new app passwords, new client secrets added to app registrations.
Metrics
| Metric | Target |
|---|---|
| Sign-ins using legacy authentication protocols (30 days) | Zero outside documented exceptions |
| OAuth clients permitted to use implicit or password grants | Zero |
| Code flow clients without enforced PKCE | Zero |
| Share of workloads using platform identity or federation rather than static credentials | Rising quarter on quarter |
| Confidential clients using secret-based rather than key-based authentication | Falling, with dated exceptions |
| Active app passwords | Zero, or a named, reviewed list |
Evidence an assessor should ask for
- The Conditional Access (or equivalent) policy blocking legacy authentication, with its state and exclusions.
- An export of OAuth clients with allowed grant types and authentication methods.
- A report of cloud credentials by type, and the exception register for remaining static credentials.
Mapping to other frameworks
| Framework | Reference | Relevance to NHI4 |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01, PR.AA-03 | Identities and credentials for services managed; users, services and hardware authenticated |
| NIST SP 800-53 Rev. 5 | IA-9 Service Identification and Authentication, IA-3 Device Identification and Authentication, IA-5 Authenticator Management, IA-5(2) Public Key-based Authentication, SC-8 Transmission Confidentiality and Integrity, SC-23 Session Authenticity | How services authenticate, how authenticators are managed, and protection of credentials in transit |
| OWASP ASVS 5.0 | V10.4.4, V10.4.6, V10.4.14, V10.4.16, V10.3.5, V12.3.5 | Grant restriction, PKCE, sender-constrained tokens, strong client authentication, internal service authentication |
| CIS Controls v8.1 | Control 6 Access Control Management (6.3 MFA for externally exposed applications) | Legacy protocols and app passwords defeat the MFA these safeguards require |
| ISO/IEC 27001:2022 Annex A | 5.17 Authentication information, 8.5 Secure authentication | Management of authentication information and secure authentication procedures |
| MITRE ATT&CK | T1110.003 Password Spraying, T1078.004 Cloud Accounts, T1552.001 Credentials In Files, T1557 Adversary-in-the-Middle, T1550.001 Application Access Token | Attacks that weak, static or replayable machine authentication enables |
Common pitfalls
- Leaving password-only accounts on data platforms. In the Snowflake breach, infostealer credentials worked against about 165 organisations' accounts because a username and password were all that was needed; there was no MFA, no rotation and no network allow list.
- Forgetting legacy and test tenants. The Microsoft Midnight Blizzard breach began with a password spray against a legacy test account without MFA, then abused a legacy OAuth application with elevated access.
- Keeping static credentials because they seem unused. In the Cloudflare breach, a service token and service account credentials that were not rotated after the Okta incident became the way in.
- Blocking legacy authentication for users only. Policies scoped to interactive users miss non-interactive sign-ins and service principals, which is where most NHI traffic is.
- Calling a custom flow "OAuth". Home-grown token endpoints and cookie conversions inherit none of the protections the standards analyse; OWASP lists them as a scenario in their own right.
- Federating, then keeping the old key. Migrations that add a role or federated identity but never delete the IAM user key leave the weakest path open.
Practitioner checklist
- Record the authentication method and grant type for every NHI, not just its existence.
- Block legacy authentication protocols, starting in report-only, including non-interactive sign-ins.
- Disable implicit and password grants and require PKCE with S256 on every authorisation server.
- Remove app passwords and basic authentication; move unattended scripts to certificate-based app-only authentication.
- Move cloud and CI/CD workloads to platform identity or OIDC federation and delete the replaced keys.
- Use key-based client authentication (private_key_jwt or mTLS) instead of client secrets where supported.
- Issue sender-constrained tokens for high-value APIs.
- Alert on any use of retired grants or legacy protocols and track the metrics above monthly.
- Keep an exception register with owners and expiry dates for every remaining static credential.
Standards and references
- OWASP: NHI4:2025 Insecure Authentication
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- OWASP: Application Security Verification Standard 5.0
- NIST: SP 800-53 Rev. 5
- Microsoft Learn: Block legacy authentication with Conditional Access
- Microsoft Learn: Deprecation of Basic authentication in Exchange Online
- AWS: Security best practices in IAM
- Google Account Help: Sign in with app passwords
Related NHI Mgmt Group resources: Machine-to-Machine OAuth (Client Credentials) Guide · Workload Identity Federation Guide · Service Account Security Guide · OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide · Non-Human Identity (NHI) Guide