OAuth 2.0 Flows and MSAL Library

OAuth 2.0 is an authorization framework defined in RFC 6749 that enables third-party applications to obtain limited access to an HTTP service on behalf of a resource owner. It separates authentication from authorization: the resource owner (user) authenticates to an authorization server, which issues an access token that the client application presents to the resource server. The token is a bearer token—any party in possession of it can use it. This is why tokens must be kept confidential and have limited lifetimes.

// MSAL.NET for mobile app using Authorization Code + PKCE
IPublicClientApplication app = PublicClientApplicationBuilder
    .Create(clientId)
    .WithRedirectUri("msal{clientId}://auth")
    .Build();

AuthenticationResult result = await app.AcquireTokenInteractive(scopes)
    .WithPrompt(Prompt.SelectAccount)
    .ExecuteAsync();
string accessToken = result.AccessToken;

#### For Confidential Clients (Web App):

// MSAL.NET for web app using Authorization Code flow
IConfidentialClientApplication app = ConfidentialClientApplicationBuilder
    .Create(clientId)
    .WithClientSecret(clientSecret)
    .WithRedirectUri(redirectUri)
    .Build();

AuthorizationCodeReceived = async (context) =>
{
    AuthenticationResult result = await app.AcquireTokenByAuthorizationCode(scopes, context.AuthorizationCode)
        .ExecuteAsync();
};

#### For Daemon Services:

// MSAL.NET using Client Credentials flow
IConfidentialClientApplication app = ConfidentialClientApplicationBuilder
    .Create(clientId)
    .WithClientSecret(clientSecret)
    .Build();

AuthenticationResult result = await app.AcquireTokenForClient(scopes)
    .ExecuteAsync();

#### For On-Behalf-Of:

// Middle-tier API exchanging incoming token for downstream token
UserAssertion userAssertion = new UserAssertion(incomingToken);
AuthenticationResult result = await app.AcquireTokenOnBehalfOf(scopes, userAssertion)
    .ExecuteAsync();

A large enterprise has a front-end web app (Angular SPA) that calls a middle-tier Web API (ASP.NET Core), which then calls Microsoft Graph to read user profiles. The SPA uses MSAL.js with the Authorization Code + PKCE flow to get an access token for the middle-tier API. The middle-tier API receives this token and uses the OBO flow (via MSAL.NET's AcquireTokenOnBehalfOf) to exchange it for a token to Microsoft Graph. This ensures the user's identity flows through the entire chain, and the middle-tier never stores user credentials. Performance considerations: token exchange adds latency (~100-200ms per call), so the middle-tier should cache the downstream token. Common misconfiguration: the middle-tier API must be registered in Azure AD with the oauth2AllowImplicitFlow set to false (it should use authorization code) and must have the required API permissions for Graph. If the downstream token expires, the middle-tier must handle MsalUiRequiredException gracefully—typically by returning 401 to the client, which then re-acquires a fresh token interactively.

A background service (Windows Service or Azure Function) needs to access Microsoft Graph to read all user mailboxes for compliance reporting. This is a server-to-server scenario with no user interaction. The service uses the Client Credentials flow. It is registered as a confidential client in Azure AD with a client secret stored in Azure Key Vault. The app registration has Application Permissions (e.g., Mail.Read.All) granted by an admin. The service calls AcquireTokenForClient with scopes like https://graph.microsoft.com/.default (which requests all app permissions). The token is cached and refreshed automatically by MSAL. Key considerations: the client secret must be rotated periodically; using a certificate instead of a secret is more secure and recommended for production. If the service runs at scale (thousands of requests per minute), ensure the token cache is thread-safe (MSAL handles this). Common mistake: using delegated permissions (User.Read) instead of app permissions (User.Read.All)—the former requires a user context and will fail.

A consumer-facing mobile app (Xamarin) allows users to sign in with their Microsoft account or Azure AD credentials. The app uses MSAL with the Authorization Code + PKCE flow. The redirect URI is set to a custom scheme (e.g., myapp://auth). The app requests scopes like User.Read and Mail.Send. MSAL opens the system browser for authentication. After the user authenticates, the app receives an access token and caches it. If the token expires, AcquireTokenSilent attempts to refresh. If the user changes their password or revokes consent, MsalUiRequiredException is thrown, and the app re-initiates interactive login. Common pitfalls: incorrect redirect URI (must match exactly, including case and trailing slashes), missing kSecAttrAccessGroup on iOS for keychain sharing, and not handling the broker (Microsoft Authenticator) on Android for single sign-on. The app should also handle the case where the user cancels the authentication.