Authentication versus authorisation: the conceptual split

Authentication: a question about identity

Authentication proves that the person making a request is the person the account claims. The classical model has three factor types: something you know (a password or PIN), something you have (a phone with an authenticator app, a hardware key), and something you are (a fingerprint or face). Single-factor uses one. Multi-factor authentication requires two from different categories, on the reasoning that an attacker who stole the password is unlikely to also hold the phone.

Passwordless authentication, despite the name, is not a fourth factor. A passkey is a private key (something you have) unlocked by a biometric (something you are). The cryptography is fresher and the sign-in shorter, but the categories are unchanged.

Authenticating a user costs key presses and attention, so applications cannot ask on every request. They cache the answer in a session: a successful authentication produces a session, the session lives for minutes or hours, and during that window the application treats the user as authenticated without asking again. This is what users feel as 'staying logged in'. It is also where the long tail of post-authentication risk sits, because once a session exists, compromising it no longer requires the password.

Most organisations do not run authentication inside each application. They delegate the question to one trusted system, the identity provider (IdP), and let every application defer to it. Microsoft Entra ID, Google Workspace, Okta and Auth0 dominate Australian corporate environments in 2026. The IdP is where the password lives, or where the passkey is registered; where MFA is enforced; and where sign-in events are logged. In a federated world, authentication is a property of the IdP, not of the application.

Authorisation: a question about policy

Authorisation is the separate decision about what an authenticated user may do. Its inputs typically include who the user is, what action they are attempting, what role or permission set they hold, and the context: device, location, time, risk score. Its output is a yes or no.

Three models dominate enterprise authorisation. Role-based access control (RBAC) assigns roles to users and permissions to roles. Attribute-based access control (ABAC) evaluates rules over user, resource and environment attributes. Policy-based access control, of which Microsoft Conditional Access is the canonical example, layers a rules engine on top of either to decide per sign-in. A modern environment uses all three, often without anyone tracking which decision lives where.

The property of authorisation that matters most for shadow AI is that it can outlive authentication. A user authenticates once at 9am. The system issues an access token valid until 5pm and a refresh token valid for weeks. The user is now authorised, by holding those tokens, to call a long list of APIs without re-authenticating. If the account is disabled at 11am, the access token still works until it expires or until each application checks back with the IdP, and the refresh token still works until something revokes it. Authorisation that outlives authentication is the design point that makes web applications usable, and it is where almost every interesting identity-layer attack sits.

How they connect: assertions, tokens, claims

The mechanism that links the two is the bearer token, seen in Chapter 6 in its HTTP-header form. When a user authenticates to an IdP and requests access to an application, three artefacts are commonly produced. An identity assertion describes what the IdP knows about the user; in SAML this is a SAML assertion, in OpenID Connect an ID token. An access token authorises the holder to call the application's APIs on the user's behalf, limited to a set of permissions. A refresh token, where issued, lets the application obtain new access tokens silently.

Each token carries claims: key-value statements such as 'sub' for the user identifier, 'aud' for the intended audience, 'iat' for issue time, 'exp' for expiry, and application-specific claims about roles, groups and consented scopes. JSON Web Tokens, the format carrying most of these, are base64-encoded and readable to anyone who can decode them, so the corporate proxy of Chapter 7, when it inspects traffic, can read the user identity, the issuing tenant and the granted scopes without the signing key. Whether it is permitted to is a Part Five question.

The pattern is delegation. A user signs in to their IdP; the IdP issues tokens to the application; the application calls the user's APIs using those tokens; the user's password never touches the application. The IdP vouches for the user, and the application trusts the IdP. OAuth 2.0 is the dominant standard for the delegation step, and OpenID Connect adds the identity-assertion semantics on top. Chapter 10 covers both mechanically. The point here is that these protocols separate the act of proving identity from the act of granting capabilities, and that separation is what lets an organisation govern the two independently: the IdP owns authentication, the application owns authorisation for its own resources, and a policy engine such as Conditional Access can deny a sign-in the IdP would otherwise allow.

The shadow AI lens

The 'sign in with Google' or 'Continue with Microsoft' button on every consumer AI service is where the split arrives in operational form. When a corporate user clicks the corporate option, the IdP authenticates them with whatever factors policy requires; issues an ID token asserting their identity to the AI vendor; and often the AI vendor also requests OAuth scopes, asking to read profile information at least, sometimes more. The user clicks 'Allow', and the AI vendor receives an access token and a refresh token. Until that refresh token is revoked, the AI vendor can call certain APIs in the user's tenant on the user's behalf.

This is a federated sign-in working as designed, and it is where a defender starts losing visibility. The sign-in event is in Entra. The OAuth grant is in Entra, under 'Enterprise applications'. What the AI vendor does with the tokens afterwards is in the AI vendor's own logs, which the organisation can read only if it pays for an enterprise tenant in that AI service.

The deeper problem is that the same staff member has another identity available. Almost every consumer AI tool also accepts a personal account: a personal Gmail address, a personal Microsoft account, a free email-and-password sign-up. A user can sign into Claude with their corporate or their personal identity, on the same managed device, sometimes in the same browser session. From the network's view, both are a TLS connection to claude.ai. From the IdP's view, only the corporate sign-in exists at all. The personal sign-in does not touch Entra, does not appear in its sign-in logs, and does not invoke Conditional Access. This two-identity problem is the heart of the shadow AI gap at the identity layer, and most controls written for the corporate IdP have nothing to say about it.

Conditional Access shows the trade-off. As an authorisation layer over authentication, it has reach: a defender can require a compliant device, an MFA prompt or a particular risk threshold before allowing a sign-in to a named application, and the Entra catalogue lists thousands of pre-categorised SaaS so that AI tools can be targeted specifically. Conditional Access can deny corporate sign-in to chat.openai.com from a non-compliant device with one rule. It cannot prevent the same user signing in with a personal account, because the personal account never authenticates against Entra. The rule operates on what it can see, which is the corporate authentication path. The way forward is not a stronger authorisation rule; it is to recognise that authentication-layer controls cover one half of the problem, and the other half needs the network, endpoint and governance controls the rest of the manual covers.

A second consequence appears in app registrations and consent. When a user clicks 'Continue with Microsoft', the AI vendor's application becomes a registered enterprise application in the tenant, with its own identity, permissions and sign-in events. The consent framework decides whether the user can grant the requested scopes themselves, or whether an administrator must approve. Microsoft has tightened the defaults over time, but tenants configured years ago can still permit user consent to scopes an administrator would refuse if asked one at a time. (medium; default behaviour depends on tenant age and licensing) Entra exposes the enterprise-application list and the consents granted; Defender for Cloud Apps adds tenant-wide risk scoring. Not every organisation looks, and a tenant audit at the start of a control programme routinely surfaces a hundred or more consented OAuth applications no one remembered approving, including a long tail of AI tools. (medium; the figure varies by sector and tenant size, but the pattern is consistent)

What a defender can see at this layer, when the controls work, is a clean record of corporate identity meeting AI tool: the sign-in, the Conditional Access decision, the OAuth grant, the consented scopes. What they cannot see, ever, is a personal-account interaction with the same AI tool from the same device. Identity-layer telemetry is sharp where it bites and silent where it does not.

Last updated 9 August 2026