azureFedAuthConfig produces malformed access token scopes

[chlowell]

azureFedAuthConfig.azureFedAuthConfig trims trailing / from the given audience before appending the default scope /.default:

go-mssqldb/azuread/configuration.go

Lines 175 to 177 in ada30cb

	if !strings.HasSuffix(serverSPN, scopeDefaultSuffix) {
	scope = strings.TrimRight(serverSPN, "/") + scopeDefaultSuffix
	}

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 Azure/azure-sdk-for-go#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)