CISSP Identity and Access Management 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.

• ✗

  Client Credentials grant

  Why it's wrong here

  The Client Credentials grant type is specifically designed for confidential clients, such as server-side applications, to obtain an access token directly from the authorization server using their own client ID and a securely stored client secret. This flow is used when the client is acting on its own behalf, not on behalf of an end-user, and does not involve user interaction for authorization. Native mobile applications are public clients that cannot securely store secrets and require user authorization, making this grant type unsuitable.

• ✗

  Implicit grant

  Why it's wrong here

  The Implicit grant type directly returns the access token in the redirect URI fragment after user authorization, bypassing the authorization code exchange step. This design makes it vulnerable to token leakage through browser history, referrer headers, and malicious applications, especially for public clients like native mobile apps. Due to these significant security concerns and the lack of refresh token support, the Implicit grant is officially deprecated in favor of more secure alternatives like Authorization Code with PKCE.

• ✗

  Device Code grant

  Why it's wrong here

  The Device Code grant type is tailored for input-constrained devices, such as smart TVs or IoT devices, where a user cannot easily type credentials directly into the device. It involves the device displaying a short code and a verification URI, prompting the user to complete authorization on a separate, more capable device (e.g., a smartphone or computer). Native mobile applications typically possess full input capabilities and an integrated browser, rendering this specialized grant type unnecessary and overly complex for their standard use cases.

• ✓

  Authorization Code grant with PKCE

  Why this is correct

  The Authorization Code grant with Proof Key for Code Exchange (PKCE) is the recommended and most secure flow for public clients like native mobile applications. PKCE mitigates the authorization code interception attack by requiring the client to generate a cryptographically random `code_verifier` and send its hash (`code_challenge`) during the initial authorization request. The same `code_verifier` must then be presented when exchanging the authorization code for an access token, ensuring only the legitimate client that initiated the request can complete the exchange, even if the code is intercepted.

Go deeper

Related to this question