auth0: can't use groups with custom auth0 domain

[abh]

If I configure my auth0 idp url to https://login.example.com/ instead of https://example.auth0.com/ then groups don't work. The data broker logs:

{"level":"warn","service":"identity_manager","error":"auth0: could not list roles: 401 Unauthorized: Bad audience: https://login.example.com/api/v2/","time":"2022-01-28T10:18:18Z","message":"failed to refresh directory users and groups"}

According to the auth0 documents, the management API has to be example.auth0.com even if login.example.com is used for logins.

[abh]

At a glance this patch adds support for it -- I'm not sure if it's the appropriate fix though. Another path would be adding an option to the service account (for Auth0 only).

diff --git a/config/options.go b/config/options.go
index 9d855844..4c22993d 100644
--- a/config/options.go
+++ b/config/options.go
@@ -148,6 +148,7 @@ type Options struct {
 	ClientSecret   string   `mapstructure:"idp_client_secret" yaml:"idp_client_secret,omitempty"`
 	Provider       string   `mapstructure:"idp_provider" yaml:"idp_provider,omitempty"`
 	ProviderURL    string   `mapstructure:"idp_provider_url" yaml:"idp_provider_url,omitempty"`
+	ProviderAPI    string   `mapstructure:"idp_provider_api" yaml:"idp_provider_api,omitempty"`
 	Scopes         []string `mapstructure:"idp_scopes" yaml:"idp_scopes,omitempty"`
 	ServiceAccount string   `mapstructure:"idp_service_account" yaml:"idp_service_account,omitempty"`
 	// Identity provider refresh directory interval/timeout settings.
diff --git a/databroker/cache.go b/databroker/cache.go
index 575f53c2..bff31516 100644
--- a/databroker/cache.go
+++ b/databroker/cache.go
@@ -160,6 +160,7 @@ func (c *DataBroker) update(cfg *config.Config) error {
 		ServiceAccount: cfg.Options.ServiceAccount,
 		Provider:       cfg.Options.Provider,
 		ProviderURL:    cfg.Options.ProviderURL,
+		ProviderAPI:    cfg.Options.ProviderAPI,
 		QPS:            cfg.Options.GetQPS(),
 		ClientID:       cfg.Options.ClientID,
 		ClientSecret:   cfg.Options.ClientSecret,
diff --git a/internal/directory/provider.go b/internal/directory/provider.go
index 24c61846..2d7524b8 100644
--- a/internal/directory/provider.go
+++ b/internal/directory/provider.go
@@ -70,8 +70,12 @@ func GetProvider(options Options) (provider Provider) {
 	case auth0.Name:
 		serviceAccount, err := auth0.ParseServiceAccount(options)
 		if err == nil {
+			domain := options.ProviderURL
+			if len(options.ProviderAPI) > 0 {
+				domain = options.ProviderAPI
+			}
 			return auth0.New(
-				auth0.WithDomain(options.ProviderURL),
+				auth0.WithDomain(domain),
 				auth0.WithServiceAccount(serviceAccount))
 		}
 		errSyncDisabled = fmt.Errorf("invalid auth0 service account: %w", err)
diff --git a/pkg/grpc/directory/directory.go b/pkg/grpc/directory/directory.go
index ba25c33e..229af6f2 100644
--- a/pkg/grpc/directory/directory.go
+++ b/pkg/grpc/directory/directory.go
@@ -54,6 +54,7 @@ type Options struct {
 	ServiceAccount string
 	Provider       string
 	ProviderURL    string
+	ProviderAPI    string
 	ClientID       string
 	ClientSecret   string
 	QPS            float64

[calebdoxsey]

Hi @abh. This may be the route we need to go, but I'd rather avoid a new configuration parameter if possible. I think custom domains have /.well-known endpoints we might be able to use to find the original auth0 domain so we can use it for the management API. Unfortunately I don't have a paid auth0 account to explore this so its hard to know if such an approach would be viable.

Off-hand do you know if there's some way to query a custom domain to determine the auth0 domain?

[abh]

@calebdoxsey Another path would be to add the extra configuration as part of the "service account" configuration. It'd keep the "configuration creep" scoped to just the auth0 provider. I only thought of this after I'd already deployed the change pasted above for my use case, so I didn't try it.

At a glance I don't think there's a way to discover one domain from the other. I posted a question to their discourse: https://community.auth0.com/t/well-known-discovery-of-tenant-domain/77255

[calebdoxsey]

I was not able to find a well-known configuration entry we could use, but after experimenting I believe adding a domain property to the service account is the best option, since I believe its possible to configure the management API using the custom domain as well, so it doesn't make sense to always use one or the other. The above PR should fix it.

[abh]

@calebdoxsey yeah, someone on the auth0 community forum confirmed the same about not having a mapping API from one to the other.

I'll update my local build to use your change instead of my quick hack.