Skip to article
Identity Authentication

OAuth 2.0

OAuth 2.0 is the system many Azure applications use to get permission to call an API without handing a password to that API. The application sends a user or workload through a trusted Microsoft identity flow, receives an access token, and presents that token to the resource. In practice, OAuth 2.0 explains why app registrations, scopes, consent prompts, redirect URIs, client secrets, certificates, and managed identities all show up when teams secure Azure-hosted applications.

Source: Microsoft Learn - Microsoft identity platform and OAuth 2.0 authorization code flow Reviewed 2026-05-17

Exam trap
Confusing OAuth 2.0 authorization with OpenID Connect sign-in and then validating the wrong token type in an API.
Production check
Can you identify the app registration, service principal, tenant, requested scopes, token audience, and API that participate in the flow?
Practice this topic Microsoft Learn
Article details and learning context
Aliases
None listed
Difficulty
fundamentals
CLI mappings
5
Last verified
2026-05-17
Learning paths Learn AZ-204 Azure Developer application path OAuth 2.0
Compare related concepts Search related resources Browse the glossary

Understand the concept

Why it matters

OAuth 2.0 matters because access failures and security incidents often come from misunderstood token flows rather than broken code. A web app might request the wrong scope, a daemon might use a secret that expired, or an API might accept a token meant for another audience. Good OAuth design keeps users from sharing passwords, lets administrators grant and revoke application permissions, and supports least-privilege access to APIs. It also gives developers a common vocabulary for redirect URIs, claims, scopes, consent, and token lifetimes. Without that vocabulary, teams overgrant permissions, misread sign-in errors, and build brittle integrations that fail during deployment or incident response.

Official wording and source

OAuth 2.0 is the authorization framework used by the Microsoft identity platform to let applications request access tokens for protected resources. In Azure, app registrations, scopes, consent, redirect URIs, credentials, and token flows shape how users or workloads access APIs.

Open Microsoft Learn

Technical context

In Azure architecture, OAuth 2.0 sits in the identity and application access layer, mainly through the Microsoft identity platform and Microsoft Entra ID. It supports flows such as authorization code, client credentials, device code, and on-behalf-of patterns. The control plane objects are app registrations, service principals, permissions, credentials, and consent grants. The runtime data-plane artifact is the token presented to a protected API. OAuth decisions also intersect with Azure RBAC, API Management, managed identities, and conditional access policies.

Exam context

AZ-204 Developing Solutions for Microsoft Azure

Compare with

Token OpenID Connect

Where it is used

Where you see it

  1. In Microsoft Entra app registrations, OAuth 2.0 appears around redirect URIs, supported account types, client secrets, certificates, API permissions, exposed scopes, and authentication settings.
  2. In application logs and sign-in events, OAuth errors appear as invalid audience, missing consent, expired credential, redirect mismatch, invalid scope, or token validation failure during incidents.
  3. In Azure CLI or deployment pipelines, the term appears when scripts create service principals, assign roles, configure federated credentials, or securely request tokens for automation.

Common situations

  • Secure web applications, APIs, daemons, and automation with token-based access.
  • Troubleshoot scopes, audiences, consent, redirect URIs, and credential expiration.
  • Replace shared secrets or passwords with identity platform flows and managed credentials.
  • Document which applications can call protected APIs and under which permissions.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Securing a university research API Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Cedar Valley University hosted a research data API for climate-model collaborators. The old integration used shared API keys, making it hard to revoke one lab without disrupting everyone.

Goals
  • Replace shared keys with identity-based API access.
  • Support delegated user access for researchers.
  • Limit each lab to approved datasets and scopes.
  • Reduce emergency credential resets during semester deadlines.
Approach using OAuth 2.0

The development team registered the API and client applications in Microsoft Entra ID, defined OAuth scopes for read, upload, and export actions, and moved web clients to the authorization code flow through MSAL. API code validated issuer, audience, signature, tenant, and scope claims before returning data. Lab managers requested admin-approved permissions through a documented onboarding path, while automation jobs used separate confidential clients with certificate credentials. Azure CLI exported app owners, service principals, and role assignments for review. Application Insights captured correlation IDs and token validation errors without logging token values. A test tenant simulated consent removal, expired certificates, and invalid audience claims so support staff could practice troubleshooting before production rollout.

Potential outcomes
  • Shared API keys were removed from all active integrations.
  • Access revocation for one lab dropped from two days to under 30 minutes.
  • Unauthorized export attempts were blocked by missing scope claims.
  • Credential-reset tickets fell by 46% during the next semester.
What to learn

OAuth 2.0 turns API access into reviewable identity configuration instead of a collection of risky shared secrets.

Scenario 02 Replacing secrets in a logistics automation pipeline Scenario, objectives, solution, measured impact, and takeaway.
Scenario

BlueRoute Logistics deployed routing updates from GitHub Actions into Azure. Several pipelines used long-lived client secrets that expired unpredictably and created release-night outages.

Goals
  • Remove stored client secrets from deployment workflows.
  • Keep least-privilege access to Azure subscriptions.
  • Improve release reliability for nightly route optimization jobs.
  • Create auditable evidence for pipeline identity usage.
Approach using OAuth 2.0

The platform team reviewed OAuth 2.0 client credential usage for each pipeline service principal. Instead of rotating another set of secrets, they configured federated identity credentials on the app registrations so GitHub Actions could exchange trusted workload assertions for Microsoft identity platform tokens. Azure CLI verified service principal object IDs, role assignment scopes, and credential metadata. Each deployment job received only the roles needed for its resource group. Sign-in logs and pipeline run IDs were correlated in a workbook so responders could trace token issuance to a specific workflow. The old secrets were disabled after two successful release cycles and a rollback rehearsal.

Potential outcomes
  • Nine long-lived client secrets were removed from production pipelines.
  • Deployment failures caused by expired credentials dropped to zero over 90 days.
  • Role assignment scope shrank from subscription-wide to resource-group level for six workflows.
  • Audit preparation time for pipeline identity evidence fell by 60%.
What to learn

OAuth 2.0 is safer and more reliable when workload identities use federation instead of unattended shared secrets.

Scenario 03 Fixing token audience failures in a media app Scenario, objectives, solution, measured impact, and takeaway.
Scenario

LumaStream added a mobile companion app that called an Azure-hosted recommendations API. Users could sign in, but API calls failed intermittently with confusing authorization errors.

Goals
  • Identify why valid sign-ins still produced API failures.
  • Separate client sign-in from API authorization checks.
  • Reduce mobile release rollback risk.
  • Document token troubleshooting for support engineers.
Approach using OAuth 2.0

Engineers discovered the mobile app requested tokens for a general sign-in audience instead of the recommendations API. The API accepted some tokens because validation checked signature but not the expected audience and scopes consistently. The team updated app registration settings, exposed the correct API scope, revised MSAL configuration in the mobile client, and hardened API token validation. Azure CLI and Microsoft Entra logs confirmed client IDs, service principal IDs, scopes, and consent records. A safe logging pattern captured request IDs, issuer, audience, and scope names without storing bearer tokens. The release pipeline added an integration test that requests a token and calls a protected endpoint before deployment approval.

Potential outcomes
  • Authorization-related mobile errors fell by 82% in the next release.
  • API validation blocked tokens with incorrect audiences in preproduction tests.
  • Rollback events for the recommendations API dropped from three per quarter to none.
  • Support engineers gained a five-step token evidence checklist.
What to learn

OAuth 2.0 troubleshooting succeeds when teams validate the token’s audience and scope, not just the user’s successful sign-in.

Azure CLI

Azure CLI is useful because OAuth 2.0 problems often involve several objects that are painful to compare by clicking: app registrations, service principals, role assignments, owners, and credentials. CLI output can prove the client ID, object ID, tenant, scopes, and assignments that a workload actually uses. It also supports repeatable reviews before credential rotation or permission changes.

Useful for

  • List app registrations or service principals to confirm the client ID, display name, tenant ownership, and object ID used by an application.
  • Inspect role assignments for a service principal or managed identity before deciding whether an OAuth-protected API failure is authorization-related.
  • Create or review federated credentials for CI/CD so pipelines can request tokens without storing long-lived client secrets.
  • Export owners, credentials, and assignments for access reviews, incident response, or preproduction validation.

Before you run a command

  • Confirm the tenant, subscription, target application, service principal, resource scope, and whether you are reviewing delegated or application permissions.
  • Avoid creating credentials or role assignments until the approval path is clear, because OAuth changes can immediately widen production access.
  • Check whether Azure CLI is using the expected account and tenant, especially when troubleshooting multitenant apps or guest-user sessions.
  • Use JSON output for evidence exports and protect token or secret values; never paste access tokens into tickets or shared chat channels.

What the output tells you

  • Client IDs identify applications, while object IDs identify the tenant-specific directory object that receives assignments, credentials, or ownership changes.
  • Role assignment output shows scope, role definition, principal ID, and principal type, which explain what a token-bearing identity may access.
  • Credential and federated identity output reveals expiration, issuer, subject, and trust configuration that can break automated token acquisition.
  • Tenant IDs, app owners, and service principal properties help distinguish a platform issue from a misconfigured registration or stale enterprise application.

Mapped commands

Term-specific Azure CLI evidence workflow

adjacent 
az ad app show --id <client-id>
az ad appdiscoverIdentity
read-only Microsoft Learn 
az ad sp show --id <client-id-or-object-id>
az ad spdiscoverIdentity
read-only Microsoft Learn 
az role assignment list --assignee <principal-id> --all --output table
az role assignmentdiscoverIdentity
read-only Microsoft Learn 
az ad app federated-credential list --id <app-object-id>
az ad app federated-credentialdiscoverIdentity
read-only Microsoft Learn 
az account get-access-token --resource <resource-uri>
az accountsecureIdentity
security-impacting Microsoft Learn

Architecture context

In Azure architecture, OAuth 2.0 sits in the identity and application access layer, mainly through the Microsoft identity platform and Microsoft Entra ID. It supports flows such as authorization code, client credentials, device code, and on-behalf-of patterns. The control plane objects are app registrations, service principals, permissions, credentials, and consent grants. The runtime data-plane artifact is the token presented to a protected API. OAuth decisions also intersect with Azure RBAC, API Management, managed identities, and conditional access policies.

Security
Security impact is direct and high. OAuth 2.0 controls how applications obtain tokens and how APIs decide whether to trust them. Weak design can expose client secrets, allow excessive scopes, accept tokens from the wrong tenant, or let abandoned app registrations retain access. Strong design uses supported libraries, short-lived access tokens, certificate or federated credentials for confidential clients, redirect URI hygiene, least-privilege API permissions, admin consent review, and Conditional Access where applicable. Operators should distinguish authentication from authorization: a valid token only proves the issuing identity platform and requested claims. The application must still validate issuer, audience, signature, scopes, roles, and tenant expectations.
Cost
OAuth 2.0 is not billed as a separate Azure resource in most application flows, but it has real indirect cost. Poorly designed identity integration consumes engineering time, slows releases, causes incident escalations, and may force emergency consulting or security remediation. Overly broad permissions increase audit effort and risk exposure, while short secret lifetimes without automation create avoidable outages. Some related capabilities, such as premium Conditional Access, identity governance, logging retention, or API Management, can affect licensing or service spend. FinOps and platform teams should track identity operational effort, duplicate app registrations, unused service principals, and manual credential rotation work as part of application ownership.
Reliability
Reliability depends on OAuth 2.0 because expired secrets, bad redirect URIs, missing consent, clock skew, tenant changes, and invalid scopes can stop applications even when compute and networking are healthy. Token acquisition is often a shared dependency for web apps, APIs, background jobs, mobile clients, and automation. Reliable designs use managed identity where possible, rotate credentials before expiration, monitor sign-in and token errors, document required permissions, and test flows in every deployment slot or environment. Rollback plans should include identity configuration, not only application binaries. When outages occur, teams need enough logs to separate identity platform errors from API authorization decisions.
Performance
OAuth 2.0 performance impact is mostly about token acquisition, validation, and dependency behavior. A well-built application caches tokens appropriately, validates them quickly, and avoids calling the identity platform for every request. A poor design can add latency, throttle token endpoints, or create startup delays when many instances request tokens at once. API performance also depends on efficient claim validation and avoiding oversized tokens with unnecessary group or role claims. For operators, diagnostic performance matters too: clear sign-in logs, correlation IDs, and predictable token lifetimes help teams resolve authentication problems quickly. The goal is secure access without turning identity into a bottleneck.
Operations
Operators inspect OAuth 2.0 through app registrations, enterprise applications, service principals, consent records, sign-in logs, API permissions, redirect URI settings, and Azure CLI or Microsoft Graph queries. Operational work includes reviewing owners, checking credential expiration, validating tenant and audience, exporting role assignments, and documenting which applications can call which APIs. Changes should be treated like production access changes because updating a redirect URI, scope, secret, certificate, or permission can break sign-in or widen access. Good runbooks show how to reproduce token acquisition, decode claims safely, correlate request IDs, and verify that a deployment uses the intended client ID and tenant.

Common mistakes

  • Confusing OAuth 2.0 authorization with OpenID Connect sign-in and then validating the wrong token type in an API.
  • Using the application client ID where Azure RBAC expects the service principal object ID, causing role assignment failures or wrong access.
  • Storing long-lived client secrets in app settings or pipelines instead of using managed identity, certificates, Key Vault, or workload federation.
  • Granting broad application permissions to fix an incident quickly and then leaving the overprivileged consent in place after recovery.