AZ-204 Implement Azure security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  In the frontend app registration, grant API permissions for the backend using the 'Delegated permissions' type. In the backend app registration, expose an API scope. The frontend uses the on-behalf-of flow (OBO) to exchange the user's token for a token to call the backend.

  Why this is correct

  This option correctly describes the standard and secure pattern for a multi-tier application using Azure AD. The frontend application, acting on behalf of the signed-in user, requests a token for the backend API using the On-Behalf-Of (OBO) flow. This flow exchanges the user's token, obtained by the frontend, for a new token specifically scoped for the backend API, preserving the user's identity throughout the call chain. Delegated permissions in the frontend's app registration allow it to request access to the backend API on behalf of the user, while the backend exposes API scopes to define what access is available.

• ✗

  In the frontend app registration, enable the implicit grant flow for access tokens. The frontend gets a token for the backend directly from the authorization endpoint.

  Why it's wrong here

  Enabling the implicit grant flow for access tokens is not recommended for modern web applications due to inherent security risks, such as token leakage via browser history or referrer headers, and the lack of refresh tokens. While it allows the frontend to directly obtain a token, it bypasses the secure exchange of an authorization code for a token, making it less secure than the Authorization Code Flow with PKCE, which is the current best practice for single-page applications.

• ✗

  In the frontend app registration, set the redirect URI to the backend URL. The frontend uses the authorization code flow to get a token for the backend directly.

  Why it's wrong here

  Setting the redirect URI to the backend URL is incorrect because the redirect URI must point back to the *client application* (the frontend) that initiated the authentication request. The authorization code flow is designed for the client to obtain an authorization code, which it then exchanges for an access token and refresh token. This token is for the *client itself* to access resources, not directly for a *different* backend API without further token exchange mechanisms like the On-Behalf-Of flow.

• ✗

  In the frontend app registration, grant API permissions for the backend using the 'Application permissions' type. In the backend app registration, expose an API scope. The frontend uses the client credentials flow to get a token for the backend.

  Why it's wrong here

  Granting 'Application permissions' and using the client credentials flow is unsuitable for a frontend application calling a backend API on behalf of a user. The client credentials flow is designed for daemon or service-to-service communication where no user context is involved; it authenticates the application itself, not a user. Using this flow would mean the backend API would receive a token representing the frontend application's identity, completely losing the original user's identity and context.

Go deeper

Related to this question