[Storage] Add source login authentication for synchronous blob copy

[Dimitri Vasdekis (dvasdekis)]

Related command
az storage blob copy start

Description
Related to #28167 and #29039.

Add opt-in --source-auth-mode login for synchronous copies of named source blobs. The existing login path generates a user-delegation SAS for the source. This option instead obtains a storage-scoped token from the signed-in credential and passes the SDK's source_authorization parameter to start_copy_from_url. Blob data remains server-side; no source account key or SAS is generated.

Requires --auth-mode login and --requires-sync true. Supports the active cloud's storage endpoint and the SDK's standard storage OAuth scope. Rejects source URI, explicit source key/SAS, file sources, invalid account names, and destination blob type conversion. Existing copy behavior remains unchanged when the option is omitted.

This is deliberately narrower than the linked issues: asynchronous and batch-copy behavior are not changed. Synchronous copies remain subject to Azure Storage service limits and network rules.

Testing Guide
Example using generic resource names:

az storage blob copy start --account-name destinationaccount --destination-container destinationcontainer --destination-blob example.txt --source-account-name sourceaccount --source-container sourcecontainer --source-blob example.txt --auth-mode login --source-auth-mode login --requires-sync true

The signed-in identity needs blob read access at the source and write access at the destination.

Local validation:

• Seven new offline unit tests pass: no source key/delegation SAS, invalid combinations, bearer-token forwarding, cloud endpoints/SDK storage scope, source-account default/snapshot handling, and unchanged default SAS/copy behavior.
• All 32 existing storage validator unit tests pass.
• CLI help renders the new option and example.
• git diff --check passes.

Live synthetic validation passed between two private development storage accounts with shared-key access disabled: synchronous server-side copy returned success, copied bytes matched the synthetic source, and create-only collision was rejected. All test containers were removed. A live run also exposed an invalid cloud attribute lookup; the follow-up commit fixes it and adds a real-cloud-object regression test. No production data was used. Draft remains pending maintainer design review and a recorded integration scenario.

History Notes
[Storage] az storage blob copy start: Add --source-auth-mode login for synchronous named-source blob copies without generating a SAS.

• PR title and description follow the contribution format.
• Command and error-handling guidelines reviewed.
• Live synthetic cross-account validation.
• Recorded integration scenario.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[microsoft-github-policy-service]

Thank you for your contribution Dimitri Vasdekis (@dvasdekis)! We will review the pull request and get back to you soon.

[Dimitri Vasdekis (dvasdekis)]

@microsoft-github-policy-service agree

[Yong Zhang (yonzhan)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[x-engineering-agent]

Automated sensitive-information remediation ran on this pull request.

• Detected categories: credential
• Replaced with typed [REDACTED:category] placeholders in: no PR metadata fields
• Comment/review owners notified because X Engineering Agent cannot edit another user's text: none

X Engineering Agent does not modify source files. The PR creator must remove or replace each suspected value at the linked line:

• src/azure-cli/azure/cli/command_modules/storage/tests/latest/test_storage_blob_source_oauth.py:68 — possible credential
• src/azure-cli/azure/cli/command_modules/storage/tests/latest/test_storage_blob_source_oauth.py:81 — possible credential

If a credential was exposed, rotate or revoke it immediately. Detected values are never copied into this comment.

✅ Confirm the finding · ❌ Dispute the finding

GitHub only supports a fixed reaction set, so 👍 represents ✅ and 👎 represents ❌. The bot-created reactions are only poll choices.

[Dimitri Vasdekis (dvasdekis)]

Regarding the sensitive-information scan in #34219 (comment): both flagged lines assign the literal test-token to client.credential.get_token.return_value.token on a unittest.mock.MagicMock. These are synthetic offline unit-test fixtures, not actual access tokens or credentials, and cannot authenticate to any service. The matching Bearer test-token assertion verifies SDK argument forwarding only. No real credential is present in these lines, so no rotation or revocation is required. I consider these two findings false positives; no source change is needed.

[Copilot]

🟡 Changes recommended

Token acquisition can fail when login mode is combined with destination key, SAS, or connection-string credentials.

1 open finding

• Use validated login credential for source bearer token · New

What changed in this PR

Adds opt-in Entra authentication for synchronous server-side blob copies without generating a source SAS.

Changes:

• Adds --source-auth-mode login validation, help, and examples.
• Forwards a storage-scoped bearer token to synchronous copy requests.
• Adds unit coverage for validation, endpoints, tokens, and existing behavior.

File	Description
_validators.py	Validates source-login constraints and builds source URLs.
_params.py	Registers the new argument.
_help.py	Documents usage and provides an example.
operations/​blob.py	Adds bearer authorization to copy requests.
test_storage_blob_source_oauth.py	Tests the new authentication path.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[x-engineering-agent]

❌ Redaction disputed by Dimitri Vasdekis (@dvasdekis).

Automation is paused for maintainer review. X Engineering Agent will not restore the suspected value because doing so would publish it again. A maintainer can replace the placeholder with confirmed non-sensitive text after review.

[x-engineering-agent]

Automated sensitive-information remediation ran on this pull request.

• Detected categories: bearer token, credential
• Replaced with typed [REDACTED:category] placeholders in: no PR metadata fields
• Comment/review owners notified because X Engineering Agent cannot edit another user's text: none

X Engineering Agent does not modify source files. The PR creator must remove or replace each suspected value at the linked line:

• src/azure-cli/azure/cli/command_modules/storage/tests/latest/test_storage_blob_source_oauth.py:69 — possible credential
• src/azure-cli/azure/cli/command_modules/storage/tests/latest/test_storage_blob_source_oauth.py:83 — possible credential
• src/azure-cli/azure/cli/command_modules/storage/tests/latest/test_storage_blob_source_oauth.py:108 — possible credential
• src/azure-cli/azure/cli/command_modules/storage/tests/latest/test_storage_blob_source_oauth.py:116 — possible bearer token

If a credential was exposed, rotate or revoke it immediately. Detected values are never copied into this comment.

✅ Confirm the finding · ❌ Dispute the finding

GitHub only supports a fixed reaction set, so 👍 represents ✅ and 👎 represents ❌. The bot-created reactions are only poll choices.

[x-engineering-agent]

❌ Redaction disputed by Dimitri Vasdekis (@dvasdekis).

Automation is paused for maintainer review. X Engineering Agent will not restore the suspected value because doing so would publish it again. A maintainer can replace the placeholder with confirmed non-sensitive text after review.