Azure B2C中移动应用为何优先选用OAuth 2.0而非OpenID Connect？

Great question! Let’s break down the reasoning behind these recommendations—they tie directly to each protocol’s core design goals and the unique security/usage needs of different application types.

For Server-Hosted Web Apps: OpenID Connect (OIDC) is the Natural Fit #

• OIDC prioritizes identity authentication: Unlike OAuth 2.0, which focuses on authorization (letting apps access user resources), OIDC’s main job is verifying who a user is. Web apps often need to render personalized UI, enforce access controls, or link actions to a specific user—OIDC delivers an ID Token right after login, packed with standardized identity claims (email, name, user ID, etc.) that you can use immediately without extra API calls.
• Secure token handling for server-side environments: Web apps have a trusted backend that can safely store sensitive tokens (like refresh tokens). OIDC’s Authorization Code Flow is built for this scenario: the authorization code is sent to your backend first, which then exchanges it for tokens. This keeps tokens out of the browser’s front-end, reducing exposure to XSS or other client-side attacks.
• Browser-native user experience: OIDC relies on redirects between your app, Azure AD B2C, and back—this is a seamless flow for browser users, who’re already familiar with being sent to a trusted login page and redirected back to the app they were using.

For Mobile/Desktop Apps: OAuth 2.0 is Optimized for Their Unique Constraints #

• Mobile/desktop apps are "public clients": Unlike web apps, they don’t have a secure backend to store a client secret. OAuth 2.0’s Authorization Code Flow with PKCE (Proof Key for Code Exchange) fixes this gap: PKCE adds a cryptographically generated key that stops attackers from intercepting and reusing authorization codes, keeping the flow secure even without a secret.
• Core need is resource access: Mobile/desktop apps typically exist to interact with APIs (your backend, Microsoft Graph, etc.) rather than render server-side UI. OAuth 2.0’s Access Token is specifically designed to grant access to these protected resources—this aligns perfectly with the primary use case of these apps. While you can still get identity info via OIDC extensions, Azure AD B2C recommends sticking to OAuth 2.0 because it’s the most streamlined approach for resource access.
• Better fit for native app interactions: Native apps use system browsers or embedded web views for authentication. OAuth 2.0’s flow (with PKCE) is optimized for these environments, avoiding pitfalls like token storage in insecure locations (e.g., shared browser cookies) and ensuring the authentication process works smoothly across different mobile OSes and desktop platforms.

A quick side note: OIDC is actually an extension of OAuth 2.0, so there’s overlap—but Azure AD B2C’s recommendations are about picking the protocol that aligns best with your app’s primary needs and security model.

内容的提问来源于stack exchange，提问作者frigon