What is OAuth? A practical guide to delegated authorisation

Security and identity

OAuth is an authorisation framework, most commonly OAuth 2.0, that lets one application access a resource on behalf of a user or service without receiving the user's password. Instead of handing credentials to every connected app, the user signs in with a trusted authorisation server, reviews the requested permissions, and the application receives tokens that represent approved access. That makes OAuth central to APIs, SaaS integrations, mobile apps, AI tool connectors and workflow automation. The catch is that OAuth governs delegated access, not trustworthiness by magic. Scopes, redirect handling, token storage, refresh controls and app governance decide whether the setup is safe or reckless.

What this means

A simple way to explain OAuth is to compare it with giving a cleaner a building pass instead of your master keys. You are not giving them your own credentials. You are allowing a separate identity and permission process to issue limited access for a defined purpose. In software, that purpose might be reading your calendar, sending files to a signed-off integration, or letting an AI assistant query a knowledge source you approved.

Several roles sit behind that. The resource owner is the person or organisation whose data or resource is being accessed. The client is the application requesting access. The authorisation server handles user approval and issues tokens. The resource server holds the protected resource, such as an API or SaaS data store. The access token is what the client presents to the resource server. A refresh token may allow the client to get new access tokens without making the user sign in repeatedly. Scopes describe the extent of access being requested.

This matters because OAuth is about delegated authorisation. It is not primarily an authentication protocol. If you want a standardised way for an application to learn who the user is and verify identity claims, you normally add OpenID Connect on top. That distinction sounds technical, but it matters in business decisions. A tool that can "sign in with corporate identity" is not necessarily the same as a tool that should be allowed to read mailboxes, files or customer records afterwards.

Why it matters

OAuth matters because modern businesses run on connected applications. CRM platforms talk to email systems. Finance tools pull receipts from storage apps. Customer support platforms integrate with messaging, ticketing and analytics tools. AI assistants and workflow automations increasingly request access to calendars, documents, notes, repos, data platforms and help-desk APIs. In that world, a great deal of business risk is no longer in the password itself. It is in who has been authorised to act after sign-in.

Done well, OAuth is a big improvement over sharing passwords or embedding long-lived credentials in scripts. The user signs in only with the trusted identity platform, the application gets narrowly scoped tokens, and the resource server can enforce those permissions cleanly. That is exactly why OAuth became so important in SaaS and API ecosystems.

Done badly, however, OAuth can create a quiet form of shadow access. A staff member authorises a useful-looking app with broad scopes. The app keeps refresh tokens. The integration survives long after the original task is forgotten. Security and operations teams may not even realise the business has granted ongoing access to mail, files or customer data. In some cases, the app can continue to access data even after a password reset or MFA re-prompt, because the real issue is the permission already granted, not the user's current login session.

That is especially relevant for AI-enabled systems. If a retrieval tool, agent platform, connector hub or model-based assistant uses OAuth to reach internal systems, then the consent and scope model becomes part of information governance. Leaders need to know not just whether the AI tool "works", but what it can read, write, export, trigger or continue doing tomorrow without fresh scrutiny.

How it works

A common OAuth flow begins when the client application sends the user to the authorisation server. The request includes what is being asked for, such as scopes, who is asking, and where the user should be sent back after approval. That return location is the redirect URI. If the user approves, the authorisation server returns an authorisation code to the client at the registered redirect URI. The client then exchanges that code for tokens. The access token is used to call the resource server. If the system allows it, a refresh token can later be used to obtain new access tokens.

That description hides important security choices. First, the redirect URI must be tightly controlled. If an attacker can influence where the authorisation response goes, they may capture codes or tokens. Second, the scopes matter because they define what the connected application may do. "Read calendar" and "full mailbox access" are not minor wording differences. They are different risk profiles. Third, token handling matters. Bearer tokens are called bearer tokens for a reason: anyone holding the token may be able to use it unless extra controls are applied.

Modern best practice has moved away from older shortcuts. The authorisation code flow is preferred for many web, server-side, native and mobile scenarios. PKCE adds protection against authorisation code interception by binding the exchange to the original client instance. For native apps, using the system browser rather than embedded web views reduces phishing and credential-handling risks. Newer security extensions such as mutual TLS and DPoP aim to make stolen tokens less reusable by binding them to a client certificate or proof key rather than treating possession alone as enough.

For operators, the shortest accurate summary is this: OAuth turns access into a brokered process. The user or admin approves a defined request, the authorisation server issues time-bound credentials, and the resource server accepts those credentials if they are valid. The business control lives in the details: registration, redirect safety, token lifetime, scope design, refresh policy, consent policy and revocation discipline.

Examples

Imagine a sales team connecting a meeting assistant to Microsoft 365 so call notes can be attached automatically to calendars and shared records. The tool uses OAuth to request access to calendars, recordings and perhaps mail or files. If the scopes are narrow and the app is approved centrally, that can be a sensible productivity choice. If the app quietly requests broad read-write access to mailboxes and cloud storage for all users, the same connection becomes an information governance problem disguised as convenience.

Take a second example from internal automation. An operations team uses a no-code workflow tool to watch a support queue, create tasks in a project board and update a finance approval system. OAuth is what lets that tool act across APIs without storing staff passwords. But the meaningful question is not "does it use OAuth?" The meaningful question is "what scopes does it hold, how often are they reviewed, who approved them, and how quickly can they be revoked?"

A third example is mobile and native apps. A field service app needs staff to view schedules, upload reports and fetch customer account notes. OAuth is useful here because staff authenticate through the trusted identity service and the app receives tokens rather than reusable passwords. But if the mobile implementation uses insecure embedded sign-in instead of the user's browser, or if redirect URIs are poorly validated, the business can undermine the very controls it thought it was adopting.

A fourth example is AI connectors. A company allows an AI workspace to connect to shared drives, a ticketing system and a CRM through OAuth. The tool is promoted as helpful because it can summarise accounts, compare open issues and draft responses. In reality, the important choices are whether the scopes are read-only or read-write, whether refresh tokens persist after staff leave, whether the app can access all users' content or only delegated content, and whether administrators can see and revoke the grants. Without those answers, "AI integration" is just another name for delegated access with unclear boundaries.

There is also an incident example. A user is tricked into approving a malicious OAuth app that asks for mail and file permissions. The attacker does not steal the password. They do not need to beat MFA at login. Once consent is granted, the malicious app gains account-level access to data and normal remediation such as password reset may not remove that app's permissions. That is why OAuth governance is not merely a developer concern. It is part of business access control.

Common misunderstandings

The most common misunderstanding is that OAuth is an authentication protocol. It is not, at least not primarily. OAuth is about delegated authorisation to resources. OpenID Connect builds on OAuth to add identity claims and standard login information. If leaders mix these up, they can approve integrations without understanding whether the tool is merely letting a user sign in or is also asking to access company data.

A second misunderstanding is that consent screens are routine noise. They are not. A scope request is the business meaning of the integration. If the screen says an application can read mail, modify files or maintain access to your data, then that is a permission decision, not a decorative UI step.

Another misunderstanding is that OAuth avoids the need for MFA. In reality, the two controls operate at different layers. MFA may protect the user's sign-in to the authorisation server. OAuth then governs what the application can do after access is granted. A malicious or over-permissioned app can still be a problem after a perfectly successful MFA step.

There is also confusion around tokens. People assume "token-based" means secure by default. It does not. Bearer tokens are powerful precisely because possession may be enough to use them. That is why storage, transport security, expiry, sender-constraining and revocation matter.

Finally, many organisations assume integrations are harmless because they were added by a business user rather than built by developers. In practice, low-code tools, browser extensions, reporting plugins and AI assistants can all become shadow integrations if nobody reviews their permissions and ongoing access.

Risks and boundaries

The sharpest OAuth risk is over-broad permissioning. Scopes are often treated as implementation detail, but they are the boundary between "can read two items needed for this workflow" and "can read or alter a large part of the business estate". Poorly designed or poorly reviewed scopes create silent overreach.

Consent phishing is another important boundary. Instead of stealing passwords, attackers trick users into granting access to malicious cloud applications. Because the consent happens through a legitimate identity platform, users may trust the screen more than they should. Once granted, the application can gain account-level access to data, sometimes without the attacker ever needing an account in the organisation. Standard account remediation can be ineffective if the real problem is the app permission itself.

Refresh tokens deserve special attention. They improve usability because the user does not have to sign in constantly. They also create persistence. If refresh tokens are long-lived, poorly stored or weakly bound to the client, a compromise can last longer than leaders expect. That is why better practice includes tight lifetime policies, rotation, secure storage and, where appropriate, sender-constrained approaches such as mTLS or DPoP.

Redirect handling is another practical risk. If redirect URIs are loose, mismatched or easy to manipulate, attackers may intercept codes or responses. Native apps and mobile apps add complexity because they can involve device-specific URI handlers, browser choice and interception risks. That is why PKCE and browser-based authorisation matter.

Governance is the wider boundary. OAuth app registration, user consent policy, admin consent review, periodic grant review and rapid revocation all determine whether the framework is being used safely. A technically correct implementation can still be a governance failure if nobody can answer which third-party apps have access to business systems, what they can do, and who approved them.

For AI-enabled organisations, this becomes a strategic issue. Before allowing an AI tool or automation layer to connect through OAuth, leaders should ask four blunt questions. What exact data can it access? Can it write back or trigger actions? How long does access persist? Who can revoke it fast if the vendor, workflow or business need changes? If those answers are vague, the organisation is not approving productivity. It is approving opaque delegated access.

What to do next

First, build a view of connected applications. You need to know which SaaS tools, internal workflows, plug-ins, low-code automations and AI connectors currently hold OAuth permissions in your environment. If you cannot list them, you cannot govern them.

Second, classify apps by risk. Separate routine low-impact integrations from tools that can read personal data, finance data, customer records, source code, support tickets or internal knowledge. Review the scopes and consent model for the second group first. Broad read-write scopes, tenant-wide grants and persistent refresh access deserve immediate scrutiny.

Third, tighten who can approve what. Decide when user consent is acceptable, when admin consent is required, and what evidence should be reviewed before approval. For sensitive systems, consent should become a managed change, not a casual click-through.

Fourth, review token policy. Ask your teams and vendors about access-token lifetimes, refresh-token rotation, storage, revocation and whether sender-constrained options are supported for higher-risk use cases. Even if you do not deploy every advanced feature immediately, knowing which apps rely on unbound bearer tokens is useful risk intelligence.

Finally, add OAuth to your incident playbooks. A password reset is not a full response if a malicious or unnecessary app still holds valid permissions. Your teams should know how to inventory grants, identify risky applications, revoke access and confirm what the app could reach. That is especially important where AI tools or automations can move quickly across multiple systems once authorised.

FAQs

Is OAuth safe for AI tools and connectors?

It can be, but only if you treat the connector as an access decision rather than a product feature. Ask what scopes are requested, whether the tool can write as well as read, how long tokens persist, whether refresh access is controlled, and how grants are revoked. An AI tool using OAuth is not inherently safe or unsafe. It is a delegated access path that must be governed like any other.

Why is OAuth better than sharing passwords with integrations?

Because the application does not need the user's primary credentials. The user authenticates with the trusted identity platform, approves a defined request, and the application gets tokens representing that approved access. That is usually safer, more revocable and more auditable than embedding usernames and passwords in scripts or third-party tools. But the benefit only holds if scopes, token handling and app governance are under control.

If we already use SSO and MFA, do we still need to worry about OAuth?

Yes. SSO and MFA help verify the user at sign-in. OAuth decides what applications can do afterwards. A malicious or over-permissioned app can still gain ongoing access even when the original user login was protected properly. In many cloud estates, the highest-risk question is not "how did the user sign in?" but "what was the app allowed to keep doing after approval?"

Sources

‹ What is SAML? A practical guide to federation and enterprise single sign-on

What is a JWT? A practical guide to token claims, trust and validation ›