Entra ID Protocol Primer: OAuth, OIDC, and the Multi-Cloud Identity Decision

What changed

Journey of the Geek's Entra ID series has moved from identity basics into the protocol layer that decides how applications actually trust users, services, and APIs. The new installment focuses on OAuth 2.x and OpenID Connect, usually shortened to OIDC. That may sound like implementation detail, but for enterprises running across Microsoft Azure, AWS, Google Cloud, SaaS platforms, and internal applications, this is the layer where identity architecture succeeds or becomes expensive to unwind.

The key clarification is that OAuth is not an authentication protocol. OAuth is about authorization, specifically delegated access to a protected resource. OIDC adds the identity layer on top of OAuth so an application can understand who signed in and receive claims about that user. That distinction matters during cloud migrations because teams often treat any token-bearing login flow as equivalent. It is not equivalent. An access token, an ID token, a refresh token, a client credential, and an on-behalf-of token all carry different trust assumptions.

In Microsoft Entra ID, this maps directly to app registrations, redirect URIs, scopes, consent, claims, token validation, Microsoft Graph access, and downstream API design. The official Microsoft identity platform OIDC documentation describes the same core model: OIDC extends OAuth and uses ID tokens to let client applications verify a user's identity. Entra ID also publishes provider metadata through the standard /.well-known/openid-configuration endpoint, which lets applications discover authorization endpoints, token endpoints, supported claims, and signing keys.

The practical change for application teams is a shift away from thinking in product names and toward thinking in token contracts. If a workload moves from Entra ID to Amazon Cognito, from Cognito to Google Cloud Identity Platform, or from a custom IdP to Entra ID, the migration is not only a matter of changing a login screen. The application must validate a different issuer, often a different audience format, a different claim set, a different group or role model, and sometimes a different consent model. Those differences show up in code, infrastructure, support processes, and audit evidence.

The article's most useful technical framing is the split between authorization code flow and client credentials flow. Authorization code flow is the default pattern for user-delegated access. The user signs in, grants consent when needed, the application receives an authorization code, and the application exchanges that code for tokens. In modern designs, PKCE should be treated as table stakes, especially for public clients such as browser and mobile applications.

Client credentials flow is different. There is no human resource owner in the loop. A service authenticates as itself and receives a token for app-only access. That is the pattern for automation, data ingestion, daemon jobs, and service-to-service API calls. It is also where governance frequently weakens, because app-only permissions can become broad and persistent if secrets, certificates, managed identities, and workload identities are not rotated and reviewed.

Provider comparison

Microsoft Entra ID is strongest when identity is already centered on Microsoft 365, Azure, Windows endpoints, Conditional Access, Microsoft Graph, and enterprise governance. Entra's app registration model is mature and deeply integrated with Microsoft Graph permissions, enterprise applications, admin consent workflows, Conditional Access, managed identities, workload identity federation, and audit reporting. For organizations already licensing Microsoft 365 E3, E5, Entra ID P1, or Entra ID P2, the effective identity cost may be tied less to a single application and more to the broader enterprise agreement. Current plan details are maintained on the Microsoft Entra pricing page.

From a migration perspective, Entra ID is a good default for workforce identity when employees, contractors, and administrators already exist in the tenant. The friction comes when teams try to use Entra as a universal external customer identity layer without modeling tenant boundaries, guest accounts, consent, app ownership, and cross-tenant access. Claims can also surprise teams. Group claims may overrun token size limits, app roles may be a better fit than raw group membership, and Microsoft Graph scopes need careful admin consent management.

Amazon Cognito is more application-centric. It is often a good fit when the application is deployed primarily on AWS, needs managed sign-up and sign-in, or needs to federate with SAML and OIDC providers while keeping user pools close to the app stack. The Amazon Cognito user pool endpoints documentation separates user pool API authentication from the OAuth 2.0 authorization server model. That distinction is useful for architects because Cognito can act as a local user directory, a broker to external IdPs, and an OIDC provider for applications.

Cognito pricing is usage-oriented. AWS currently prices user pools by monthly active users across Lite, Essentials, and Plus tiers, with additional costs for items such as advanced security features, machine-to-machine authorization, higher request quotas, SMS, and email. The Amazon Cognito pricing page lists free tiers for Lite and Essentials, including 10,000 monthly active users for direct or social sign-in in many cases, while federated SAML or OIDC users are priced separately after a smaller free allowance. This model can be attractive for consumer applications with variable usage, but the cost model must include federation, SMS, email, threat protection, and request volume rather than only MAU.

Google Cloud Identity Platform is also application-focused, with a strong fit for teams building on Google Cloud, Firebase-adjacent stacks, or applications that need common consumer sign-in methods plus OIDC or SAML federation. The Google Cloud Identity Platform OIDC documentation shows how external OIDC providers can be added to web applications. Google prices Identity Platform largely by monthly active users, and its pricing page separates Tier 1 providers such as email, phone, anonymous, and social sign-in from Tier 2 providers such as OIDC and SAML. As of the referenced pricing page, Tier 1 includes a 50,000 MAU free tier, while OIDC and SAML federation are charged after 50 MAU at a listed rate of $0.015 per MAU. Phone and MFA messaging are charged separately.

The provider decision should not be reduced to token support, because all three can participate in OAuth and OIDC patterns. The real comparison is around operating model.

Entra ID favors centralized enterprise control. It fits organizations that want Conditional Access, privileged access management, Microsoft Graph integration, device signals, and workforce governance to shape application access. It is usually the strongest choice when the application is internal, partner-facing, or tightly connected to Microsoft 365 data.

Cognito favors AWS-native product teams that want an application-owned user pool, managed login, and federation without making the corporate directory the center of every customer identity decision. It can reduce build effort for AWS-hosted apps, but teams must understand Cognito-specific token formats, hosted UI behavior, app client settings, and pricing add-ons.

Google Cloud Identity Platform favors teams that want Google Cloud integration and Firebase-style identity patterns with support for social, email, phone, SAML, and OIDC providers. It can work well for digital products with mixed consumer and enterprise sign-in, but architects should model Tier 1 versus Tier 2 usage carefully because federation-heavy SaaS products price differently than consumer login flows.

There is also a protocol compatibility issue that does not show up on pricing pages. OAuth and OIDC are standards, but providers still differ in defaults and extensions. Microsoft uses the on-behalf-of flow for common multi-hop API delegation scenarios. Some platforms support token exchange patterns differently. Refresh token handling, claims mapping, key rotation, logout behavior, device code flow, consent prompts, and admin approval all vary. A migration plan that says, "OIDC is standard, so we can swap providers later," is too thin. The better plan is to define a provider-neutral identity contract inside the application: required claims, issuer validation, audience validation, role mapping, session duration, refresh behavior, and downstream API authorization rules.

Business impact

The business impact is that identity provider selection now affects cloud portability as much as compute, storage, and networking choices. Most organizations already know that databases create migration gravity. Identity creates a different kind of gravity. It reaches into user experience, audit trails, privileged administration, service credentials, customer support, compliance evidence, and incident response.

For a Microsoft-centered enterprise, Entra ID can lower governance overhead because identity controls sit close to existing policy. Conditional Access, MFA requirements, risk signals, group lifecycle, admin consent, enterprise app review, and audit data can be managed through a familiar operating model. The trade-off is that application teams must learn the Entra application model properly. Poorly scoped Graph permissions, unmanaged app secrets, broad admin consent, and token validation shortcuts create real risk. The protocol primer matters because it gives architects the vocabulary to challenge those designs before they reach production.

For an AWS-centered digital product, Cognito can be commercially efficient and technically convenient, especially when the application owns its users and does not need every account to exist in a corporate directory. Pricing by monthly active users is easier to align with product usage than per-employee licensing. The trade-off is that Cognito becomes part of the product architecture. Migration later requires user export planning, password reset strategy, redirect URI changes, app client replacement, claim mapping, customer communication, and new support runbooks.

For Google Cloud and Firebase-style application teams, Google Cloud Identity Platform can be a strong identity layer when customer sign-in methods are varied and product usage drives spend. Its MAU model can be attractive at lower and mid-scale usage, especially for Tier 1 sign-in methods. The cost story changes when the application is enterprise-heavy and most users arrive through OIDC or SAML federation. In that case, the architect should forecast federated MAU, SMS traffic, MFA adoption, and tenant count before committing.

Migration planning should start with application inventory, not provider configuration. For each application, document whether it is a confidential client or public client, which redirect URIs are registered, which scopes are requested, which APIs consume access tokens, which claims are required, where sessions are stored, and how refresh tokens are protected. Then map those requirements to the target provider. This is slower than clicking through a console, but it prevents the common failure mode where login works in a test browser while authorization fails in downstream APIs, background jobs, mobile clients, or partner tenants.

Security review should focus on five controls. First, use authorization code flow with PKCE for interactive sign-in unless there is a specific reason not to. Second, validate tokens with provider metadata and signing keys rather than hard-coded assumptions. Third, separate ID token use from access token use. An ID token starts an application session. An access token authorizes access to an API. Fourth, minimize scopes and app-only permissions, especially for Microsoft Graph and management APIs. Fifth, treat client secrets like production credentials, and prefer certificates, managed identities, or workload identity federation where the platform supports them.

Cost review should be done with usage profiles. Workforce apps often map better to per-user enterprise licensing because the user base is known and governance features matter. Consumer apps often map better to MAU pricing because usage fluctuates. B2B SaaS sits in the middle. A SaaS provider with many enterprise customers may pay more for federated OIDC or SAML users than expected, while also needing tenant-aware claims, admin consent, customer-specific IdP metadata, and support for certificate rotation. That is where architecture and finance need the same model.

The larger strategic lesson is that OAuth and OIDC are not just developer topics. They are the common language for multi-cloud identity. Once leaders understand the difference between delegated access, app-only access, ID tokens, access tokens, scopes, and claims, provider comparisons become clearer. Entra ID, Cognito, and Google Cloud Identity Platform can all issue tokens. The decision is about where trust should live, how governance should operate, how costs scale, and how much migration flexibility the business needs later.

For most enterprises, the best answer is not a single identity provider for every scenario. A practical model is to use Entra ID as the workforce authority, use cloud-native identity services where they fit product architecture, and standardize application authorization contracts so tokens from any provider are handled deliberately. That gives teams room to build on the right cloud service without turning every login flow into a one-off security design.