OAuth

OAuth 2.0 is the open authorisation standard that underlies modern authentication in Microsoft Entra ID, Microsoft 365, and most modern cloud services. OAuth doesn't authenticate users directly — that's OpenID Connect (OIDC), layered on top — but it standardises how applications obtain access tokens to call APIs on behalf of users (delegated) or themselves (application). Tokens are bearer credentials with scoped permissions and limited lifetimes, refreshed via refresh tokens without re-prompting the user. Every modern Microsoft 365 sign-in is OAuth under the hood. Compared to older protocols like SAML, OAuth is leaner (JSON over HTTPS), better for mobile and SPAs, and the foundation for API-first architectures.

The consent prompt is OAuth, made visible

The one moment most users actually see OAuth working is the consent screen: "This app would like to Read your mail, Read your contacts, Sign in as you." That screen exists because the requesting application has asked Entra ID for a specific set of scopes (Mail.Read, Contacts.Read, User.Read), and OAuth requires the resource owner — the user, or an admin acting on behalf of the tenant — to explicitly grant them before a token is ever issued. What the user is actually approving is not "let this app exist," it's "let this app hold a token with these specific permissions for as long as the grant stands." That distinction is the whole reason consent phishing works: the attacker doesn't need a password, just one click of Accept.

Delegated vs application permissions

The two permission types map directly onto the two things OAuth lets an app do. Delegated permissions act as the signed-in user, capped at whatever that user could do themselves — an app with Mail.Read delegated can read the current user's mail, not anyone else's. Application permissions act as the app itself, with no signed-in user in the loop at all, which is why they always require admin consent and why they're the higher-risk grant: an app with Mail.Read application permission can read every mailbox in the tenant, unattended, on a schedule. A background sync job legitimately needs application permissions; a user-facing add-in almost always only needs delegated ones, and requesting more is a red flag worth challenging in an app registration review.

Worked example

A line-of-business app needs to read a user's calendar to suggest meeting times. It registers in Entra ID, requests the delegated scope Calendars.Read, and redirects the user to Entra ID's authorize endpoint. The user signs in (if they haven't already) and sees the consent screen naming the app and the scope in plain language. On approval, Entra ID redirects back to the app with an authorization code, which the app exchanges server-side for an access token and a refresh token. The access token — typically valid for about an hour — rides on every Graph API call in the Authorization header; when it expires, the app silently uses the refresh token to get a new one, and the user never sees another prompt unless the grant itself is revoked or a Conditional Access policy demands re-authentication.

Common pitfalls

Treating OAuth tokens like a password to be stored indefinitely is the most common mistake — a leaked long-lived refresh token is functionally a stolen credential, which is why token protection and short access-token lifetimes matter. The second is over-scoping a service principal's application permissions "in case we need it later," which quietly creates a standing high-value target with no user in the loop to notice misuse. The third is confusing OAuth with authentication: an app that only checks "did I get a valid access token back" without validating an ID token via OIDC has confirmed the user granted some API access, not who the user actually is.