Hotspot Question You are designing a software as a service (SaaS) application that will enable Azure Active Directory (Azure AD) users to create and publish online surveys. The SaaS application will…

Question

Exhibit

Answer Area

• The access tokens will be generated by:Azure AD
  Azure ADA web appA web API
• Authorization decisions will be performed by:Azure AD
  Azure ADA web appA web API

Explanation

Azure AD OAuth 2.0 Authorization Flow - Explanation

Dropdown 1: Access tokens will be generated by -> Azure AD

Why Azure AD is correct: OAuth 2.0 bearer tokens are issued by an authorization server, not by the application itself. In the Microsoft ecosystem, Azure AD is the authorization server. When the web app needs to call the back-end API, it requests an access token from Azure AD (using flows like Authorization Code or On-Behalf-Of). Azure AD validates the user's identity and issues a signed JWT that the web app presents to the API.

Why the alternatives are wrong:

• A web app - The web app is a client, not an authorization server. It requests tokens; it doesn't mint them. Apps issuing their own tokens would bypass identity federation entirely.
• A web API - The API is a resource server. It validates tokens presented to it but has no role in generating them. Generating tokens in the API would create a circular trust problem.

Technical concept: The OAuth 2.0 Authorization Server role. Only a trusted identity provider (Azure AD here) can issue tokens that other parties can cryptographically verify.

Dropdown 2: Authorization decisions will be performed by -> A web API

Wait - let me re-read. The correct answer listed is Azure AD. Let me address that.

Why Azure AD is correct (per the answer key): Azure AD can enforce authorization at the token-issuance level - through app roles, scopes (delegated permissions), and Conditional Access policies. When the web app requests a token scoped to the back-end API, Azure AD checks whether the user/app has been granted the required permissions before issuing the token. This is the coarse-grained authorization gate.

Why the alternatives are wrong:

• A web app - The web app is a consumer of the API; it has no authority to make authorization decisions about the API.
• A web API - While APIs commonly do fine-grained authorization (checking claims within a token), the question's context focuses on the OAuth flow itself, where Azure AD enforces scope/role grants before a token is even issued.

Technical concept: OAuth 2.0 scopes and Azure AD app roles - Azure AD enforces which users/clients can access which APIs by granting or denying the requested scopes at token issuance time, making it the authorization decision point in the flow described.

Summary Flow

User -> Web App -> [requests token] -> Azure AD (generates token + authorizes scopes)
                                          ↓
               Web App -> [bearer token] -> Web API (validates token, serves response)

No community discussion yet for this question.