An urchin-barren plot site must let a visitor’s browser upload one photo to Blob Storage. A teammate tries enabling managed identity on the user’s laptop. What is the correct approach?

Managed identities are for Azure-hosted resources, not end-user laptops. For the urchin-barren plot site that must let a visitor’s browser upload one photo to Blob Storage, the correct pattern is to issue a short-lived SAS or user-delegation SAS scoped to the upload container or blob, with write-only permissions and a tight expiry. Azure-hosted backends (App Service, Functions) can use managed identity to mint a user-delegation SAS; the browser never holds the account key or a managed identity. That separates visitor upload capability from host identity.

Enabling managed identity on every visitor laptop fails because consumer devices are not Azure compute resources with the Instance Metadata Service. Browsers do not automatically present managed-identity tokens for Blob uploads, and there is no supported “flip MI on the laptop” path for anonymous visitors.

Granting Microsoft Graph Directory.ReadWrite.All to the anonymous browser fails because Graph directory permissions govern Microsoft 365 and directory objects, not Blob Storage data-plane uploads. Over-privileged Graph consent also creates a severe identity risk unrelated to photo storage.

Putting the storage account key in localStorage fails because account keys are full-control credentials and anything in localStorage is readable by XSS and client-side scripts. Direct Blob REST with the account key from the SPA is an anti-pattern for public sites.

Exam caveat: prefer user-delegation SAS when Entra authentication is available so key rotation does not invalidate every outstanding signature; still keep SAS lifetime and permissions minimal. Operational check: upload one photo with the issued SAS, confirm the object lands in the intended container, and verify the SAS cannot list or delete other blobs after expiry.