Have you ever clicked “Sign in with Google,” “Sign in with Microsoft,” or connected one application to another without giving the application your password? There is a good chance OAuth 2.0 was involved.
OAuth 2.0 is an authorization framework that allows applications to access specific resources on behalf of a user without requiring the application to know or store the user’s password. It is widely used across cloud applications, mobile apps, APIs, SaaS platforms, and enterprise Identity and Access Management (IAM) environments.
For anyone working with Microsoft Entra ID, Okta, SSO, APIs, cloud security, or IAM, understanding OAuth 2.0 is an important foundation.
What Is OAuth 2.0?
OAuth 2.0 stands for Open Authorization 2.0. It provides a standardized way for an application to obtain limited access to a protected resource. Think of OAuth 2.0 like a temporary access badge.
Your password is similar to a master key. You would not normally give that master key to every application that needs access to one room. Instead, OAuth allows you to authorize an application to receive a limited credential, an access token that can be used to access specific resources according to the permissions granted.
For example, imagine a calendar application wants to access your Google Calendar. Instead of asking for your Google password, the application sends you to Google’s authorization service. You authenticate with Google, review the permissions being requested, and approve them.
Google then issues an access token that the application can use to access the authorized calendar resources. The application does not need your Google password.
The Four Main Roles in OAuth 2.0
OAuth 2.0 involves four primary roles:
| Role | Description | Example |
|---|---|---|
| Resource Owner | The person or entity that owns the data | Employee or customer |
| Client Application | The application requesting access | Calendar application |
| Authorization Server | Authenticates the user and issues tokens | Microsoft Entra ID, Google, Okta |
| Resource Server | Hosts the protected data or API | Microsoft Graph, Google Calendar API |
How OAuth 2.0 Works
The basic process is straightforward. The user asks an application to access certain information. The application redirects the user to the authorization server. The user authenticates and reviews the requested permissions. If the user approves, the authorization server provides the appropriate authorization result and, depending on the OAuth flow, an access token. The application then uses that token when communicating with the resource server. The resource server validates the token and determines whether the requested operation is permitted.
A simplified flow looks like this:
User → Application → Authorization Server → Access Token → Resource Server
The important point is that the application does not need to receive the user’s password.
Access Tokens and Scopes
An access token is a credential that allows an application to access a protected resource. Instead of repeatedly sending a username and password to an API, the application sends the access token.
Access tokens can be limited by factors such as expiration and permissions. This helps reduce the potential impact if a token is compromised.
Scopes define what an application is allowed to access. For example, an application might request permission to read a user’s profile, access a calendar, read files, or send email.
Scopes support the principle of least privilege, meaning an application should receive only the permissions it actually needs.
For example:
Application: “I need permission to read your calendar.”
User: “Approved.”
Access Token: “Calendar read access.”
The application does not automatically receive unrestricted access to everything in the user’s account.
OAuth 2.0 Is Not Authentication
One of the most important things to understand is that OAuth 2.0 is primarily an authorization framework, not an authentication protocol.
Authentication answers:
“Who are you?”
Authorization answers:
“What are you allowed to access?”
OAuth 2.0 primarily addresses authorization. When an application needs to authenticate a user and obtain standardized identity information, OpenID Connect (OIDC) is commonly used. OIDC is an identity layer built on top of OAuth 2.0.
This distinction is important for anyone working with IAM, SSO, Microsoft Entra ID, Okta, and cloud security.
OAuth 2.0 vs. OIDC vs. SAML
| Technology | Primary Purpose | Common Use |
|---|---|---|
| OAuth 2.0 | Authorization and delegated access | APIs and application integrations |
| OpenID Connect (OIDC) | Authentication and identity | Modern web and mobile application sign-in |
| SAML | Authentication and federation | Enterprise and workforce SSO |
A simple way to remember the difference is:
OAuth 2.0: What can this application access?
OIDC: Who is this user?
SAML: How can an application authenticate and receive information about this user?
OAuth 2.0 and API Security
Modern applications rely heavily on APIs to communicate with other applications and services. OAuth 2.0 provides a standardized way for applications to obtain authorization to access protected APIs.
A typical process looks like:
Application → Authorization → Token → API → Protected Resource
The API validates the token and determines whether the application has the required permissions.
This makes OAuth 2.0 an important technology in API security, cloud computing, SaaS, mobile applications, microservices, IAM, and Zero Trust architectures.
Why OAuth 2.0 Matters
OAuth 2.0 helps organizations provide controlled and limited access to protected resources without requiring users to share their passwords with every application.
Instead of giving an application unrestricted access to an account, users can authorize specific permissions. Access tokens can also be limited by scope and lifetime, providing greater control over how applications interact with protected resources.
Whether you use Microsoft 365, Google Workspace, Salesforce, mobile applications, or cloud APIs, OAuth 2.0 is likely working behind the scenes.
OAuth 2.0 allows an application to access protected resources on your behalf without requiring you to give the application your password.
For professionals working in IAM, Microsoft Entra ID, Okta, SSO, API security, cloud security, or cybersecurity, understanding OAuth 2.0 is fundamental. Once you understand authorization servers, clients, resource servers, access tokens, scopes, OIDC, and SAML, modern identity and access architectures become much easier to understand.