azureFedAuthConfig produces malformed access token scopes

[chlowell]

azureFedAuthConfig.azureFedAuthConfig trims trailing / from the given audience before appending the default scope /.default: https://github.com/microsoft/go-mssqldb/blob/ada30cbaf031d81144e5c5487ddefd4f3dac0ef5/azuread/configuration.go#L175-L177

This is incorrect in general because the default scope for a given audience is audience + /.default regardless of whether audience has a trailing /; see the Entra doc on this point. Removing trailing slashes makes it impossible for a downstream authentication client to reliably convert the resulting scope to a valid v1 resource string, which can cause authentication failures as seen in https://github.com/Azure/azure-sdk-for-go/issues/22957

[shueybubbles]

Sigh. it'd sure be nice if the backend services were consistent. go-sqlcmd -G works fine with some fabric native endpoints, just not that one. thx for opening an issue!

[aslatter]

For reference, the equivalent code in the C# SQL-Client SDK does not trim the trailing slash:

string scope = parameters.Resource.EndsWith(s_defaultScopeSuffix, StringComparison.Ordinal) ? parameters.Resource : parameters.Resource + s_defaultScopeSuffix;

This is in src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/ActiveDirectoryAuthenticationProvider.cs in Microsoft.Data.SqlClient.

It seems like the SPN returned from the TDS endpoint for Fabric is "https://database.windows.net/" (but to be clear I'm pretty far out of my depth at this point).

Thanks for opening this issue @chlowell! I appreciate you getting me pointed in the right direction.

[shueybubbles]

I wish I could remember what was in my head 3 years ago. Not sure why scope gets initialized to stsUrl then reassigned based on serverSPN

[shueybubbles]

ok, testing with a local copy of go-sqlcmd seems to work

sqlcmd -G -Q "select 1"

-----------
          1

(1 row affected)