OAuth 2.0

The security protocol that powers "Sign in with Google" — and underpins every secure API connection in modern enterprise technology.

Over 85% of web and mobile applications use OAuth 2.0 for authentication and authorisation, making it the most widely deployed security protocol on the internet. For enterprises, OAuth 2.0 is the foundation of every integration between your SaaS tools, every API your developers build, and every "single sign-on" experience your employees and customers use. Misconfigured OAuth implementations are also responsible for approximately 15% of all data breaches involving application programming interfaces, costing affected organisations an average of $4.5 million per incident. Understanding OAuth 2.0 is essential for every business leader responsible for digital security.

What It Is

OAuth 2.0 is an open standard for access delegation — a protocol that allows a user to grant a third-party application limited access to their data on another service, without sharing their password. When you use "Sign in with Google" to access a new application, OAuth 2.0 is working behind the scenes: it lets the new application request your identity information from Google, and Google asks you whether you approve. Your password never reaches the third-party application. Think of it as a hotel key card system: the front desk (the authorisation server) verifies your identity and issues a key card (an access token) that opens specific doors (specific data or functions) for a limited time. The key card does not give you access to the hotel's master keys, and it expires when you check out.

OAuth 2.0 separates authentication (who are you?) from authorisation (what are you allowed to do?). It issues tokens — short-lived digital credentials — that grant specific permissions for specific periods. A calendar application might receive a token that lets it read your Google Calendar events for the next hour, after which the token expires and must be refreshed. This token-based approach is far more secure than sharing passwords because tokens can be revoked instantly, have limited scope, and expire automatically.

Since its standardisation in 2012 (RFC 6749), OAuth 2.0 has become the universal language of API security. Every major platform — Google, Microsoft, Apple, Facebook, Salesforce, GitHub — implements OAuth 2.0. The protocol works alongside OpenID Connect (which adds a standard identity layer on top of OAuth 2.0) to provide both authentication and authorisation in a unified framework. In enterprise contexts, OAuth 2.0 is the mechanism that enables single sign-on (SSO), API integrations between SaaS platforms, and secure machine-to-machine communication.

Why It Matters for Business

OAuth 2.0 is the enabler of the modern SaaS ecosystem. Without it, every integration between your CRM, marketing automation, analytics, and collaboration tools would require sharing credentials or building custom security mechanisms — a practical impossibility at scale. When your marketing team connects HubSpot to Salesforce, or your finance team integrates Stripe with your ERP system, OAuth 2.0 provides the secure, standardised handshake that makes these connections possible. The protocol enables the average enterprise to manage over 370 SaaS integrations securely, something that would be operationally unfeasible without a standardised authorisation framework.

Security is the critical business consideration. While OAuth 2.0 is fundamentally sound, its implementation is complex and error-prone. The protocol defines several "flows" (grant types) for different scenarios, and choosing the wrong flow can expose your organisation to attacks. The most common vulnerability is the use of the "Implicit Grant" flow — now deprecated but still found in legacy applications — which can leak access tokens through browser URLs. More sophisticated attacks, such as authorisation code interception and token theft, require careful implementation of security controls including Proof Key for Code Exchange (PKCE) and strict redirect URI validation.

Regulatory compliance increasingly mandates OAuth 2.0 or equivalent token-based security. The Financial Grade API (FAPI) standard, built on OAuth 2.0, is required for open banking implementations in the UK (under the CMA Open Banking mandate), the EU (under PSD2), and Australia (under the Consumer Data Right). Healthcare APIs under HIPAA and HL7 FHIR also leverage OAuth 2.0 for patient data access. Organisations that fail to implement OAuth 2.0 correctly risk both security breaches and regulatory non-compliance.

Enterprise Use Cases

Salesforce's entire API ecosystem is secured through OAuth 2.0, enabling over 5 million developers and thousands of integration partners to access customer data securely. When a company like DocuSign integrates with Salesforce to automatically send contracts when deals reach a certain stage, OAuth 2.0 ensures that DocuSign receives only the specific data permissions the customer has granted — and the customer can revoke those permissions at any time without changing their Salesforce password. Microsoft Azure Active Directory (now Entra ID) uses OAuth 2.0 to provide single sign-on for over 500 million users across Microsoft 365, Dynamics 365, and thousands of third-party SaaS applications.

In financial services, the UK Open Banking initiative requires all regulated financial institutions to expose APIs secured with OAuth 2.0 and FAPI profiles. This enables consumers to share their banking data with authorised fintech apps (such as budgeting tools and mortgage comparison services) without sharing their banking credentials. Since its 2018 launch, UK Open Banking has grown to over 9 million users, with OAuth 2.0 providing the security foundation that gives consumers confidence their financial data is shared safely.

GitHub uses OAuth 2.0 to secure its integrations ecosystem, allowing tools like CircleCI, Slack, and Jira to access repository data on behalf of developers. The fine-grained permission model means a CI tool can be authorised to read code and write build statuses, but cannot modify repository settings or delete code — a critical security boundary for organisations managing proprietary source code.

Vendor Landscape

Identity providers that implement OAuth 2.0 include Auth0 (acquired by Okta for $6.5 billion), which is the most popular dedicated identity platform for developers, with pricing from $240 per month for up to 10,000 active users to enterprise contracts exceeding $200,000 annually. Okta's core product provides enterprise-grade identity management with OAuth 2.0 support, with per-user pricing typically ranging from $2-8 per month. Microsoft Entra ID (formerly Azure AD) is included with Microsoft 365 subscriptions and serves as the default identity provider for most Microsoft-centric enterprises. Google Identity Platform, AWS Cognito, and Firebase Authentication offer OAuth 2.0 capabilities with generous free tiers suitable for startups and small businesses. For organisations requiring on-premises or self-hosted solutions, Keycloak (open-source, backed by Red Hat) and WSO2 Identity Server provide enterprise-grade OAuth 2.0 implementation without vendor lock-in.

Strategic Considerations

Standardise on a single identity provider across your organisation rather than allowing each application team to implement OAuth 2.0 independently. A centralised identity platform reduces security risk, simplifies user management, and provides consistent auditing and compliance reporting. Ensure your development teams understand the different OAuth 2.0 grant types and use the appropriate one for each scenario: Authorisation Code with PKCE for web and mobile applications, Client Credentials for machine-to-machine communication, and Device Code for IoT and input-constrained devices. Never use the Implicit Grant or Resource Owner Password Credentials flows — both are deprecated and represent significant security risks. Implement comprehensive token lifecycle management, including short-lived access tokens (15-60 minutes), secure refresh token storage, and automated revocation capabilities. Finally, audit your OAuth 2.0 implementations regularly; third-party integrations granted excessive permissions are a common attack vector that can expose your organisation to data breaches.