Self Serve SSO feature request

Product Feedback
,
1

Feature:
Self Serve SSO:

  • Add a callback once the connection is created and/or enabled
  • Add ability for the user to map their attributes on the auth0 connection

Description: We have been using the self-serve sso tool which has been really helpful to expand what types of connections we can offer to customers. There are some limitations though so I was wondering if there was any consideration about adding these features:

  • Callback on creating the connection
    • When the connection is created in the self serve flow, there is a period where the state of auth0 and the state of our app is out of sync.
    • It would be useful to have a callback when the connection is created so that we can update our app
  • Map attributes in auth0
    • At the moment the self serve flow only shows the users how to configure their attibutes in their IdP. Sometimes this is not convenient.
    • It would be great if the self serve flow could also allow the user to set up attribute mappings in the auth0 connection if needed.
    • These mappings would be added in the connection mappings section here:
      Screenshot 2025-03-17 at 13.59.01
      Screenshot 2025-03-17 at 13.59.012108Ă—1132 135 KB

Thank you in advance.

2

Hello, I am keen to know if these features are on the roadmap?

3

Hi @nadia.zyborska, thanks for taking the time to add in this feature request.

  • Add a callback once the connection is created and/or enabled

As an immediate option, we create entries in the Tenant Logs when certain actions occur in the self-service flow - Log Event Types begin with “ss-sso”. You can stream these events to trigger any additional updates are needed to complete the setup on your end.

image
image1160Ă—124 14 KB

  • Add ability for the user to map their attributes on the auth0 connection

This item is currently in our backlog and hasn’t been prioritized yet, as we’re still gathering feedback to better understand overall interest and demand.

Again, appreciate the feedback! We’ll keep these in mind as we continue to evaluate.

4

@sheena.allan Thank you!

I have an additional question about the self serve flow if that’s ok.

Are you planning on adding SLO (single logout) instructions and links in the SSO self serve flow?

Many thanks,

Nadia

1 Like
5

Hi @nadia.zyborska;

Great question — thanks for bringing this up!

SLO support hasn’t come up as a request yet, but I’ve added it to our backlog so we can keep track of it. I agree it could be a helpful addition when setting up SSO, especially for those that care about session management across systems.

Appreciate you flagging it!

1 Like
6

@sheena.allan,

We are planning to replace the existing SAML configuration for our customers with SS SSO. The problem is that we did allow the customers to do custom attribute mapping. It would still make sense to have custom attribute mapping available in the Self Service SSO flow.

We also require our customers to configure the groups attribute on their IdP. This seems to be missing in the flow. This is especially difficult with OIDC connection (Okta Workforce, Entra or Custom OIDC). The connection needs to be manually updated later to support group attribute claims. Is there any workaround for this?

Cheers,
Sarath

7

Hi @sarathsivadas88!

Thanks for raising both points.

For SAML: We’re currently developing support for mapping SAML attributes to Auth0 user profile properties. Once a connection is created, these mappings will be visible and configurable via the “Mappings” tab in the connection UI. This should cover most standard use cases, but we want to ensure we’re accounting for any edge cases as well.

For OIDC: We’re also exploring support for more scopes within the Self-Service SSO flow. This would help reduce the need for manual updates after connection setup.

To help shape both of these features, could you clarify:

  • You mentioned you allow your customers to do custom mapping. How are customers typically customizing the attributes they pass through (e.g., renaming, formatting, assigning default values)?
  • Are group claims expected to come through in the ID token, or are they retrieved via /userinfo?
  • What are the most common IdPs you’re working with for OIDC connections?
  • Do you have any specific examples from customer setups that highlight unique or complex scenarios we should plan for?

This feedback is incredibly helpful as we refine the experience, thank you again!