Authentication vs Authorisation: Differences, Examples and Common Failures

Authentication proves who or what is making a request; authorisation decides what that verified identity may do, and most serious access failures happen when a system treats the first as if it settled the second. The two are taught together and often built into the same login flow, so teams assume a strong sign-in means strong access control. It does not: an attacker with a stolen but valid session passes authentication perfectly, and a fully authenticated user who changes an object ID in a URL is an authorisation problem. This guide gives a short answer, a side-by-side comparison, worked examples for people, APIs and machine identities, how the two fit together in OAuth, OpenID Connect and zero trust, and the failure patterns that recur in both. It is for developers, architects and IAM teams who design, review or test access.

Key takeaways

• Different questions, different evidence. NIST SP 800-63-4 defines authentication as a claimant proving possession and control of authenticators bound to an account. Authorisation, in the CNSSI 4009 and SP 800-162 sense, is the decision to allow or deny a subject's access to an object.
• Authentication happens once per session; authorisation happens on every request. A login sets up who you are; each API call, object read and admin action still needs its own permission check on the server.
• The OWASP lists keep them apart. OWASP Top 10:2025 lists A01 Broken Access Control and A07 Authentication Failures separately; the OWASP API Security Top 10 2023 has three authorisation risks (API1, API3, API5) alongside API2 Broken Authentication.
• HTTP has a code for each. 401 Unauthorized means the request lacks valid authentication; 403 Forbidden means the identity is known but lacks permission. Mixing them up hides the real fault.
• Machines need both too. A service account, workload or AI agent authenticates with a key, certificate or federated token, and is then authorised by roles and scopes. Over-broad authorisation on a correctly authenticated machine identity is one of the most common NHI exposures.

The short answer

Authentication (AuthN) answers "are you who you claim to be?". The subject presents something it knows, has or is (a password, a passkey, a private key, a certificate, a signed token from a trusted issuer) and the system verifies it. FIPS 200 and NIST SP 800-53 Rev. 5 describe it as verifying the identity of a user, process or device, often as a prerequisite to granting access.

Authorisation (AuthZ) answers "are you allowed to do this, to this resource, now?". The system takes the authenticated identity plus attributes of the resource, the action and the context, and applies policy. NIST SP 800-53 Rev. 5 describes authorisation as permissions granted to a person or software process, or the act of granting them; SP 800-162 frames it as the decision to allow or block a subject's access to objects.

The order is fixed: authenticate first, then authorise. Neither substitutes for the other. You never choose authentication "instead of" authorisation; you decide how strong each must be for a given resource and where each is enforced.

Side-by-side comparison

Worked examples

A person using a web application

A finance analyst signs in with a passkey (authentication, phishing-resistant at NIST AAL2 or above). The application then checks, for each request, that her role may view invoices, that the invoice belongs to a cost centre she covers, and that approving a payment above a threshold needs a second approver (authorisation, combining role, attribute and business rule). If she tries /invoices/10432 for another cost centre, authentication has nothing to say: only the per-object check stops it.

A client calling an API

A mobile app sends Authorization: Bearer <access token>. The API validates the token's signature, issuer, audience and expiry: that is authentication of the token and, through it, of the client and user. It then checks the token's scope covers the endpoint (coarse authorisation) and that the user owns the requested record (fine-grained authorisation). OWASP ASVS 5.0 V8.3.1 requires authorisation to be enforced at a trusted service layer, not by hiding buttons in the client.

A machine identity

A Kubernetes workload authenticates to a cloud provider with a federated service account token, with no stored secret. The cloud then authorises it through the role it assumes. The authentication can be excellent and the authorisation still dangerous if the role grants * on storage. See the NHI Authentication Guide and the Least Privilege Techniques Guide.

An AI agent acting for a user

An agent authenticates as itself (its own client credential or workload identity) and acts on behalf of a user. Authorisation must consider both: OWASP ASVS 5.0 V8.3.3 says access to an object should be based on the originating subject's permissions, not those of an intermediary acting on their behalf. See the AI Agent Authorisation Guide.

How they fit together in protocols and architectures

• OAuth 2.0 is an authorisation framework: it issues access tokens that carry delegated permission (scopes) to call APIs. It does not by itself tell the client who the user is.
• OpenID Connect adds authentication: it layers an ID token on top of OAuth so the client learns who signed in. Using an OAuth access token as proof of login is a classic confusion; validate ID tokens for sign-in and access tokens for API calls. See the OAuth 2.0 and OpenID Connect Guide.
• SAML carries both: an assertion states who the user is and can carry attributes the service provider uses for authorisation. The service provider still makes the decision.
• Zero trust treats them as continuous: NIST SP 800-207 places a policy decision point and policy enforcement point in front of resources, re-evaluating identity, device and context per session rather than trusting network location. See the NIST SP 800-207 Zero Trust Architecture Guide.
• Step-up links them: an authorisation decision can demand stronger authentication (for example re-authentication before a payment), which NIST SP 800-53 covers as IA-11 Re-authentication. See the Session Timeout and Reauthentication Guide.

Choosing how strong each must be

The question is never which one to use but how much of each a resource needs, and where to enforce it.

1. Classify the action, not just the application: reading a public catalogue, viewing personal data, changing payment details and administering the tenant need different strength in both dimensions.
2. Set authentication strength from the impact of impersonation: NIST SP 800-63B-4 assurance levels (AAL1 to AAL3) are the reference. At AAL2 verifiers must offer at least one phishing-resistant option, and AAL3 requires a cryptographic authenticator with a non-exportable private key; administrative and high-value actions warrant phishing-resistant authenticators. See the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.
3. Set authorisation granularity from the data model: if users share an application but not records, you need object-level checks, not just roles. Pick the model (RBAC, ABAC, ReBAC) that matches how ownership actually works. See the Authorisation Models Guide.
4. Centralise authentication, distribute enforcement: one identity provider for sign-in; authorisation checks inside each service, ideally calling a shared policy decision point so rules are consistent and testable. See the Policy-as-Code for Authorisation Guide.
5. Decide what happens when either fails: both should fail closed. A policy engine outage must deny, not allow.

Small organisations: buy authentication (an identity provider with MFA and passkeys) and spend engineering time on authorisation in your own code, because no product can know your data ownership rules. Large organisations: separate the two in governance as well: the IAM team owns authenticator policy, while application owners are accountable for authorisation rules, reviewed through access certification and tested in CI.

Implementing and testing both

1. Inventory entry points: list every interface (web, API, admin, batch, message consumers) and the authentication each accepts, including machine credentials.
2. Write the authorisation matrix: roles or attributes against functions, data items and fields, as OWASP ASVS 5.0 V8.1.1 and V8.1.2 ask for. Untested rules are guesses.
3. Enforce server-side on every request: deny by default, check function-level (V8.2.1), object-level (V8.2.2) and field-level (V8.2.3) access, and apply permission changes immediately or with compensating controls when tokens carry them (V8.3.2).
4. Test negatively: for authentication, test missing, expired, wrongly signed and replayed credentials; for authorisation, run the same request as two users and as a lower role, and confirm denial. See the Authorisation Testing Automation Guide.
5. Roll out stronger checks in monitor mode first: log what a new authorisation rule would deny before enforcing it, then enforce per route; keep the previous rule set ready to restore.
6. Review periodically: authentication policy (authenticator types, session lifetimes) and authorisation grants (access reviews, unused permissions) drift in different ways and need separate reviews.

Detection and measurement

• Authentication signals: failed sign-ins by source, impossible travel, MFA prompts denied or spammed, new devices, token validation failures.
• Authorisation signals: 403 rates per user and route, sequential object ID access, a user touching far more records than peers, first use of an admin function, permission changes outside change windows.
• Machine identity signals: a service account authenticating from a new workload or network, and use of permissions it has never used before.

Common failures

• Authentication without strength: in the Snowflake breach, about 165 organisations were notified after attackers logged in with infostealer-captured usernames and passwords to accounts with no MFA and no network allow lists. Nothing in authorisation was bypassed: the attacker simply was, as far as the system could tell, the user.
• Authorisation without limits: in the Microsoft SAS token exposure, a shared link meant to expose some AI models carried an account-level SAS token with full control and an expiry extended to 2051, exposing 38TB. The credential worked as designed; the permissions attached to it were far too broad.
• Treating login as permission: an API that checks only that a token is valid, not that the caller owns the record, is OWASP API1:2023 Broken Object Level Authorization. See the OWASP API Top 10 API1 Broken Object Level Authorization Guide.
• Client-side authorisation: hiding an admin button is not access control. OWASP ASVS 5.0 V8.3.1 requires enforcement at a trusted service layer.
• Using OAuth access tokens as login proof: a client that signs a user in because it received an access token can be fed a token issued to another application. Use OpenID Connect ID tokens and validate their audience.
• Stale authorisation in long sessions or tokens: a user removed from a role keeps it until the session or token expires. Shorten lifetimes or re-check permissions on sensitive actions.

Framework mapping

Practitioner checklist

• Document, per interface, how callers authenticate and where authorisation is enforced.
• Require phishing-resistant authentication for administrators and high-value actions.
• Deny by default and check function, object and field access on the server for every request.
• Keep an authorisation matrix and test it with two-user and lower-role negative tests in CI.
• Return 401 for authentication failures and 403 (or 404) for authorisation failures, and log them separately.
• Use OpenID Connect ID tokens for sign-in and access tokens only for API calls.
• Give every machine identity strong authentication and least-privilege roles, and review both.
• For agents and services acting for users, authorise on the originating user's permissions.
• Make permission removals take effect quickly, with short token lifetimes or re-checks on sensitive actions.

Standards and references

• NIST CSRC Glossary: Authentication
• NIST CSRC Glossary: Authorization
• NIST: SP 800-63B Authentication and Authenticator Management (SP 800-63-4 suite)
• NIST: SP 800-162 Guide to Attribute Based Access Control (ABAC) Definition and Considerations
• OWASP: Top 10:2025
• OWASP: API Security Top 10 2023
• OWASP: Application Security Verification Standard 5.0
• IETF: RFC 9110 HTTP Semantics

Related NHI Mgmt Group resources: Authentication Guide · Broken Access Control Prevention Guide · IAM and IGA Basics · API Security Guide