Identity Focus

Azure Entra ID Applications

For the purpose of this article, below are key elements.

Key Roles

  • Client: The application (frontend or backend) that requests access to resources—either on behalf of a user (in user flows) or on its own behalf (in machine-to-machine flows). In Azure Entra ID, the client app is represented by an App Registration.
  • Authorization Server (Entra ID): The service that authenticates users or clients and issues access tokens and ID tokens based on the authentication and authorization process.

Note – OAuth itself is not an authentication protocol—it’s designed for authorization (granting access). But Azure Entra ID (formerly Azure AD) combines OAuth with OpenID Connect (OIDC), which adds authentication capabilities.

  • Resource Server: The API or service that hosts protected data and validates access tokens before allowing access to its resources.
  • App registration: The configuration in Entra ID that acts like the client app’s identity card. It contains important info like the Client ID, Client Secret (if confidential), redirect URIs, and permissions/scopes required to obtain access tokens.

API permissions

Understanding API Permissions & Call Direction in Azure Entra

In Azure Entra, API permissions defined in an application’s registration determine which APIs (like Microsoft Graph or your own custom APIs) the app can call, and how it can call them.

Importantly, API communication isn’t just one-way — depending on the permissions (or scopes) granted, an app might be:

  • Calling out to other APIs, or
  • Exposing its own API for other apps to call.

These permissions fall into two main types:

Delegated Permissions

  • The application is acting on behalf of a signed-in user.
  • The user must be authenticated (logged in via Entra ID).
  • The app can only do what the user is allowed to do — it’s limited to the user’s permissions.
  • Example: A web app accessing a user’s calendar after they log in.

Application Permissions

  • The app acts as itself, not tied to a user.
  • Used in background services, daemons, or automation scripts.
  • These permissions allow broader access and often need admin approval.
  • Example: A background service syncing users from Entra ID to another system.

ADMIN CONSENT

Some permissions — especially application-level ones — are sensitive and require an admin to approve them.

In such cases:

  • An administrator must grant consent for the app to access data, either for all users or the tenant as a whole.
  • This is typically done once by clicking the “Grant admin consent” button in:
    • Azure Portal ➝ App registrations ➝ API permissions

Granting consent this way ensures smoother operation in non-interactive scenarios, such as background jobs or automated workflows.

OAuth 2.0 token

When a 3 rd party application performs an API call, it needs to interact with the Entra ID application
via an OAuth token to retrieve the permissions.
For a 3 rd party application to retrieve the token, The application needs to do a POST request to the
token endpoint. In Entra ID App registration, under overview, under endpoints, copy “OAuth 2.0
token endpoint (v2)” URL and provide it to the 3rd party app.

Note – in the 3 rd party application, you must define the Oauth2 grant types. This determines the
sequence of steps involved in the Oauth process.
OAuth 2.0 grant types define how the application acquires tokens. Common types include:

. Authorization Code (used with user sign-in)
. Client Credentials (used for daemon apps / background services)
. Device Code (used on devices without browsers)
. Refresh Token (used to renew access tokens)

Part of the token retrieval process is configuring scope. Client ID and client secret in the 3 rd party
application.
Client ID – under overview in App registration in Entra ID , it will have the client ID.
Client secret – “the password” to provide to the 3 rd party application to be able to authenticate to
the Application to trigger an API call.

FLOWS

 There are two types of flows, authorization code flow and Client credential flow.

Authorization code flow is primary used for Web apps, SPAs, mobile apps accessing APIs with user context.

Client credential flow. Is primary used for background jobs, microservices, daemons calling APIs.

Unlike Authorization flow, where user is redirected to Entra Login page to retrieve the token.

Authorization code flow

OAuth 2.0 Flow with Client, Entra ID (Authorization server), and Resource Server

Step 1: User is redirected to Entra ID for login and consent from client app.

The client app (a web app like a website where you log in, a desktop application or a mobile app for example) sends the user to Entra ID’s login page to start the login process and ask for permission to access the API, this information is obtained from the app registration related to the the client app (like its identity card, telling the client app how to interact with Entra ID). Example of the kind of URL:

GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?

  client_id=CLIENT_ID

  &response_type=code

  &redirect_uri=CALLBACK_URL

  &scope=openid profile email api://API_CLIENT_ID/.default

  &state=RANDOM_STATE

Step 2: Entra ID Authenticates the User

  • Entra ID shows the login screen (or SSO, MFA, etc.).
  • User enters their credentials.
  • If successful, Entra ID redirects the user back to the client’s redirect_uri with an authorization code:

GET https://client-app.com/callback?code=AUTH_CODE&state=RANDOM_STATE

Step 3: Client Exchanges Code for Tokens

The client calls Entra ID’s token endpoint to get tokens — especially the access token — to act on the user’s behalf.:

After the user signs in, the client app sends a secure request to Entra ID’s token endpoint to exchange the temporary authorization code for tokens. This request includes:

  • The client ID to identify the app.
  • The client secret if it’s a confidential app (like a backend server).
  • The authorization code received from the previous step.
  • The redirect URI to verify where the response should go.
  • The grant type set to authorization_code to specify the flow being used.

If everything checks out, Entra ID responds with:

  • An access token that the app can use to call APIs on behalf of the user.
  • An ID token containing information about the user’s identity.
  • Optionally, a refresh token that lets the app get new tokens without making the user sign in again.
  • The scopes granted, indicating what permissions the app has.

Step 4: Client Calls the Resource Server (API)

The client sends the access token in the Authorization header:

GET /data HTTP/1.1

Host: api.example.com

Authorization: Bearer ACCESS_TOKEN

Access protected resources using the token issued by Entra ID.

Step 5: Resource Server Verifies the Token

  • The resource server does not trust the client directly.
  • Instead, it validates the access token:
    • Is it signed by Entra ID? (using Entra’s public keys from the discovery document)
    • Is the aud (audience) claim correct (matches this API)?
    • Is the token expired?
    • Is the iss (issuer) correct (Entra ID URL)?

If valid → process the request
If invalid → return 401 Unauthorized

Only allow requests with valid Entra-issued token

Machine flow – client credentials flow

  1. Machine Authenticates to Entra ID
    The machine app (such as a backend service, a server on-premises or daemon running without user interaction) sends a token request to the fixed Azure Entra ID token endpoint URL. It includes its Client ID and Client Secret—credentials obtained from its App Registration (identity card)—along with the scopes representing the permissions it needs. This request uses the client_credentials grant type to authenticate the machine app and request an access token
  • Entra ID Issues an Access Token
    If the client’s credentials and requested scopes are valid, Entra ID responds with an access token. This token contains important claims like:

aud (audience): the resource server the token is for.

iss (issuer): Entra ID’s URL.

exp (expiry): token expiration time.

  • Machine Calls the Resource Server
    The machine app sends its access token along with its request to the resource server so it can access the protected data.
  • Resource Server Validates the Token
    The API verifies that the token is:
  1. Signed by Entra ID (using its public keys).
  2. Intended for this API (audience claim).
  3. Still valid (not expired).

If valid, the API processes the request and returns the data; if not, it returns an error.

Tip – 401 Unauthorized means:
“You need to provide valid credentials (like a valid access token) to access this resource.”

    403 Forbidden — means the token is valid, but the user or app doesn’t have permission to perform the action.