Self-service SSO connection does not return options.domain_aliases

Get Help
,
1

Hi

I am struggling with getting access to the domain aliases for a given self-service SSO connection. I’m configuring using an Okta Workforce connection an I am following the docs here:

..which states that ‘Both methods populate the same field: options.domain_aliases’. However, when I issue the connection request I see no such options in the response:

curl --request GET \
  --url 'https://REMOVED.eu.auth0.com/api/v2/connections/con_REMOVED?fields=options' \
  --header 'authorization: Bearer REMOVED'
{"id":"con_REMOVED","is_domain_connection":false,"authentication":{"active":true},"connected_accounts":{"active":false}}%

Is this a bug, or a documentation issue?

Any input much appreciated.

Thanks for looking

2

Note, in the management console the aliases are clearly visible in the Connnection/Login Experience/Home Realm Discovery/Identity Provider domain list.

3

Hi!

I haven’t done it before but did you get to this point in the doc where you create the ticket via this API? Welcome to Auth0 Docs - Auth0 Docs

4

Yes, profile created, ticket created, wizard completed. I am currently pre-verifying by passing domain_aliases when creating the ticket. This is for ease of initial testing of the flow.

5

The examples in document use different APIs to the one in your question?
/v2/self-service-profiles Welcome to Auth0 Docs - Auth0 Docs
/v2/self-service-profiles/{id}/sso-ticket Welcome to Auth0 Docs - Auth0 Docs..

6

Although, this old thread may help:

and here is the solution someone else found Auth0 Connection Management Options - Full API Missing

7

@JFoxUK wrt the self-service URLs your referenced. I have already done the ticket creation and connection setup wizard. I’m trying to fetch the resultant connection. The REST API docs for the get connection endpoint state a specific read:connection_optionsscope is required:

This was missing from my client API config, but adding it did nothing :upside_down_face:

After a management token refresh this worked.

So it was a scope issue. The API normally gives good feedback on when there are relevant scopes configured for an API operation, but it was silent in this case. And not present in the main docs:

Just nestled in the API docs.

1 Like