alisha-tingle

Alisha Tingle is a Senior Customer Advocate at Auth0 with 10 years of client-facing experience in the tech industry. In her role, she focuses on accelerating self-service customer growth, expanding self-service reach to developers, and generating enterprise growth. Outside of work, Alisha is passionate about teaching pilates and spending time with her family.

Senior Customer Advocate, DLG

Alisha Tingle

Understand the differences between Social and Enterprise Connections to choose the right identity provider for your application.

Social or Enterprise: Which Connection is Right?


Daizen Ikehara

.NETエンジニアとしてキャリアをスタートさせた後、UIコンポーネントベンダーやクラウドコミュニケーションプラットフォームベンダーにおいて様々なロールを歴任。2023年3月よりOktaに参画し、日本市場における開発者リレーションを担当。趣味はゲームと長距離散歩。

Daizen Ikehara joined the Developer Relations team in March 2023 as a Principal Developer Advocate. In the early stages of his professional career, Daizen started using C#. Then, he touched on various JavaScript technologies/frameworks—Angular, React, and Vue. Recently, he’s been using Node.js/JavaScript more often. He is passionate about talking with developers. Outside of work, Daizen likes to take long walks, play video games, and watch Formula 1 racing.

Principal Developer Advocate

In this blog post, we will add the capability to edit existing Self-Service SSO configurations in your SaaS application.

In the previous post, we added [a Self-Service capability to create SSO connections](https://auth0.com/blog/how-to-add-self-service-sso-to-your-nodejs-saas-app/). This is a powerful feature that you can use to offload administrative tasks to your customers' admins. However, your SaaS also needs to support editing the existing SSO configurations.


## Editing SSO Connections Is a Must-Have


Let's discuss why editing is essential. After creating an SSO connection, a customer admin might need to update the Client Secret or swap the SAML certificate for the connection. In this scenario, the customer admin still needs to contact SaaS’s support or representatives.


To provide true “Self-Service” administration, you can continue to leverage the power of Auth0's [Self-Service SSO](https://auth0.com/docs/authenticate/enterprise-connections/self-service-SSO) feature. Let's dive into the details.


## The Sample App


This blog post will use the sample application built previously as a starting point.


You can download a sample Node.js/Expression application:


```bash
git clone --branch feature/self-service-sso-create --single-branch https://github.com/neri78/self-service-sso-express.git
```


> Note: The sample code omits error handling to make the code simple. In a real-world development, you will need to implement error handling correctly.


Follow the attached README file instructions to register and configure the Regular Web Application and a Machine-to-Machine (M2M) Application.


In the sample app, once you have signed up as a user and logged in, click Dashboard on the header navigation to open the dashboard page. You will see the following page on the navigation to the Dashboard page. Currently, the Dashboard provides a button to create a new SSO Connection.

![Admin dashboard for the self-service SSO application, showing only the 'Add SSO Connection' button before changes.](https://images.ctfassets.net/23aumh6u8s0i/1aT1P96Mvj5ZyZedvOalfQ/596ff65b8017d157e2732abd07f2bbb3/sso-dashboard-start.png)

## Self-Service Editing for SSO Connections
To add editing capability to the sample application, we will perform the following steps:


1. Update the UI on the Dashboard page.
2. Add a permission for the Management API to retrieve existing connections.
3. Update router handler to create a Self-Service SSO editing.

### Update the UI on the dashboard page


First, let's add an Edit button on the `views/dashboard.ejs` file:


```html

   <form action="/dashboard" method="post" class="w-full max-w-xl">
     <div class="md:flex md:items-center">
       <div >
       
         <button class="shadow bg-indigo-600 hover:bg-indigo-500 focus:shadow-outline focus:outline-none text-white font-bold py-2 px-4 rounded"
                 name="action"
                 value="create"
                 type="submit">
           Add SSO Connection
         </button>
         <p>or</p>
         <button class="shadow bg-indigo-600 hover:bg-indigo-500 focus:shadow-outline focus:outline-none text-white font-bold py-2 px-4 rounded"
                 name="action"
                 value="edit"       
                 type="submit">
           Edit SSO Connection
         </button>
       
       </div>
     </div>
   </form>

```

Now, the dashboard has two buttons. Each button has a `value` attribute, which is used to branch logic in the router handler.

![Updated admin dashboard for self-service SSO, now with both 'Add SSO Connection' and 'Edit SSO Connection' buttons.](https://images.ctfassets.net/23aumh6u8s0i/5HvXR2dwCAvggLI5qZlPRE/342a95bcd2fa4e0e3968b9a1062ced5f/Self_Service_SSO_-_dashboard_-_edit.png)

### Add a Permission for the Management API to retrieve existing connections

We must retrieve existing connections using the [Auth0 Management API](https://auth0.com/docs/api/management/v2) to edit an existing connection. For those purposes, grant the following permission in your Machine-to-Machine (M2M) application:

- `read:connections`

![Auth0 Management API permissions screen, with the 'read:connections' permission selected to retrieve existing connections.](https://images.ctfassets.net/23aumh6u8s0i/2yDvfX80n1XdrX6RElU5am/8f43c9c42546add6b8c6a3458ff6f82c/Management_API_-_read_-_connections_permission.png)

## Update Router Handler to Create a Self-Service SSO Editing

The application has a POST handler for `/dashboard` in the `router/index.js` file. This handler is creating a Self-Service SSO ticket to create a connection. We are going to use this handler for editing, too. 

### Branch the logic

Let's update the handler to branch based on the button's value attribute.

```javascript
// routes/index.js

// ...existing code...
router.post('/dashboard', requiresAuth(), async function (req, res, next) {
   // get an instance of the ManagementClient.
   const management = getManagementClient();

   // get a list of Self-Service Profiles.
   const { data: ssoProfiles } = await management.selfServiceProfiles.getAll();

   // use the 1st profile in this sample.
   const ssoProfile = ssoProfiles[0];

   const requestParameters = {
       id: ssoProfile.id
   };

   // 👇 change code
   let bodyParameters = {};

   const action = req.body.action;

   if (action === 'create') {
       // build bodyParameter for 'create a connection'.
       bodyParameters = {
           ...bodyParameters,
           connection_config: { name: `self-service-sso-${Date.now()}` },
           enabled_clients: [process.env.CLIENT_ID]
       }
   } else if (action === 'edit') {
       // build bodyParameter for 'edit a connection'.
   }
   // 👆 change code

   // generate a Self-Service SSO ticket.
   const { data: ssoTicket } =
       await management.selfServiceProfiles.createSsoTicket(
           requestParameters,
           bodyParameters
       );

   res.render('dashboard', {
       title: 'Admin Dashboard',
       ticketURL: ssoTicket.ticket
   });
});
// ...existing code...
```

With this change, we can keep the existing logic for creating new connections.

### Build a bodyParameter to edit an existing connection

To edit an existing connection with the Self-Service SSO, specify `connection_id` in the `bodyParameters`. Here's the updated code:

```javascript
// routes/index.js

//...existing code...
router.post('/dashboard', requiresAuth(), async function (req, res, next) {
   // get an instance of the ManagementClient.
   const management = getManagementClient();

   // get a list of Self-Service Profiles.
   const { data: ssoProfiles } = await management.selfServiceProfiles.getAll();

   // use the 1st profile in this sample.
   const ssoProfile = ssoProfiles[0];

   const requestParameters = {
       id: ssoProfile.id
   };

   let bodyParameters = {};
   const action = req.body.action;

   if (action === 'create') {
       // build bodyParameter for 'create a connection'.
       bodyParameters = {
           ...bodyParameters,
           connection_config: { name: `self-service-sso-${Date.now()}` },
           enabled_clients: [process.env.CLIENT_ID]
       }
   } else if (action === 'edit') {

       // build bodyParameter for 'edit a connection'.
       // 👇 add code
       // get connections for the current client
       const { data: enabledConnections } = await management.clients.getEnabledConnections({
           client_id: process.env.CLIENT_ID
       });

       // filter a connection with the name and use the first item for this sample.
       const ssoConnection = enabledConnections.connections.filter(connection => {
       return connection.name.includes('self-service-sso-')
       })[0];

       // add connection_id to the bodyParameter.
       bodyParameters = {
           ...bodyParameters,
           connection_id: ssoConnection.id
       };
       // 👆 add code
   }

   // generate a Self-Service SSO ticket.
   const { data: ssoTicket } =
       await management.selfServiceProfiles.createSsoTicket(
           requestParameters,
           bodyParameters
       );

   res.render('dashboard', {
       title: 'Admin Dashboard',
       ticketURL: ssoTicket.ticket
   });
});
// ...existing code...
```

Let's see the details of the code.

### Retrieve an existing connection

We need to get the `id` of the connection we want to edit. You can use the [Get enabled connections for a client](https://auth0.com/docs/api/management/v2/clients/get-client-connections) endpoint to get a list of connections for the current Auth0 Application and filter the list with condition(s).

```javascript  
// get connections for the current client
const { data: enabledConnections } = await management.clients.getEnabledConnections({
   client_id: process.env.CLIENT_ID
});

// filter a connection with the name and use the first item for this sample.
const ssoConnection = enabledConnections.connections.filter(connection => {
   return connection.name.includes('self-service-sso-')
})[0];
```

`management.clients.getEnabledConnections()` method retrieves a list of connections for a specified Auth0 client (application). Because we created a Self-Service SSO connection with a naming convention in the previous post, we can apply a `filter`  to the list with the following condition:

- The name of the connection includes `self-service-sso-`.

This blog post assumes the first connection that matches the condition is appropriate.

> If you are using [Auth0 Organizations](https://auth0.com/docs/manage-users/organizations), you can use the [Get connections enabled for an organization](https://auth0.com/docs/api/management/v2/organizations/get-enabled-connections) endpoint instead. The `auth0-node` [supports](https://auth0.github.io/node-auth0/classes/management.OrganizationsManager.html#getEnabledConnections) this endpoint, too. Make sure the machine-to-machine application has `read:organization_connections` permission for the Auth0 Management API access. In another post, I will cover the combination of Self-Service SSO and Auth0 Organizations.

### Set connection_id in the bodyParameter

The final step is to set the `connection_id` value in the bodyParameter

```javascript
 // add connection_id to the bodyParameter.
 bodyParameters = {
   ...bodyParameters,
   connection_id: ssoConnection.id
 };
```

That's all. Now, everything is set to create a Self-Service SSO Ticket to edit an existing connection. We can keep using existing code to generate a ticket:

```javascript
 // generate a Self-Service SSO ticket
 const ssoTicket = await management.selfServiceProfiles.createSsoTicket(
   requestParameters,
   bodyParameters
 );
```

## Let’s See It in Action!

When you click the `Edit SSO Connection` button on the dashboard page, you will see the following page with another button that opens the URL of the generated ticket.

![Application dashboard showing a 'Click here to Configure SSO' button, which appears after the self-service SSO ticket has been generated.](https://images.ctfassets.net/23aumh6u8s0i/7EiN9VIyZ49VfY5O9EqUIV/5062b95e568a4971e9ba13389858f4d6/Self_Service_SSO_-_continue.png)

When you click the button, the browser opens a new tab with the SSO setup assistant page and the current connection settings. Customer admins can change settings here.

![The Auth0 self-service SSO setup assistant, pre-filled with existing Google Workspace connection data for editing.](https://images.ctfassets.net/23aumh6u8s0i/6gc8xwfpP0rpVYFy1lVh61/c4b4c3b107973812ef761299672490a3/Edit_SSO_connection_-_Google.png)

## Conclusion

In this post, you learned how to:

- Update the application to generate a Self-Service SSO ticket for an existing connection.

With the creation and editing capabilities of Self-Service SSO, you can provide a delegate administration feature in your SaaS. In the following posts, I will cover the details of the Self-Service profile and using this feature with Auth0 Organizations for a B2B SaaS scenario.

## Try with SaaStart: Next.js B2B SaaS Reference Application

Auth0 provides features for building a B2B SaaS application. In this post, I used Node.js/Express to showcase one of its features. If you are considering building a B2B SaaS in Next.js, try [SaaStart](https://a0.to/saastart). The app provides reference implementations of necessary features for B2B SaaS, such as multi-tenancy, login options for enterprise users, security policies, and more.

[Explore the SaaStart App](https://a0.to/saastart)   
Deploy locally using the [SaaStart GitHub repo](https://a0.to/saas-code)

Unlock Enterprise Readiness: How to Edit Existing Connections with Self-Service SSO in your SaaS App

Mira Sharma

Mira is a Product Manager on Auth0’s Enterprise Federations team. She is passionate about building connections, whether they involve OIDC tokens, puzzling out the shape of new product features, or frustrating New York Times games. When she’s not working, she’s probably writing intergalactic stories, out on a run, or in a pool somewhere.


Product Manager

How Private Key JWT Client Authentication on OIDC and Okta Enterprise Connections does away with client secrets. 

Using a client secret to authenticate an application is a bit like writing your password on a sticky note and handing it to someone else. It works, but only if everyone who touches it is careful, no one ever copies it, and you remember to change it before anything goes wrong.

For years, that’s how systems authenticated with OpenID Connect (OIDC): using long-lived, reusable secrets shared between clients and identity providers (IdPs). But in today’s threat landscape&mdash;where secrets get logged, leaked, and left behind&mdash;that model just isn’t good enough.

Now, with **Private Key JWT Client Authentication for OIDC and Okta Enterprise Connections**, available in Early Access, Auth0 offers a more secure, standards-based alternative. Instead of passing shared secrets between systems, Auth0 signs short-lived JWTs with a private key on a per-request basis, enabling signature-based trust, built-in expiration, and no shared credentials.

Combined with existing support for [Private Key JWT authentication](https://auth0.com/blog/use-private-key-jwt-to-authenticate-dotnet-app/) from applications to Auth0, this release completes the picture: both direct login with Auth0 as the IdP and federated login flows can now have security without any client secrets.

### Why Client Secrets No Longer Cut It

Client secrets have been a default mechanism in OIDC authentication flows for years, but they come with serious limitations:

* **They’re static:** Secrets don’t expire unless someone rotates them manually.  
* **They’re symmetric:** Both the client and the IdP must store the same secret.  
* **They’re hard to secure at scale:** Especially in distributed architectures or across multi-tenant environments.

This model assumes a shared secret can be protected forever. But in practice, secrets leak through misconfigured pipelines, exposed logs, stale repositories, or over-permissioned vaults.

**Private Key JWT Client Authentication** addresses these limitations, specifically in the context of enterprise federated identity flows.

### What Private Key JWT Client Authentication Enables for Enterprise Connections

This release introduces support for JWT-based authentication from Auth0 to upstream identity providers in OIDC and Okta Workforce enterprise connections.

Instead of storing and sending a `client_secret`, Auth0 now enables developers to perform client authentication using a client assertion JWT signed with a per-connection private key. The upstream IdP verifies it using the corresponding public key.

Each JWT:

* Is generated dynamically per token request  
* Expires after 60 seconds or less  
* Includes a `jti` claim for replay protection  
* Is signed with a private key managed by Auth0

No static credentials. No shared secrets. No reuse.

This capability aligns with [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523) and is compatible with identity providers that support `private_key_jwt` as their token endpoint authentication method.

### A Fully Secretless Authentication Flow

This release introduces support for asymmetric JWT-based client authentication from Auth0 to upstream identity providers, complementing the [existing Private Key JWT support for authenticating applications to Auth0](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt). While each mechanism applies to a different type of login flow \- direct (app → Auth0) versus federated (Auth0 → IdP) \- together they let organizations eliminate client secrets on both sides of the authentication process. Whether between the app and Auth0 or between Auth0 and the enterprise IdP, authentication can now rely entirely on signed, short-lived JWTs.

![Side by side comparison](https://images.ctfassets.net/23aumh6u8s0i/6785eEfdKGSLr6gwQ1mBon/ff8eedc5cf2748f1c1a5d6b7255d3621/JWTCA_Blog.png)

Here’s a side-by-side comparison of how the two mechanisms work:

![Table with side by side comparison](https://images.ctfassets.net/23aumh6u8s0i/7FlJNHOkBvcRa3iP7fbbOe/c7d545c00fd5166deba4aa1ec3980be8/Screenshot_2025-06-25_at_1.01.09_PM.png)

### How It Works

Here’s what changes when you use Private Key JWT Client Authentication for enterprise connections:

1. A user authenticates via an enterprise IdP (e.g., Okta, Ping, ForgeRock).  
2. The IdP returns an authorization code to Auth0.  
3. Auth0 generates a signed JWT using the connection’s private key.  
4. Auth0 sends the JWT (as `client_assertion`) to the IdP’s token endpoint.  
5. The IdP verifies the signature using the registered public key (JWKS URI or inline).  
6. Tokens are issued \- no shared secret ever exchanged.

This is now available in Early Access for any custom OIDC or Okta Workforce connection configured to use Private Key JWT Client Authentication.

### Why Enterprises are Making the Switch

**Asymmetric Security and No Credential Sharing** <br>
JWTs are signed and short-lived; secrets never leave your environment. Public keys are published via JWKS, and there’s nothing to store, rotate, or accidentally leak.

**Compliance with High-Security IdPs** <br>
Some IdPs require signed JWTs — not secrets — for authorization code exchange. This feature facilitates integrations with these IdPs, enabling developers to work within policy or compliance constraints.

**Secure, Auditable Key Rotation** <br>
Keys are generated and stored more securely by Auth0 per connection. Rotation is supported through the Dashboard or Management API, and Auth0 supports multi-key publishing to avoid downtime during transitions.

### Learn More and Get Started

To learn more about how to configure Private Key JWT Client Authentication for enterprise connections, check out our [Early Access documentation](https://auth0.com/docs/authenticate/enterprise-connections/client-assertion-jwt). 

Zero Trust Begins with Zero Shared Secrets

diegopoza

System Engineer, geek, foodie, technology lover, speaker.

Sr Manager, Developer Advocacy

Diego Poza

How our Customer's Users Are Connecting To Enterprise Providers



Auth0 supports authentication through a ton of different providers. Through social login, our user's users can connect via Google, Twitter, Facebook and a host of others. Auth0 also provides authentication for Enterprise clients through LDAP, Microsoft, and Google among others.

Throughout 2015 we collected data on how companies and individuals were using these providers with Auth0. We wanted to know how our users were using Auth0 and how their users were using Auth0. Which providers were the most used and how was their share changing over time.

In this second article we are looking at which Enterprise providers are most used via Auth0, how often Enterprise connections are used, and how developers can use better connections to boost security, usability and value for users.

Here’s what we found.

## What Connections Are Enterprise Using?

Auth0 has a number of Enterprise connections available to users easily from the Dashboard:

![Enterprise Connections Dashboard](https://images.ctfassets.net/23aumh6u8s0i/hEuAtmCAEiIzMbYWKGhYd/c5fc389dd6688eaaa7b5a7f85e6557ec/enterprise-connections-dashboard)

Using these allows companies to let their users connect via enterprise credentials, access internal identity providers to validate these credentials, and implement single sign on (SSO) easily for their users.

We wanted to see which of these possible connections was most common among Enterprise users:

![Enterprise Connections Usage](https://images.ctfassets.net/23aumh6u8s0i/7wAwvvsRcIH69tar3IznBp/f2b04932dce902a23a34fd026b285b6b/enterprise-connections)

**Findings:**

* Most (53%) Enterprise connections are through Active Directory Federation Services (ADFS).
* Another 35% are using Active Directory connections.
* SAMLP (7%), Microsoft Azure Active Directory (3%), and Google Apps (2%) round out the top 5.

These results show that logins via Windows Server architecture are still by far the most common connections made by Enterprise. These results tally with what we have said before—[hundreds of thousands of companies rely on Active Directory](https://auth0.com/blog/2013/04/10/Auth0-Windows-Azure-Active-Directory/). In fact, over 90% of all Enterprise connections through Auth0 are built on Windows architecture, either through AD directly, Microsoft Azure, or via Office 365 or Sharepoint.


<include src="TweetQuote" quoteText="Over 90 percent of all Enterprise connections through Auth0 are built on Windows architecture."/>


ADFS is the part of Active Directory Services that allows for resource access across traditional boundaries:

* It provides [simplified and secure identity federation](https://resources.auth0.com/build-vs-buy-evaluating-identity-management/).
* It enables the creation of trust relationships between two organizations.
* Provides access to applications between organizations.
* Provides single sign on between two different directories for web-based applications.

In this way, it acts as an easy and transparent way for a user in one organization to connect and access applications from another organization.

However, because Active Directory was designed to work on the internal corporate network, it isn’t best-suited for web-based services.

### Why People Use Microsoft Azure Active Directory through Auth0?
One of the perks of using Auth0 with Microsoft Azure Active Directory is that you gain access to more features not available in AAD standalone. By combining AAD with Auth0 you can take advantage of all our available SDKs and a better development experience.

Whether you are just getting started or already deep into a project - our SDKs will help you quickly integrate a solid authentication framework into your application. We provide SDKs for most major languages and frameworks including [Angular](https://auth0.com/docs/quickstart/spa/angularjs), [Node.js](https://github.com/auth0/node-auth0), [ASP.NET](https://github.com/auth0/auth0.net), [Java](https://auth0.com/docs/quickstart/webapp/java/01-login), and more. Our selection of quickstarts, seed projects, and tutorials showcase best practices and how-to’s to ensure you are up and running as quickly as possible.

You also get access to rules, which are JavaScript code snippets that allow easy control and customization of the login process. Rules are an easy way to address that inevitable exception in an identity environment – integration with marketing or analytics tools, whitelisting and other forms of access control, triggering a webhook, and so on. You can check the [Rules documentation](https://auth0.com/docs/rules) for more information.

## How Much Are Enterprise Connections Used?

Enterprise connections are only a small part of the possible login options available through Auth0. We wanted to see what proportion of the total logins were Enterprise compared to these other options:

![Total Users per Connection Type](https://images.ctfassets.net/23aumh6u8s0i/4jXEa8UQMFyNvlzzUYAewi/5fd14be2dbe5a03910f25f95f8c3c667/total-users)

**Findings:**

* An astonishing 70% of all logins still use username and password combinations.
* Enterprise connections account for almost a quarter (24.7%) of all logins.
* Passwordless logins currently account for less than 1% of all logins.

So 1 in 4 connections made through Auth0 are using an Enterprise connection. From this we can surmise that a significant number of Auth0 users are B2B companies, looking to make it easier for the employees of other companies to use their apps.

This is excellent news. One of the best ways for developers to [grow their revenue](https://auth0.com/blog/2015/08/18/how-to-go-upmarket-and-grow-your-revenue-by-20x) is to add Enterprise options to their existing app, such as the ability for companies to login with their current Enterprise connections.

What is less excellent news is that Enterprise connections, as well as social and passwordless, are still dwarfed by the traditional username and password combination. This means lower security, reduced compliance, and reduced B2B collaboration for those companies and users.

## Conclusion

There are two major findings from our study so far:

1. The vast majority of Enterprise connections are using Windows Active Directory in some capacity.
2. The vast majority of users are still using an individual username and password combination.

Both of these are areas of improvement. Auth0 users currently connecting through AD or ADFS could start to look seriously at using Azure for their connections instead. And Auth0 users not pushing their own users away from unique usernames and passwords should definitely consider allowing SSO, either through Enterprise or Social.

[Learn how to evaluate a modern identity management solution that fits your needs in this free eBook, Build vs Buy: Guide to Evaluating IAM.](https://resources.auth0.com/build-vs-buy-evaluating-identity-management/)


"enterprise connections"