A tarn-depth logger already obtained user consent for User.Read. A new OneDrive export feature needs Files.Read. How should the app obtain the additional Graph permission?
Select an answer to reveal the explanation.
Short Explanation
Consent is not a one-shot forever stamp for every Graph scope. When a later feature needs Files.Read, ask for that scope then—incremental consent—rather than inventing a new tenant or stuffing scopes into Key Vault.
Full Explanation
Delegated Graph consent is incremental. The tarn-depth logger already holds User.Read for the signed-in operator; that does not automatically authorize OneDrive file reads. When the new export feature runs, the app should request Files.Read (or the least-privilege Files scope that fits) through incremental/dynamic consent so the user (or admin, when required) can approve the additional scope at the moment of need. Tokens then carry the expanded set without rebuilding the whole identity story.
Registering a brand-new Entra tenant to reset consent fails conceptually: tenants isolate organizations, not feature scopes. You would abandon existing users, apps, and municipal directory links for no permission benefit. Storing the string Files.Read as a Key Vault secret and injecting it into the Graph base URL fails because scopes are OAuth claims on the token request, not URL path fragments or vault payloads—Key Vault cannot grant Graph access by itself. Switching entirely to application permissions so the signed-in user is never asked again fails the least-privilege and product-intent test for a user-driven export: app-only rights need admin consent, often broader directory access, and remove the user's agency over their OneDrive data.
Exam caveat: some Graph permissions are admin-consent-only; incremental consent still surfaces that requirement rather than silently elevating. Operational check: exercise the export path on a test account that previously consented only to User.Read, confirm the consent prompt (or admin consent flow) appears for Files.Read, then decode the access token and verify the scp claim includes the new scope before writing production logs.