# Authentication

## Walkthroughs

[Authorization code](./authorization-code/)

[Client credentials](./client-credentials/)

## How it works?

In Microsoft Entra ID, the choice between **Delegated** and **Application** permissions depends entirely on one question:

:::note

## Is there a user present during the interaction?

:::

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

| **Feature**                | **Client Credentials (App Permissions)**     | **Authorization Code (Delegated)**      |
| -------------------------- | -------------------------------------------- | --------------------------------------- |
| **Who is Authenticating?** | The Application only.                        | The User + The Application.             |
| **User Interaction**       | **Zero.** Completely automated.              | **Required.** User must log in/consent. |
| **Security Layer**         | Relies on secure storage of the Secret/Cert. | Supports MFA and Conditional Access.    |
| **Token Content**          | Contains `roles` claim (App Permissions).    | Contains `scp` (Scopes) and User ID.    |

## Delegated Permissions

:::note

## The user is in the driver's seat

:::

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

:::note

## The app is a background worker

:::

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.All` as 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

| **Feature**          | **Delegated Permissions**             | **Application Permissions**           |
| -------------------- | ------------------------------------- | ------------------------------------- |
| **User Presence**    | Required (User must be logged in)     | Not required (Runs in background)     |
| **Identity**         | User + App (Delegated access)         | App only (Service Principal)          |
| **Effective Access** | Minimum of (User rights + App scopes) | Full privilege of the App scope       |
| **Common Scopes**    | `User.Read`, `Mail.Read`              | `User.Read.All`, `Mail.ReadWrite.All` |
| **Consent**          | User or Admin                         | **Admin only**                        |

## 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?

### 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

**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.