Why is Get-AzAccessToken going to start returning a SecureString?

[jackmtpt]

Description

Other Microsoft code is actively migrating away from SecureString , e.g. AzureAD/microsoft-authentication-library-for-dotnet#2437.

Microsoft's own documentation about SecureString recommends that it is not used: https://learn.microsoft.com/en-us/dotnet/fundamentals/runtime-libraries/system-security-securestring

Apparently Az version 14 is going to ignore this guidance and make a breaking change to use SecureString anyway:

WARNING: Upcoming breaking changes in the cmdlet 'Get-AzAccessToken' :
The Token property of the output type will be changed from String to SecureString. Add the [-AsSecureString] switch to avoid the impact of this upcoming breaking change.
- The change is expected to take effect in Az version : '14.0.0'
- The change is expected to take effect in Az.Accounts version : '4.0.0'

Why?

Script or Debug output

Environment data

Module versions

Error output

[isra-fel]

Hi @jackmtpt thanks for reaching out. Long story short, we promote secure string to prevent the risk of unintentional exposure of plain text string, not for cryptographic reasons.

PowerShell scripts are often executed in automation systems. Some of them lack comprehensive access control over logs, which when combined with unsafe programming practices, leads to the exposure of secrets. That's the problem we want to address with SecureString. Even if a SecureString is logged, it's never in plain text, hence free of risk.

The reason why SecureString is unrecommended in .NET is that it's not safe cryptographically. Since Azure PowerShell is not relying on it to encrypt those data, it is unnecessary to move away from SecureString as well.

[jackmtpt]

There's better ways to do that though aren't there? e.g. via the Format.ps1xml files that specify which fields are shown by default when an object is written to the pipeline. That would prevent the token getting printed to the terminal/logs accidentally unless someone explicitly accesses .Token.

[isra-fel]

Yes that's one option. But there are limitations that (a) as you said if someone explicitly .Token or does customized format with | Format-* it won't work. (b) format.ps1xml doesn't apply to the result of jobs e.g. $j = start-job { get-azaccesstoken }; $j | receive-job.

[jackmtpt]

For A I'd say that's up to the user - if they send .Token to the pipeline they shouldn't be surprised when it ends up in logs. For B does it work if you include Deserialized.Microsoft.Azure.Commands.Profile.Models.PSAccessToken in the format xml?

For context my reason for not wanting to deal with SecureStrings here is that for some API calls you need to include the Entra ID refresh token in the body of a POST request, such as when getting an ACR refresh token via the /oauth2/exchange endpoint. You'd have to go via PSCredential.GetNetworkCredential().Password to retrieve the token which is just pointless extra code vs being able to get the token directly.

If you still want to change the default to SecureString, would you be open to having a -AsPlainText argument to keep the current behaviour?

[davidbviana]

Recently, the deprecation went into effect, so our workaround was the following:
For some reason, we had:
$token = ConvertTo-SecureString (Get-AzAccessToken -Resource $resource_id).Token -AsPlainText -Force
And that became (by dropping the ConvertTo-SecureString call):
$token = (Get-AzAccessToken -Resource $resource_id).Token

[isra-fel]

Adding to David, depending on your purpose for the token -

1. If whoever consumes the token also accepts a SecureString, that's perfect - you can simply remove the redundant code for conversion, as shown in David's example
2. If you need the token to make a web request to Azure, consider Invoke-AzRestMethod which frees you completely from handling the token by yourself.
3. If you absolutely need the token in plaintext - follow the migration guide or use ConvertFrom-SecureString (PS 7 required).