Authentication
Walkthroughs
Section titled “Walkthroughs”How it works?
Section titled “How it works?”In Microsoft Entra ID, the choice between Delegated and Application permissions depends entirely on one question:
Think of it as the difference between acting as someone’s personal assistant versus acting as an independent automated service.
Key differences in the authentication logic
Section titled “Key differences in the authentication logic”Delegated Permissions
Section titled “Delegated Permissions”Delegated permissions are used by apps that have a signed-in user present. The app acts on behalf of that user.
- How it works: The app’s effective permissions are the intersection of the user’s privileges and the permissions granted to the app. Even if the app has “Read All Files,” it cannot see a file that the logged-in user doesn’t have access to.
- Typical Use Case: A web dashboard where a user logs in to see their own Outlook emails or OneDrive files.
- Consent: Often granted by the end-user (if allowed by policy), but sensitive scopes still require an Admin.
Application Permissions
Section titled “Application Permissions”Application permissions (also known as “App-only” or “Service” permissions) are used by apps that run without a signed-in user.
- How it works: The app acts as itself. It has direct access to all data associated with the permission scope across the entire tenant. For example,
Files.Read.Allas an Application permission allows the app to read every single file in the organization’s SharePoint/OneDrive. - Typical Use Case: Background daemons, sync services, or automation scripts (e.g., a nightly cleanup script that deletes old logs).
- Consent: Always requires Administrative consent because of the broad level of access.
Comparison Summary
Section titled “Comparison Summary”Which one should you choose?
Section titled “Which one should you choose?”- Choose Delegated if you are building a client-facing app where users need to interact with their own data. It is the “Principle of Least Privilege” friendly choice.
- Choose Application if you are building a backend service that needs to process data for the whole company or perform tasks while everyone is asleep.
Which credential will you choose in Mindflow?
Section titled “Which credential will you choose in Mindflow?”Application Permissions & OAuth 2.0 Client Credentials
Section titled “Application Permissions & OAuth 2.0 Client Credentials”Why this flow? Because there is no human to type in a password.
When an app has Application Permissions, it is acting as its own entity (a Service Principal). Since no user is present to “authorize” the action at runtime, the application must prove its own identity directly to Microsoft Entra.
- The Secret Handshake: The app uses its own credentials—usually a Client Secret (password) or a Certificate—to say, “I am App ID X, and here is my proof.”
- No Redirection: Because there’s no user, there is no need for a browser popup or a login screen. The app sends a direct POST request to the token endpoint.
- The Result: Entra verifies the secret/certificate, checks that Admin Consent was previously granted, and issues an Access Token representing the App only.
Delegated Permissions & OAuth 2.0 Authorization Code
Section titled “Delegated Permissions & OAuth 2.0 Authorization Code”Why this flow? Because we need to verify both the app AND the user.
When an app uses Delegated Permissions, it isn’t allowed to do anything until a user proves who they are. The Authorization Code Flow is the gold standard for security because it keeps the user’s credentials hidden from the application.
- The Middleman: The app redirects the user to Microsoft’s login page. The app never sees the user’s password or MFA code; only Entra does.
- The “Permission Slip”: Once the user logs in, Entra sends an “Authorization Code” back to the app. This code is like a temporary claim check.
- The Exchange: The app then takes that Code (and its own Client Secret) and exchanges it for an Access Token.
- The Result: The resulting token contains both the App’s identity and the User’s identity. This allows Microsoft Graph to ensure the app only touches what that specific user is allowed to see.