manfred

Under the leadership of Manfred Steyer, ANGULARarchitects.io supports companies with the implementation of web-based business applications with Angular. <br>
 
At the Angular seminars he designs, he combined his profound knowledge of Angular, for which he was recognized by Google as a Google Development Expert (GDE), with his experience, which he worked as a team leader in the field of software development, as a Professor at a university of applied sciences and as an external member of the Angular team. <br>
 
Manfred has published books at O'Reilly, Microsoft Press, and Hanser and writes for Heise Online, windows.developer, and the Java magazine. He also regularly shares his knowledge at conferences.

Trainer and Consultant with focus on Angular

Manfred Steyer

Module Federation allows loading Micro Frontends at runtime. Common dependencies like Angular or the Auth0 library can be shared and hence don't need to be loaded several times. This is also the key for sharing data like the current user or global filters.

**TL;DR:** Module Federation allows loading Micro Frontends at runtime. Common dependencies like Angular or the Auth0 library can be shared and hence don't need to be loaded several times. This is also the key for sharing data like the current user or global filters.

## Micro Frontends

Recently, there have been a lot of discussions about Micro Frontends. The underlying idea is quite tempting: Splitting a huge software system into smaller parts and assigning each part to an individual team:

![Each micro frontend can be developed by an autarkic team](https://images.ctfassets.net/23aumh6u8s0i/38DpehwkPwiMTNBOvOQowG/ce345e71277e19f211f23add38a0ae4e/microfrontends.png)

As these teams are -- more or less -- autonomous, they can work in a more flexible way and don't need to coordinate that much with others. This shows that Micro Frontends are mostly about scaling teams. Hence, if you don't have several frontend teams, Micro Frontends might be overkill. 

## Module Federation

Splitting software systems into several parts is, however, only one side of the coin. Even though we developers might like this idea, the users don't! They aren't interested in starting several frontends but expect an integrated solution. 

Accordingly, we need to find a way to make all our micro frontends appear as one (single page) application. Very often, this involves loading micro frontends into a shell application.

For instance, the example used here mimics a simple shopping system. One of its micro frontends deals with shipping:

![Example micro frontend dealing with shipping products](https://images.ctfassets.net/23aumh6u8s0i/3Zs0it0naO2U4W1GwBMpNn/caa76eb2a246ab2dfa5d5394c6ed89c5/example-shipping.png)

For the purpose of integration, this micro frontend needs to be loaded into a shell:

![Example of a shell loading the shipping micro frontend](https://images.ctfassets.net/23aumh6u8s0i/iJOA5Lg4AHYGHBt0SK06U/8bdb25c11b8ac571f259f57217ff72eb/example-shipping-in-shell.png)

The shell loads this but also other micro frontends on demand.

For such an implementation, you needed a lot of tricks in the past. Fortunately, Module Federation makes this task straightforward. 

Module Federation is an integrated part of webpack 5, and hence, it works with all modern web frameworks. Also, as webpack is highly used in nearly all communities, Module Federation immediately becomes a widespread solution.

In order to allow loading separately compiled and deployed micro frontends, Module Federation defines two roles: the host and the remote:

![Schematic representation of Module Federation](https://images.ctfassets.net/23aumh6u8s0i/6RTBbIScEwfnZm97MMe7nJ/2138d86c99a988b286f9852d020097a4/module-federation.png)

In our case, the host is the shell, while the remote is the micro frontend. Both can be configured with their webpack configurations. 

The host defines virtual URLs pointing to remotes. In the previous picture, for instance, the URL ``mfe1`` pointing to a micro frontend, also called ``mfe1``, is defined.

The remote, in turn, exposes files -- or, to be more precise: EcmaScript modules -- for the host. To prevent that, the latter one needs to know the remote's file structure; exposed files can get a shorter alias. The example in the last picture goes with the alias ``Cmp``. 

Exposed EcmaScript modules can easily be loaded into the host by using a dynamic ``import`` together with the mapped URLs and defined aliases. The best: From Angular's perspective, this is just like lazy loading. 

As Angular doesn't even recognize that the application loads a micro frontend, we can use it exactly as it was intended to be used. We don't need any tricks or meta frameworks orchestrating different SPAs in our browser window. This eases our endeavor dramatically.

## Module Federation in Angular

Since version 12, the Angular CLI uses webpack 5. Hence, we also get Module Federation out of the box. To activate it, we need a custom builder that, e. g. ships with the community solution ``@angular-architects/module-federation``. As it comes with respective schematics, you can easily ``ng add`` it to your CLI workspace:

```bash
ng add @angular-architects/module-federation
```

![Adding @angular-architects/module-federation to your project](https://images.ctfassets.net/23aumh6u8s0i/3eoqQDVCE5OK0QfzoYmXt8/378fda04d26bd28ffc798754f3150819/ng-add.png)

The well-known CLI extension [Nx](https://nx.dev/) is supported too. The schematic asks about the name of the project in your workspace you want to enable module federation for. Also, it asks which port to assign for ``ng serve``.

After that, it generates several files, e. g. a partial webpack configuration we need to adjust for our needs. Also, it registers the custom builder in our ``angular.json``.

For the example used here, I ran this command twice: Once for the shell and once for the above-shown shipping micro frontend. The latter one is just called ``mfe1`` here.

## Configuring the Micro Frontends

Now, we need to adjust the webpack configurations generated for the shell and the micro frontend. As the Angular CLI is generating most parts of the webpack configuration, we just need to define the remaining details for the module federation. First and foremost, this is about configuring the ``ModuleFederationPlugin`` that ships with webpack.

Let's start with the configuration for the micro frontend:

```javascript
// projects/mfe1/webpack.config.js

[...]
plugins: [

  new ModuleFederationPlugin({
    
      // For remotes (please adjust)
      name: "mfe1",
      filename: "remoteEntry.js",
      exposes: {
          './AddressModule': './projects/mfe1/src/app/address/address.module.ts',
      },        
      
      shared: share({
        "@angular/core": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common/http": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/router": { singleton: true, strictVersion: true, requiredVersion: 'auto' },
        "@angular/material": { singleton: true, strictVersion: true, requiredVersion: 'auto', includeSecondaries: true },

        ...sharedMappings.getDescriptors()
      })
          
  }),
],
[...]
```

The property ``name`` is normally the project name and should be unique across all micro frontends. The ``filename`` points to a file webpack generates when building the project. It's often referred to as the remote entry point. This JavaScript file provides all the metadata the shell needs to know for loading the micro frontend.

While normally you can go with the generated values for ``name`` and ``filename``, you very likely need to adjust the ``exposes`` section. As discussed above, it contains the aliases for the files to expose.

With ``shared``, you define all the npm packages you want to share across the shell and the micro frontends. These packages are only loaded once at runtime. This is vital because having ten micro frontends doesn't mean you want to load Angular or other packages ten times!

Of course, when sharing packages at runtime, we might end up with version conflicts. Fortunately, Module Federation also got us covered here: It provides several strategies for dealing with version mismatches. 

In our case, the combination of ``singleton: true`` and ``strictVersion: true`` is used. Hence, only one version of the shared packages is allowed, and if Module Federation detects several versions at runtime, it throws an Error. While this seems to be quite harsh at first sight, it allows our integration tests to immediately find out about version mismatches.

More details on [strategies for preventing version mismatches](https://www.angulararchitects.io/en/aktuelles/getting-out-of-version-mismatch-hell-with-module-federation/) can be found [here](https://www.angulararchitects.io/en/aktuelles/getting-out-of-version-mismatch-hell-with-module-federation/).

Besides ``singleton`` and ``strictVersions``, there are two further properties used: ``requiredVersion`` and ``includeSecondaries``. If we set the first one to ``auto``, ``@angular-architects/module-federation`` assumes the version found in your project's ``package.json``. This avoids several [pitfalls](https://www.angulararchitects.io/aktuelles/pitfalls-with-module-federation-and-angular/). 

The option ``includeSecondaries`` is provided by ``@angular-architects/module-federation`` too. It automatically adds all secondary entry points to the list of shared libraries. In the case of libraries like Angular Material, this saves you a lot of typing as they provide one such entry point per component, e. g. ``@angular/material/input`` or ``@angular/material/button``.

Now, let's have a look at the exposed ``AddressModule``: 

```typescript
// projects/mfe1/src/app/address/address.module.ts

[...]

@NgModule({
  imports: [
    [...]
    RouterModule.forChild([{
      path: 'address', 
      component: AddressComponent
    }])  
  ],
  declarations: [
    AddressComponent
  ],
})
export class AddressModule { }
```

As you see, it's just an ordinary Angular module. However, as it has child routes, we can immediately route to them after loading the whole module into the shell. 

## Configuring the Shell

The shell's ``webpack.config.js`` is a bit simpler. Here, we only need to define the shared libraries:

```javascript
// projects/shell/webpack.config.js

[...]
plugins: [
  new ModuleFederationPlugin({

      shared: share({
        "@angular/core": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common/http": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/router": { singleton: true, strictVersion: true, requiredVersion: 'auto' },
        "@angular/material": { singleton: true, strictVersion: true, requiredVersion: 'auto', includeSecondaries: true }

        ...sharedMappings.getDescriptors()
      })
      
  }),
],
[...]
```

In addition, we also could map URLs here, as outlined above. This would look like this:

```typescript
// Alternative that maps URLs upfront
new ModuleFederationPlugin({
  remotes: {
    "mfe1": "mfe1@http://localhost:3000/remoteEntry.js"
  },
  [...]
})
```

The key is the mapped URL, and the value defines the name of the micro frontend as defined in its ``webpack.config.js``. Here, the value also contains the location of the micro frontend's remote entry point. To load ``mfe1``'s exposed Module, we could use a dynamic ``import``:

```typescript
// Using mapped URL:
import('mfe1/AddressModule')
```

As the TypeScript compiler doesn't know the file ``mfe1/Module``, we also needed a type definition. For this, we could create an arbitrary with the ending ``.d.ts``:

```typescript
declare module "mfe1/AddressModule";
```

However, while mapping URLs this way is simple, it also requires us to know about the micro frontends and their locations upfront. Hence, I'm using a more dynamic approach that does not demand us to define URLs for compile time. 

Instead, we can tell Module Federation about possible Micro Frontends at runtime. To make use of it, I use the helper function ``loadRemoteModule`` provided by ``@angular-architects/module-federation`` together with lazy routes:

```typescript
// projects/shell/src/app/app.module.ts

[...]
RouterModule.forRoot([
  {
    path: '',
    component: HomeComponent
  },
  {
    path: 'mfe1',
    loadChildren: () => loadRemoteModule({
      remoteEntry: 'http://localhost:3000/remoteEntry.js',
      remoteName: 'mfe1',
      exposedModule: './AddressModule',
    }).then(m => m.AddressModule)
  }
])
[...]
```

The ``loadRemoteModule`` function takes the location of the remote entry point, the remote's name, and the alias of the exposed EcmaScript module. All these values are defined in the micro frontend's webpack configuration. 

As these properties are just strings, we could even retrieve their values from a configuration file or from a service endpoint.

## Trying It Out

After starting both projects, e. g. with ``ng serve shell, `` and ``ng serve mfe1``, we can use the lazy route shown above to load the micro frontend into the shell. It's also interesting to inspect the loaded files in your browser's dev tools:

![The browser loads the shared libraries](https://images.ctfassets.net/23aumh6u8s0i/5YzAFolOzvMYTspPsgZ5Wb/73d1fb9772e1128fca2eca404a1aa0ce/share.png)

At first sight, it really looks like lazy loading. However, when looking more closely, we see that the lazy chunks come from the micro frontend's origin. Also, for all the shared libraries, a bundle of its own is loaded. This is necessary because the module federation decides at runtime when to load which shared package. 

## Authentication for Micro Frontends

Sometimes we need to share some information between micro frontends and the shell, e. g. context information like the current user or global filters like the selected customer. The example used here allows logging in the user via the shell:

![Logging in the current user](https://images.ctfassets.net/23aumh6u8s0i/2XumqnUE2Cp56cB0nWJt2w/37480acbfca69c8036e36d38b94fbcd2/logged-in.png)

However, when loading the micro frontend on demand, it also knows about the current user:

![Sharing information about the logged in user](https://images.ctfassets.net/23aumh6u8s0i/2BdJ84YhuAxliC349B9A2Q/6294f33fd3d8b940789da984d41efe8c/logged-in-shipping.png)

To achieve this, we just need to share a package that holds the information to share. In our case, this is ``@auth0/auth0-angular`` as we are using Auth0 as our identity provider. It's available via npm:

```bash
npm i @auth0/auth0-angular
```

To make this work, I've configured a web application at https://manage.auth0.com/. If you want to try this out, don't forget to register your SPA's URL, e. g. http://localhost:4200, under _Allowed Callback URLs_. Besides this, I went with the default values proposed by the web portal.

To get started, we need to import the ``AuthModule`` provided by ``@auth0/auth0-angular`` into the ``shell``'s but also into ``mfe1``'s ``AppModule``:

```typescript
// projects/shell/src/app/app.module.ts
//  and
// projects/mfe1/src/app/app.module.ts

[...]

import { AuthModule } from '@auth0/auth0-angular';

[...]

@NgModule({
  imports: [
    AuthModule.forRoot({
      domain: 'dev-ha-6vf7s.us.auth0.com',
      clientId: 'pQXuZGn3bfOfHpFd9ch7Wfa4xP4KhKlS'
    }),
    [...]
  ],
  [...]
})
export class AppModule { }
```

The values for ``domain`` and ``clientId`` can be found at https://manage.auth0.com after registering your application.

After that, we can use the ``AuthService`` in the shell to login the current user:

```typescript
// projects/shell/src/app/home/home.component.ts

import { Component } from '@angular/core';
import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
  styleUrls: ['./home.component.scss']
})
export class HomeComponent {

  user$ = this.auth.user$;

  constructor(private auth: AuthService) {}

  login(): void {
    this.auth.loginWithRedirect();
  }

}
```

I also decided to display the user's name after they logged in:  

```html


<h1>Welcome!</h1>

<p *ngIf="user$ | async as user">
    User: {{user.name}}
</p>

<div>
    <button (click)="login()" mat-flat-button color="primary">Login</button>
</div>
```

In the micro frontend's ``AddressComponent``, I'm also using the ``AuthService`` to get some information about the current user:

```typescript
// projects/mfe1/src/app/address/address.component.ts

[...]

import { AuthService } from '@auth0/auth0-angular';

@Component({
  selector: 'app-address',
  templateUrl: './address.component.html',
  styleUrls: ['./address.component.scss']
})
export class AddressComponent {

  [...]

  constructor(
    private auth: AuthService,
    private fb: FormBuilder) {

    this.auth.user$.pipe(take(1)).subscribe(user => {
      if (!user) return;
      this.addressForm.controls['firstName'].setValue(user.given_name);
      this.addressForm.controls['lastName'].setValue(user.family_name);

    });

  }

  [...]
}
```

In order to make this work, we need to share the ``@auth0/auth0-angular`` package:

```javascript
// projects/shell/webpack.config.js
//  AND
// projects/mfe1/webpack.config.js

[...]
shared: share({
  [...]
  
  // Add this:
  "@auth0/auth0-angular": { singleton: true, strictVersion: true, requiredVersion: 'auto' },

  ...sharedMappings.getDescriptors()
})
[...]
```

This ensures there is only one ``AuthService`` at runtime we can use to share information about the current user. 

After changing the webpack configuration, we need to restart our applications. If everything works well, we can log in the user via the shell and read the user's name in the lazy loaded micro frontend.

## Summary

Module Federation allows loading separately compiled applications at runtime. Also, we can share common dependencies. This also allows sharing common data like information on the current user or global filters.

As Module Federation allows runtime integration, it is also the key for plugin systems and micro frontend architectures. However, this approach turns to compile-time dependencies into runtime dependencies; we need a sound set of integration tests to detect issues. 

In general, Micro Frontends only makes sense if you want to scale a project by splitting it into several smaller applications developed by different autarkic teams. If you only have one frontend team, Micro Frontend architectures are very likely an overhead.

Micro Frontends with Angular, Module Federation, and Auth0

Vittorio

Vittorio Bertocci is a Principal Architect for Auth0. Before Auth0, he had a lengthy career with Microsoft, where Vittorio worked with Fortune 100 and Global 100 companies, including working on Microsoft’s Azure Active Directory team as principal program manager focusing on the developer experience. He contributed to the inception and launch of Microsoft's claims-based platform components (Windows Identity Foundation and ADFS, ADAL and MSAL SDKs, ASP.NET middleware). Vittorio is a well known speaker, educator and published author.

Principal Architect

Vittorio Bertocci

Explore how FastFed is looking to shorten the time it takes to join organizations into a federation.

## The Overview

In this episode of _Identity, Unlocked_, principal architect at Auth0 and podcast host Vittorio Bertocci focuses on OpenID foundation’s FastFederation ([FastFed](https://openid.net/wg/fastfed/)) group. Vittorio chats with Darin McAdams, a software engineer at AWS and the author of FastFed’s specifications, to explore how FastFed is looking to shorten the time it takes to join organizations into a federation.

Darin explains that Dick Hardt, one of the founders of FastFed, zeroed in on him to edit and draft the spec for FastFed. Darin began at the beginning, creating a sample G Suite and trying to set up a federation between both AWS and Salesforce. When he finally arrived at a place to begin joining the orgs, he was stuck - the first line, the first page, the needle scratches, and he doesn’t know how to proceed.

Eventually, after reading the SAML specs and following Google’s directions for integration, a long drawn out process of over 40 steps, Darin was finally able to integrate his sample G Suite with AWS, but never Salesforce. It became clear to him this process could be made much faster through automation.

FastFed is going after integrating a push-button single-sign-on experience for users of a federation, and to do so, they have to develop the communication between different authentication programs used by the organizations. FastFed also runs into the complications of communicating between identity providers, enterprise security preferences, and creating trust between the orgs. 

Darin and Vittorio dive into more details of the problems faced creating FastFed and scaling down a program with a vast scope into a push-button user experience.

## Key Takeaways

Darin explains how he discovered the problem FastFed is trying to solve:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/976ce3a6"></iframe>

How FastFed is looking to make the problem better:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/d79c5e15"></iframe>

Darin discusses the logical problems FastFed had to solve:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/1e42983d"></iframe>

SCIM’ing the problem. Funneling the multiple implications of SCIM into a single solution:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/a4e48489"></iframe>

Darin calls on engineers:

<iframe width="100%" height="230px" scrolling="no" style="border: none" src="https://identityunlocked.auth0.com/player/220d2e54"></iframe>


### Links/Resources:

Connect with Darin McAdams on [LinkedIn](https://www.linkedin.com/in/darin-mcadams-3950b52/)<br />
Connect with Vittorio Bertocci on [LinkedIn](https://www.linkedin.com/in/vittoriobertocci/)<br />
Connect with Vittorio Bertocci on [Twitter](http://www.twitter.com/vibronet)<br />

Learn more about [Identity, Unlocked](https://identityunlocked.auth0.com/public/49/Identity%2C-Unlocked.--bed7fada/episodes)<br />
Learn more about [Auth0](https://auth0.com/)<br />
Learn more about the sponsor for this season, the [OpenID Foundation](https://openid.net/foundation/)<br />

<include src="asides/IdentityUnlocked" />

<include src="asides/AboutAuth0" />

Identity, Unlocked... Explained: Season 2, Ep 6

diegopoza

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

Sr Manager, Developer Advocacy

Diego Poza

Enable your upmarket strategy with the right technical infrastructure



Enterprise customers are demanding.

Long sales cycles, filled with requests for custom features and integrations, can monopolize your developers and your sales team. If a contract falls through, a lot of time and money will fall through with it.

But the [_move upmarket_](https://auth0.com/blog/how-to-go-upmarket-and-grow-your-revenue-by-20x/) doesn't need to be such a struggle. If you're willing to slightly alter your sales strategy, you can quickly impress new clients and close enterprise deals.

Enterprise clients present three primary challenges to growing B2B companies:

1. **Legacy technology stacks**: Enterprises prioritize stability and often favor products from companies that have long histories in their industries.
2. **Intensive security demands**: Enterprises handle large volumes of data that make security breaches especially risky.
3. **Unique needs**: Enterprises have numerous stakeholders who need to be satisfied, some of whom will demand simplicity and others customization.

With Auth0's [_B2B federation_](https://auth0.com/b2b-enterprise-identity-management/), you can shorten the sales cycle with compatible infrastructure, ensure that the connections between your product and their employees are secure, and address their unique needs with custom configurations.

![Auth0 helps B2B companies grow](https://images.ctfassets.net/23aumh6u8s0i/76cbcjek9FIZY6nxQmvdZR/f0a096097a955ecfb53f099394e91092/b2b_1)

## Offer Compatibility Options to Shorten Your Sales Cycles with Enterprise Customers

The bigger an organization gets, the more internal and third-party tools — all potentially built on different stacks with different protocols — are likely to be in use. The person you're initially selling to might not even know all the infrastructure complications lying in wait.

A primary example is identity and access management (IAM) providers. Your ability to integrate with whichever provider your customers use can drastically shorten or lengthen the sales cycle. If they use Active Directory (and _[hundreds of thousands do](https://auth0.com/blog/analysis-of-enterprise-connections-data/)_), you'll need to implement that before you can close the deal.

If you let the sales cycle stretch out (already _[estimated at 3-6 months](https://saasmetrics.co/benchmark-for-b2b-saas-sales-cycles/)_ for deals that exceed \$100,000 in annual contract value), your internal advocate might move to a different position or company, or the benefits of your initial pitch might not remain relevant. Meanwhile, you might be losing out on other opportunities as you pay expensive developers to make your back end work with theirs.

Worse, if your next customer has a different back end, you'll have to do it all over again.

Auth0 offers B2B federation that _[integrates with 10+ IAM providers](https://auth0.com/blog/how-enterprise-federation-helps-shorten-the-sales-cycle/)_. With a few lines of code, you can configure any enterprise connection, including Active Directory, LDAP, ADFS, SAML, and more.

![Auth0 enterprise connections](https://images.ctfassets.net/23aumh6u8s0i/6HTuHDmDrVhGoM64N5W5VT/fbf838da10673560329d5dfcd92070f3/why-federation-is-your-secret-weapon-for-enterprise_auth0-enterprise-connections)

B2B federation provides the technical compatibility that makes your product more trustworthy and easier to use. By configuring your app with Auth0, you effectively configure it for numerous providers at once.

A sustainable [_enterprise sales strategy_](https://sapphireventures.com/oiling-the-enterprise-it-sales-engine/) builds from one company to the next, so you don't need to start over each time.

<include src="TweetQuote" quoteText="Auth0 offers B2B federation that integrates with 10+ IAM providers. Active Directory, LDAP, ADFS, SAML? Bring it on!"/>

## Show Enterprise Customers They Can Trust You

High-profile [_data breaches_](https://auth0.com/blog/what-is-a-data-breach/) have made enterprises increasingly risk-averse. To a wary enterprise, another partnership might seem like another vulnerability. New products, though they might be valuable, risk widening an enterprise's attack surface.

Enterprises are more likely than SMBs to have security and compliance teams that will take a critical look at your product. These teams need more than assurance. Their input for your service-level agreements will go beyond up-times and scalability and into strict security parameters and compliance standards.

If you provide federation through Auth0, however, maintaining security and compliance in the authentication process is much easier. Auth0 combines the simplicity of a federated identity provider with customizable security features. Your customers can enable tools like multi-factor authentication (MFA) and reinforce compliance procedures as necessary.

![Auth0 multi-factor authentication](https://images.ctfassets.net/23aumh6u8s0i/5zHCdntb8UHVwFG6QBnhd4/2b9f2ba4cfbcab1461b35f82e76d4e8c/why-federation-is-your-secret-weapon-for-enterprise_auth0-multi-factor-authentication)

With MFA, your enterprise clients know that access to sensitive materials won't be granted to anyone with a username and password. Despite these barriers to malicious access, administrators can approve requests easily across a variety of devices.

Guardian, Auth0's MFA application, also provides Mobile SDKs for [_iOS_](https://auth0.com/docs/multifactor-authentication/developer/libraries/ios) and [_Android_](https://auth0.com/docs/multifactor-authentication/developer/libraries/android) that enable you to build a white-labeled MFA application that matches a customer's branding.

Auth0 is compliant with a [_wide range of security, privacy, and compliance standards_](https://auth0.com/security/), such as HIPAA BAA, SOC 2 Type II, and PCI DSS, so you can demonstrate an understanding of your customer's industry-specific needs.

If you're competing with other products that have similar value propositions, the trust you build with enterprise customers can tip a decision in your favor. With Auth0 backing you, it's easier to address concerns from security and compliance teams. The faster and better you can satisfy these stakeholders, the closer you can get to completing a deal.

<include src="TweetQuote" quoteText="Auth0 is compliant with a wide range of security, privacy, and compliance standards such as HIPAA BAA, SOC 2 Type II, and PCI DSS that lets you cover your customer's industry-specific needs."/>

## Sell across Organizations with Single Sign on and Customization

Selling to an enterprise requires selling across levels and [_pleasing different parties_](https://www.copper.com/blog/enterprise-sales-prospecting). Your point of contact might be excited by the core value proposition, but the project managers might be worried about its execution. If all decision-makers aren't in agreement, a deal months in the making can fall apart.

Authentication can be a significant hurdle. IT staff, for example, might resist a new product if it threatens to increase their account-management workloads. Other stakeholders might resist the sheer addition of more credentials to memorize.

Single sign-on (SSO) can dispatch these concerns. With Auth0, employees will only have to enter their credentials once.

![Auth0 single sign-on](https://images.ctfassets.net/23aumh6u8s0i/51MTEF6y286lEpPFiuWMMC/5b67cb0f5643bb655fe06ddf981240cc/why-federation-is-your-secret-weapon-for-enterprise_auth0-single-sign-on)

Enterprises have a higher volume of users and tools, so the ability to sign on once is compelling.

Safari, a company that provides access for corporate learning materials, [_leveraged Auth0's SSO capabilities_](https://auth0.com/learn/safari-case-study/) to expand to enterprise customers. SSO cut support calls for account management without Safari having to dedicate specialized resources. They have since added numerous enterprise customers, differentiating their offering with easy authentication across desktop and mobile devices.

If you need to make integration and usage even smoother, Auth0 also provides customizable _[Rules](https://auth0.com/docs/rules)_. With this customization engine, you can make unique authentication and authorization stages for the customers that need it.

You can use Rules to assist migration by reusing information from existing databases, maintain a white list for particular users, notify systems of login attempts, and more.

## Moving Upmarket Requires a Renewed Strategy

Moving upmarket is more complicated than aiming your sales team at a different target. While you might be able to [_validate product/market fit_](https://www.intercom.com/blog/podcasts/the-myths-of-product-market-fit/) with smaller companies first, moving to enterprise clients requires significant planning.

Moving too fast can threaten your stability. A big contract might seem like a win at first, but without a [diverse customer base](https://www.inc.com/magazine/201606/jason-fried/saying-no-to-large-enterprise-customers.html), too much of your sustainability might hinge on a single large customer. If you shift your business to serve only a few clients, then your future belongs to those contracts—and that's a position no one wants to be in.

Closing deals with enterprise customers means closing the gap between a legacy provider's track record and your ability to meet the needs of your customer. The better you can tailor your product to their needs, the more you'll be able to _[shorten the sales cycle](https://blog.getbase.com/3-hurdles-slowing-sales-cycle)_ and build more valuable relationships for the long-run.

<include src="asides/AboutAuth0" />


Why Federation Is Your Secret Weapon for Enterprise

Get inside your customers' heads by centralizing your data.



---

Having a 360 view of your customers might sound like just another marketing cliche designed to sell CRM software. But the idea—that you should have a comprehensive understanding of your customers at all stages of the lifecycle, from acquisition to referral, is essentially the holy grail of all growth marketing efforts.

> Auth0 can help B2C companies to enrich the profile of their customers through an easy to use [Modern Customer Identity Management solution](https://auth0.com/b2c-customer-identity-management). Increase brand loyalty with better conversion, boost your revenue with new user acquisition, and secure customer identity with state-of-the-art technology.

Back in the early days of apps and the internet, a 360 view was easier to acquire. User identities were simply more consolidated. You didn't have dozens of SaaS tools running off the cloud, your users' identities weren't dispersed across Google, Facebook, and every other social platform —  all your users' data was stored in your own system. You were in charge.

Those days are gone. The landscape is fragmented by all different kinds of identity providers, authentication protocols, and tools.

What you have instead is a vast explosion of user data and tools for analyzing that data. That's made getting a 360 view of your customers more technically complicated—but it's also made it far more powerful.

## Your Identity Management System Needs a Single Source of Truth

The biggest roadblock to getting a 360 view of your users is how identity is managed. The complexity begins when a user signs up for your app and it expands entropically as they use it. Your different SaaS tools and monitoring systems collect all of this information, send it back to their servers, and then you wind up fighting with their APIs and integrations to make sense of all of it.

That's why the best analytics teams begin the process of collecting data at the root—when a user first signs up for an app.

The easiest way to do that is to set up a classic 1:1 authentication system. You control user registration and login, you manage their passwords, and you are the only entity that is involved. Therefore, you have total access to your users' data and the data of any external APIs you might integrate with.   

What makes this tricky today is that federated identity management is such an established practice. You want to be enabling social and enterprise login if you have an app of any size, or a new app that you want people to feel comfortable using. Federated identity managers are simply not based on a centralized model—consolidating your customer view into one place will involve a ton of development time and effort.

That's why we built [Auth0](https://auth0.com), an identity provider that acts as both a classical identity provider and a federated identity manager.

![Auth0 Value Prop](https://images.ctfassets.net/23aumh6u8s0i/6FQek2JcD5SJ17wxsQi6tw/ab95045e16579bd858d63068c7ca7ad8/venndiagram)

This allows you create the foundations on which to start building and acting upon your 360 view of your customer:

* **Classic identity management**:
    * **Auth0**:
        * stores login credentials for every unique user
        * provides user information on an analytics dashboard
        * manages all of the users in your organization, no matter what they used to log in

* **Federated identity management:**
    * **Social login**: User and password from Facebook, Google, Twitter, etc. serve as login information for connection to the desired platform through Auth0
    ![Auth0 Providers](https://images.ctfassets.net/23aumh6u8s0i/4K4wQdWfj9upCjTaoQG2wT/6e717e3ec553b2813fd5dd1f412a2f08/auth0-social-login)
    * **Enterprise login**: Enterprise credentials are used to access a variety of systems and platforms, where the username and login are stored in an internal identity provider but connected through Auth0

> Auth0 provides the simplest and easiest to use [user interface tools to help administrators manage user identities](https://auth0.com/user-management) including password resets, creating and provisioning, blocking and deleting users.

This type of data collection means that you can connect user information that would otherwise be stored in completely separate places — maybe data that isn't even collected directly by your app. Putting the missing pieces in your user profile for a 360 view gives you what you need to customize your user interaction, from onboarding to upselling.

## Automate the Error Out of Your Data Centralization

Within your own system, you use a variety of tools to help you monitor and engage with users. Maybe you have an app analytics platform to gather behavioral data, an email management system to send personalized emails, a CRM, and a login platform like Auth0. These systems tend to rely on client-side analytics, which makes the perfect storm for data to slip through the cracks.

Client-side analytics are notoriously unreliable. Because they have to be executed on the user's end when they first visit your site, they can easily be disrupted:

* Users might exit out of a page before your code runs
* They could block JavaScript (with an ad blocker, for instance)
* They might click on a link before the page has finished loading and interrupt the loading script

Meanwhile, server-side analytics are unwieldy and difficult to implement. In order to get all of your desired server-side analytics running with your system, you'll end up running through a web of APIs and [writing more and more code](https://segment.com/blog/the-way-server-side-analytics-should-be/) just to get everything working smoothly.

That's where Auth0 Rules come in. Rules are snippets of server-side Javascript that run as soon as a user logs in, eliminating the client-side reliability problem while being just as easy to set up and get going.

![Auth0 Identity Flow](https://images.ctfassets.net/23aumh6u8s0i/3fDhde4dlCPTWQh6awAULV/5f0c496d5f0636dae76328b547ca8500/flow)

With [Auth0 Rules](https://auth0.com/docs/rules), your server-side automation always gets information from your user to your tools. For example, if you wanted to create a lead in Salesforce the first time a user logs in, you can [use an Auth0 Rule to instantly send] (https://github.com/auth0/rules/blob/master/rules/creates-lead-salesforce.md) the signal to Salesforce to make a new lead.

In fact, you can connect Auth0 with pretty much any platform by creating automated actions at sign in using JavaScript. And they're just a few lines of code — not a forest of API integrations.

You need to know that your tools are going to get the data they need to help you understand how your customers are behaving, and automating a cross-platform integration ensures that you [realize the power of all of your SaaS platforms](https://auth0.com/blog/integrate-auth0-into-your-existing-saas-tools/).

## Use Your Centralized Data to Cater to Your Customers

A rich, 360 view of your customers is a springboard for fine-tuning your product to increase customer satisfaction. The way you interact with your users  from login onwards can make or break whether or not you retain those customers, no matter how good your product is.

When you're unable to consolidate all the information that you know about your customers, you can easily wind up asking them the same questions twice. Getting information about who your customers really are turns into a slow and error-prone process. When you have a centralized repository of knowledge about your users and a reliable infrastructure for gathering data on them, however, you can put much more effective and subtle collection practices into place.

A great example of this is [progressive profiling](https://auth0.com/blog/progressive-profiling/). You want to ask your users questions about who they are and why they're using your product, but you know that slamming your users with a huge form as soon as they sign up ruins your conversion rates. With Auth0, you can create a Rule that triggers every time your users log in. You can ask them questions intermittently—throughout their customer journey—rather than giving them a huge survey up-front.

![Progressive Profiling](https://images.ctfassets.net/23aumh6u8s0i/1At7rnzD0X0Q7fLQauxuUV/4899e717b5cf6f8920b905af80927397/progressive-profiling-2)

Auth0 helps you store all of this information through creating profile records. You can gather information from an existing identity (like a Facebook profile), an Auth0 Rule, or information the user adds to their profile. Each users' profile record will get updated as data rolls in, to keep all of that valuable information accessible.


Capturing and centralizing log in information is a great way to make your users' experience better, especially when it is part of a larger customer profile. When the user experience is good, your customers are satisfied, and there's nothing better for business than satisfied customers.

## Aside: Securing Applications with Auth0

Are you building a [B2C](https://auth0.com/b2c-customer-identity-management), [B2B](https://auth0.com/b2b-enterprise-identity-management), or [B2E](https://auth0.com/b2e-identity-management-for-employees) tool? Auth0, can help you focus on what matters the most to you, the special features of your product. [Auth0](https://auth0.com/) can help you make your product secure with state-of-the-art features like [passwordless](https://auth0.com/passwordless), [breached password surveillance](https://auth0.com/breached-passwords), and [multifactor authentication](https://auth0.com/multifactor-authentication).

[We offer a generous **free tier**](https://auth0.com/pricing) to get started with modern authentication.

## To Delight, You Must First Understand

Creating a complete profile for your customer is one of the most important steps you can take to turn your users' actions into insights.

Think of all the bad email marketing campaigns you've deleted from your inbox, or marked as spam. Think of all the irrelevant push notifications you've gotten. Think of all the products you've downloaded with high hopes only to see an onboarding process that seems like it wasn't designed with *anyone in mind.*

When you centralize your data collection and build up the right infrastructure around it—the kind that lets everyone on your team get on the same page—then you become capable of building truly personalized, delightful experiences across every part of your app.


How To Get A 360 View of Your Customer By Managing Identity

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

Martin Gontovnikas, a.k.a Gonto, is a software engineer at heart who moved to the ‘dark side’ and became VP of Marketing at Auth0. He considers himself lucky to have found a way to combine his two passions and apply his engineering thinking model to marketing.<br/><br/> Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Optimizing your login for enterprise customers can help you save time and close deals.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Forrester Consulting analysis determines that using Auth0 can yield a 548% ROI and $3.7M in identity-related savings. Read the full report: <a href="https://resources.auth0.com/forrester-tei-research-case-study/">Total Economic Impact of Auth0</a>.</strong>
</div>

---

Enterprise customers are great. They're large, stable accounts that can represent a real win for your business. But they're also a unique challenge, and more complicated than small to medium-sized businesses (SMBs).

> [Give your customers **enterprise identity integration**, frictionless SSO across your products and adaptive authentication with **MFA and Anomaly Detection**. All of this with a flip of a switch.](https://auth0.com/b2b-enterprise-identity-management)

Selling to enterprise clients has always meant managing:

* Long sales cycles
* Custom solutions
* Specific needs

But in 2017, in the aftermath of some of the most prominent hacks of all time, it also means keeping up with enterprise companies that are getting extra serious about making sure that their security practices are airtight.

Implementing Auth0, with support for 10+ types of enterprise IAM federation, is the best way to shorten your sales cycle with these companies and make sure you don't have to do frantic work on the back-end to make deals happen.

## How selling to enterprise companies usually works

You've built a product that you've been selling to SMBs. But, finally, you're starting to get a foothold with enterprise-level customers. Your hard work is paying off, and you line up a deal with Coca-Cola. Things are really moving for your business, and it feels amazing.

As it turns out, Coca-Cola uses Active Directory for their IAM, so if you want Coca-Cola employees using your product, you need to implement Active Directory. Of course, you get right on it to close the deal, but it takes three months, which stretches your sales cycle out much longer than it could be.

After your deal with Coca-Cola closes, you're feeling good about your ability to serve the enterprise customer. So you go to Disney and you try to sell to Disney. Bad news comes almost immediately: Disney uses SAML!

Now you have to go through the whole process all over again. Extending your sales cycle because of compatibility issues is just time and money being constantly thrown away. On top of that:

* It doesn't present your business in the best light
* Your internal champion at your enterprise customer could leave or be fired in those three months
* Opportunities could be lost elsewhere because you had to spend time building this integration
* You have to spend even more money on developers making those integrations happen

This is not a cycle you want to be stuck in. **And many of your customers are going to have these kinds of requirements if you want to sell to them. **Based on data we've collected about enterprise identity management, we learned that **hundreds of thousands of companies rely on **[**Active Directory alone**](https://auth0.com/blog/analysis-of-enterprise-connections-data/).

![Enterprise Connections](https://images.ctfassets.net/23aumh6u8s0i/7Go0R7SCnxCiybuPGVQwVu/68158c7587c8955ea184a5663625ffe5/enterprise-connections)

* Most ([53%](https://auth0.com/blog/analysis-of-enterprise-connections-data/)) Enterprise connections are through Active Directory Federation Services (ADFS).
* Another [35%](https://auth0.com/blog/analysis-of-enterprise-connections-data/) are using Active Directory connections.
* SAMLP ([7%](https://auth0.com/blog/analysis-of-enterprise-connections-data/)), Microsoft Azure Active Directory ([3%](https://auth0.com/blog/analysis-of-enterprise-connections-data/)), and Google Apps ([2%](https://auth0.com/blog/analysis-of-enterprise-connections-data/)) round out the top 5.

You've got to be able to handle these requirements to get your product in the door with enterprise customers.

## Safari Books case study

A great example of how Auth0 can be easily integrated into to your app to open up enterprise possibilities is through Safari Books Online.

Safari Books Online was facing a predictable pattern of long sales cycles and new development time when they first started to go upmarket and sell their design resources, videos, and e-books services to the enterprise customer.

At first, they tried to implement all the enterprise demands they were receiving in-house, but realized they couldn't upgrade their login quickly enough. Understanding what they stood to lose, [they sought out an IAM](https://auth0.com/learn/safari-case-study/).

Safari Books Online chose Auth0's secure enterprise login options to upgrade their platform and implement logins across enterprise requirements. This dramatically shortened their sales cycle and gave them the functionality they desperately needed.

“Compared to the costs and resources required to build, host, and secure a custom solution, the [investment associated with a third-party authentication service like Auth0 was a sensible choice](https://auth0.com/learn/safari-case-study/),” said Safari engineering manager Cris Concepcion.

Today, Safari Books Online is used by a wide range of enterprise clients, from Google to Tesla.

## How enterprise sales work with Auth0

When you use Auth0, you immediately cut down on the time that your team has to spend doing heavy lifting on the compatibility front. Auth0 allows you to make your app work with 10+ different enterprise identity providers, out of the box.

![Auth0 Enterprise Options](https://images.ctfassets.net/23aumh6u8s0i/5ynuPzl9slsUiwlQMJGjjv/8ca714b810e83d36766ce74e92235757/options)

Auth0 acts as an intermediary between your app and your users. It seamlessly integrates into your product, but [keeps your app isolated](https://auth0.com/docs/identityproviders) from any changes to or idiosyncrasies of different implementations. This means you can keep maximum function for your app with minimal effort for login.

![Enterprise Overview](https://images.ctfassets.net/23aumh6u8s0i/36Kv7HYvkMsIfmuLhU42Sn/6209062afe5c49e9d850cca4f10c9dd8/overview)

Using Auth0 to ramp up your security and login doesn't just shorten your sales cycle for one customer, but also gives you the tools to fit your login to a wide variety of enterprise needs. If you configure compatibility between Auth0 and your app once, you've configured compatibility for 10+ identity providers in one fell swoop.

Auth0 also gives you the power to add other critical features that enterprise customers want, like [multi-factor authentication](https://auth0.com/multifactor-authentication) and [single sign-on](https://auth0.com/learn/how-to-implement-single-sign-on/).

## The power of the enterprise customer

Enterprise contracts can represent a big win for your business and are one of the best ways to maximize your revenue.

The enterprise customer wants great solutions to their problems, and it's likely that a well-crafted product that works for SMBs will [scale extremely well](https://auth0.com/blog/how-to-go-upmarket-and-grow-your-revenue-by-20x/?utm_source=twitter&utm_medium=sc&utm_campaign=saas_upmarket) to an enterprise venture. Add a few extra perks, like a designated point-person and a higher user limit, and you've paved the path to scale up.

The key is to couple this with enterprise-ready security and identity management.

If enterprise customers want employees to be able to sign in with their existing logins instead of creating more accounts, you can use Auth0's [single sign-on](https://auth0.com/docs/sso) to streamline your product's integration. If they want to hone in on security, you can offer [multifactor authentication](https://auth0.com/multifactor-authentication) that requires both a login and an additional security precaution, like a fingerprint scan, or a verification code.

Whatever their need, a good IAM integration will help you cater to it.

This will allow you to take that premium plan and charge a premium price. Better yet, when you use an IAM, that “premium plan” can be ready as soon as you decide to go after enterprise clients. When you offer enterprise login and security compatibility, you instantly open the door to a whole new — and efficient — revenue stream.


How Enterprise Federation Helps Shorten The Sales Cycle

eugenio-pace-new-avatar

Pace co-founded Auth0 in early 2013 with CTO and “brother-in-arms” Matias Woloski while living 7,000 miles apart from each other. Since then, Pace has played an instrumental role in growing Auth0 into a leading identity management company that is loved by developers and trusted by global enterprises. He loves traveling and has visited more than 35 countries for business and pleasure. He currently lives in Redmond, Washington with his wife, two sons, and their labrador retriever. In his spare time, he enjoys the outdoors, rowing, riding bikes, spending time with his family, restoring his 1970 Karmann Ghia, writing his blog, and reading history and philosophy.

CEO and Co-Founder

Eugenio Pace

Supporting SharePoint is a prime scenario in Auth0 and it's fully integrated into it. In this post we show how SharePoint can accept users authenticated

Supporting SharePoint is a prime scenario in Auth0 and it's fully integrated into it. In [this post](http://blog.auth0.com/2013/03/04/On-Premises-SharePoint-Federated-with-Office-365-and-Google/) we show how SharePoint can accept users authenticated in Google and Office365. In [this other one](http://blog.auth0.com/2013/03/07/On-Premises-SharePoint-Federated-with-Partner-AD/) we do the same with a partner using Active Directory.

In this post, we show how easy it is to **configure** SharePoint for claims based authentication.



We have fully integrated the experience into Auth0 control panel so setup is as simple as:

-1. Entering your SharePoint URL
-2. Running the PowerShell scripts we generate for you on your SharePoint box

And that's it!

![SharePoint SAML Federation](https://images.ctfassets.net/23aumh6u8s0i/42Yqn0JZANWEgdlrtxSz5r/5dffe2c889fc75aa502bd979da1ff378/auth0-sharepoint-setup)

Another example of our "just works" approach to identity management in Auth0.

[Try Auth0 yourself!](https://auth0.com)

"federation"