Confused when using ClientSecretCredential to authenticate an AppConfiguration in China Cloud

[RichardChen820]

When I try to use ClientSecretCredential to authenticate an AppConfiguraiton in mooncake to get a setting, code like:

clientCred, _ := azidentity.NewClientSecretCredential(mooncake_tenant_id, mooncake_client_id, mooncake_client_secret, nil)

client, _ := azappconfig.NewClient("https://my-store-in-mooncake.azconfig.azure.cn", clientCred, nil)

setting, err := client.GetSetting(context.Background(), "test", nil)

It can successfully get the setting without specifying the AuthorityHost when creating the ClientSecretCredential.

But if I use .net SDK in the same way

var chinaClient = new ConfigurationClient(new Uri("https://my-store-in-mooncake.azconfig.azure.cn"), new ClientSecretCredential(mooncake_tenant_id, mooncake_client_id, mooncake_client_secret));

chinaClient.GetConfigurationSetting("test");

It throws exception saying no tenant was found.

Unhandled exception. Azure.Identity.AuthenticationFailedException: ClientSecretCredential authentication failed: AADSTS90002: Tenant '3d0a72e2-8b06-4528-98df-1391c6f12c11' not found. Check to make sure you have the correct tenant ID and are signing into the correct cloud. Check with your subscription administrator, this may happen if there are no active subscriptions for the tenant.
Trace ID: d7ff5734-2533-42d6-be2a-9f616b161e00
Correlation ID: 8c5f75bc-34f2-453d-a4f3-7113b0faee2b
Timestamp: 2023-05-23 03:39:24Z
 ---> MSAL.NetCore.4.49.1.0.MsalServiceException:
        ErrorCode: invalid_request
Microsoft.Identity.Client.MsalServiceException: AADSTS90002: Tenant '3d0a72e2-8b06-4528-98df-1391c6f12c11' not found. Check to make sure you have the correct tenant ID and are signing into the correct cloud. Check with your subscription administrator, this may happen if there are no active subscriptions for the tenant.
Trace ID: d7ff5734-2533-42d6-be2a-9f616b161e00
Correlation ID: 8c5f75bc-34f2-453d-a4f3-7113b0faee2b

I'm really confused why there's a such difference between go and .net. How the sovereign clouds be handled in azure. identity?

GO SDK package version I'm using:

github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.3.0
github.com/Azure/azure-sdk-for-go/sdk/data/azappconfig v0.5.0

.NET SDK package version I'm using:

<PackageReference Include="Azure.Data.AppConfiguration" Version="1.2.0" />
<PackageReference Include="Azure.Identity" Version="1.9.0" />

[chlowell]

There are 2 ways to set the authority host for azidentity credentials (Azure Public Cloud is the default):

1. environment variable AZURE_AUTHORITY_HOST
2. programmatically via ClientOptions:

   import (
    "github.com/Azure/azure-sdk-for-go/sdk/azcore/cloud"
    "github.com/Azure/azure-sdk-for-go/sdk/azcore/policy"
   )
   
   opts := azidentity.ClientSecretCredentialOptions{
    ClientOptions: policy.ClientOptions{Cloud: cloud.AzureChina},
   }
   cred, err := azidentity.NewClientSecretCredential("tenant", "client-id", "secret", &opts)

The .NET SDK has a different options API but observes AZURE_AUTHORITY_HOST, so the SDKs should behave the same in your scenario. I guess there's a difference in the service principal details (tenant ID, etc.) or runtime environment. Are both apps running in the same deployment environment?

If you can't just debug the app to see what's happening--the authority host is set here--you can enable logging to see where the credential sends token requests:

import azlog "github.com/Azure/azure-sdk-for-go/sdk/azcore/log"

azlog.SetListener(func(cls azlog.Event, msg string) {
	fmt.Println(msg)
})

azlog.SetEvents(azlog.EventRequest)

[github-actions]

Hi @RichardChen820. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[RichardChen820]

@chlowell
I just tried Go and .NET SDK in the totally same dev environment. What I get from .NET SDK is expected, because I neither set the authority host in env var nor in option. I do nothing different in GO, but get different result.

This is what I get after enabling the logging in GO

==> OUTGOING REQUEST (Try=1)
   GET https://login.microsoftonline.com/common/discovery/instance?api-version=1.1&authorization_endpoint=REDACTED
   User-Agent: azsdk-go-azidentity/v1.3.0 (go1.18.3; Windows_NT)

==> OUTGOING REQUEST (Try=1)
   GET https://login.microsoftonline.com/3d0a72e2-8b06-4528-98df-1391c6f12c11/v2.0/.well-known/openid-configuration
   User-Agent: azsdk-go-azidentity/v1.3.0 (go1.18.3; Windows_NT)

==> OUTGOING REQUEST (Try=1)
   POST https://login.partner.microsoftonline.cn/3d0a72e2-8b06-4528-98df-1391c6f12c11/oauth2/v2.0/token
   Content-Length: 223
   Content-Type: application/x-www-form-urlencoded; charset=utf-8
   User-Agent: azsdk-go-azidentity/v1.3.0 (go1.18.3; Windows_NT)

==> OUTGOING REQUEST (Try=1)
   GET https://junbchen-config-cn.azconfig.azure.cn/kv/test?api-version=1.0
   Accept: application/vnd.microsoft.appconfig.kv+json, application/json, application/problem+json
   Authorization: REDACTED
   Sync-Token: REDACTED
   User-Agent: azsdk-go-azappconfig/v0.5.0 (go1.18.3; Windows_NT)

Seems it just talking with public cloud AAD endpoint, not the mooncake's AAD endpoint.
But I verified the token I get, it is indeed a valid token that issue to a mooncake tenant. It's really weird.

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "_CJAOtysYVm5xc1YoK0oQ7qyBCQ",
  "kid": "_CJAOtysYVm5xc1YoK0oQ7qyBCQ"
}.{
  "aud": "https://junbchen-config-cn.azconfig.azure.cn",
  "iss": "https://sts.chinacloudapi.cn/3d0a72e2-8b06-4528-98df-1391c6f12c11/",
   .... .... 
  "idp": "https://sts.chinacloudapi.cn/3d0a72e2-8b06-4528-98df-1391c6f12c11/",
  "sub": "5e5a8e96-6cad-451d-bc50-a472a0ccc079",
  "tid": "3d0a72e2-8b06-4528-98df-1391c6f12c11",
   .... ....
  "ver": "1.0"
}.[Signature]

[chlowell]

I see. The difference in this case is in the behavior of MSAL.NET and MSAL for Go, supporting libraries the Azure SDK uses to implement service principal authentication. The first two requests in your log are MSAL requesting metadata about the Azure AD instance and tenant. The third is the token request--note that it's sent to Azure China. Looking at the metadata from the second request, I see that Azure China endpoint is the given token_endpoint. Your application's behavior makes sense then: the global metadata service knows your tenant is in Azure China, so it tells clients to send token requests there, and MSAL for Go automatically does the right thing; it doesn't need you to tell it the authority host in this case.

Off the top of my head, there are a couple reasons for your .NET application to behave differently:

1. MSAL.NET doesn't request tenant metadata because you set the DisableInstanceDiscovery option, that option somehow gets the wrong default, or Azure.Identity misinterprets its value (maybe an Azure SDK bug)
2. MSAL.NET doesn't observe the tenant's token_endpoint (maybe an MSAL bug)

Assuming you didn't set DisableInstanceDiscovery, you can narrow this down by enabling logging in your .NET app and looking for the /common/discovery/instance and /v2.0/.well-known/openid-configuration requests. I'm not familiar with .NET but the SDK's logging is documented here.

[github-actions]

Hi @RichardChen820. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[github-actions]

Hi @RichardChen820, we're sending this friendly reminder because we haven't heard back from you in 7 days. We need more information about this issue to help address it. Please be sure to give us your input. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!