CISSP Identity and Access Management Practice Question
A financial services firm is deploying a customer-facing mobile banking app and wants to delegate limited access to account balances and transaction history to third-party budgeting apps without sharing the customer's banking credentials. The security architect must select controls that implement this delegation securely. (Choose two.)
⚠ Common exam trap
A common mix-up: candidates confuse authentication with authorization delegation, leading to choices that share credentials or issue overly broad tokens instead of scoped OAuth access.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use OAuth 2.0 authorization code grant with PKCE so the budgeting app obtains a scoped access token without receiving the customer's password.
OAuth 2.0 authorization code grant with PKCE lets the budgeting app receive a scoped token without ever handling the customer's credentials, and granular scopes plus explicit consent constrain that token to balances and transaction history. Together these controls implement least-privilege delegation for a public mobile client while keeping the bank's authentication boundary intact.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use OAuth 2.0 authorization code grant with PKCE so the budgeting app obtains a scoped access token without receiving the customer's password.
Why this is correct
The authorization code grant with PKCE lets the budgeting app obtain a limited access token after the customer authenticates directly with the bank, so credentials are never shared. PKCE protects the code exchange from interception on public clients such as mobile apps, matching the delegation and security requirements of this scenario.
- ✗
Configure the budgeting app to store the customer's banking username and password in its local keystore for future API calls.
Why it's wrong here
Storing customer credentials in a third-party app defeats the purpose of delegated authorization and creates a severe credential compromise risk. The requirement is explicitly to avoid sharing banking credentials, so persisting them locally contradicts the design goal and would expand the attack surface dramatically.
- ✗
Rely on SAML 2.0 bearer assertions issued to the budgeting app so it can impersonate the customer for all banking operations.
Why it's wrong here
SAML bearer assertions are not the right mechanism for limited third-party API delegation and, if broadly issued, allow impersonation rather than scoped access. Using them here would grant more authority than needed and does not provide the granular, consent-based token model the scenario requires.
- ✗
Issue refresh tokens with long lifetimes and broad scopes so budgeting apps can maintain access without repeated customer consent.
Why it's wrong here
Long-lived refresh tokens with broad scopes expand the blast radius if a third-party app is compromised and violate least privilege. The scenario calls for limited delegation to balances and transaction history, so broad scopes and extended lifetimes increase risk rather than implement secure, bounded delegation.
- ✓
Define granular OAuth 2.0 scopes such as read:balances and read:transactions and require the customer to consent to them during authorization.
Why this is correct
Granular scopes enforce least privilege by limiting the token to exactly the data the budgeting app needs, and explicit consent ensures the customer understands what is shared. This directly satisfies the requirement to delegate only balances and transaction history without granting broader banking capabilities.
Go deeper
Related to this question
Learn chapter
Access Control Models and Mechanisms
Key term
Access token
A digital key that a computer system gives you to prove your identity and grant you permission to access specific resources or perform actions.
Key term
Authentication
Authentication is the process of verifying that someone or something is who or what it claims to be before granting access to a system or resource.
About these practice questions
One of 816 original CISSP practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISC2 exam blueprint
This CISSP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CISSP exam.