001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

In this post you will learn about Single Sign-On (SSO) authentication and how to use it for your web apps

[Single Sign-On (SSO)](https://auth0.com/resources/whitepapers/definitive-guide-to-single-sign-on) authentication is now required more than ever. Nowadays, almost every website requires some form of authentication to access its features and content. With the number of websites and services rising, a centralized login system has become a necessity. In this post, we will study how **SSO authentication** is implemented for the web. Read on!

<AmpContent>
<amp-youtube
    data-videoid="Vp6kx4Sd_E0"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<div class='embed-container' style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src='https://www.youtube.com/embed/Vp6kx4Sd_E0' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

## Federated Identity Glossary

The concept of a centralized or linked electronic identity is known as *federated identity*. Federated identity systems handle several concerns:

- Authentication
- Authorization
- User attributes exchange
- User management

The **authentication** aspect deals with validating user credentials and establishing the identity of the user.

**Authorization** is related to access restrictions (e.g., is the user allowed to access X resource?). 

The **attributes exchange** aspect deals with data sharing across different user management systems. For instance, fields such as *"real name"* may be present in multiple systems. A federated identity system prevents data duplication by linking the related attributes. 

Lastly, **user management** is related to the administration (creation, deletion, update) of user accounts. A federated identity system usually provides the means for administrators (or users) to handle accounts across domains or subsystems.

SSO is strictly related to the **authentication** part of a federated identity system. Its only concern is establishing the identity of the user and then sharing that information with each subsystem that requires the data. Below, we focus on this crucial aspect of a federated identity system.

![What is single sign-on separator 1](https://images.ctfassets.net/23aumh6u8s0i/2xIzg7UIbBpGNvCeRsdn4k/32f29b73fc2b4bd33bac6fe124d9bfb1/what-is-sso-1)

## Single Sign-On (SSO) Authentication

Sooner or later web development teams face one problem: you have developed an application at domain X and now you want your new deployment at domain Y to use the same login information as the other domain. In fact, you want more: you want users who are **already logged-in** at domain X to be already logged-in at domain Y. This is what SSO is all about.

![Non-Single-Sign-On Scenario](https://images.ctfassets.net/23aumh6u8s0i/4pa532TumNn6TI3gQmMWEw/0a6182b447b75b24bea1b763c1ba73a1/non-sso-scenario)

The obvious solution to this problem is to **share session information** across different domains. However, for security reasons, browsers enforce a policy known as the [*same origin policy*](https://en.wikipedia.org/wiki/Same-origin_policy). This policy dictates that cookies (and other locally stored data) can **only be accessed by its creator** (i.e. the domain that originally requested the data to be stored). In other words, domain X cannot access cookies from domain Y or vice versa. This is what SSO solutions solve in one way or the other: sharing session information across different domains.

![No cookie sharing](https://images.ctfassets.net/23aumh6u8s0i/2WJQLWBpByFyth3ufF3Af0/5f341d8816d77f20dc05c5a2f31ec89f/same-origin-policy-forbids-this)

Different SSO protocols share session information in different ways, but the essential concept is the same: there is a **central domain**, through which authentication is performed, and then the **session is shared** with other domains in some way. 

For instance, the central domain may generate a signed [JSON Web Token (JWT)](https://auth0.com/docs/jwt), which may be encrypted using [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516). This token may then be passed to the client and used by the authentication domain as well as any other domains. The token can be passed to the original domain by a redirect and it contains all the information needed to identify the user for the domain requiring authentication. As the token is signed, it cannot be modified in any way by the client.

![SSO - Central authentication domain](https://images.ctfassets.net/23aumh6u8s0i/2GrAhJRypY1XQx3TIDbqzO/ecbd47c21f1e1c1fd334a239b9015a08/using-central-auth-domain)

Whenever users go to a domain that requires authentication, they are **redirected** to the authentication domain. As users are **already logged-in** at that domain, they can be immediately redirected to the original domain with the necessary authentication token.

![Single Sign-On Authentication](https://images.ctfassets.net/23aumh6u8s0i/4hakDPwQtaPfcDNwkd4C9x/e54ee76304953540b4b71fcccbaf690a/typical-sso-v2)


## SSO Authentication with Auth0

If you have been reading about SSO online, you have probably found that there are many different implementations: OpenID Connect, Facebook Connect, SAML, Microsoft Account (formerly known as Passport), etc. Our advice is to choose whatever is simplest for your development efforts. For instance, [SAML](https://auth0.com/docs/protocols/saml) is deeply entrenched in enterprise developments, so in some cases, it will make sense to pick that. If you think you will need to integrate your development with more than one alternative, don't despair: there are frameworks that allow interoperability between different SSO solutions. In fact, that's one of the things we do at Auth0.

<include src="SignupCTA" text="Try out Auth0 authentication for free." linkText="Get started →" />

You can go and check our [docs on Single Sign-On](https://auth0.com/docs/sso/single-sign-on) and the [Auth0 SSO samples](https://github.com/auth0/auth0-sso-sample).

If you remember the Typical SSO Scenario diagram we saw earlier, you can see how Auth0 comes to play in the next diagram:

![SSO with Auth0](https://images.ctfassets.net/23aumh6u8s0i/5n5APnJDhCtUiyZvyAG6rK/5a9faf400e436dd131bdee21b81c8761/auth0)

In this case, **Auth0 is the [Authentication Server](https://auth0.com/blog/what-is-an-authentication-server/)** and it works as a *bridge* between different SSO frameworks. 

<include src="ebook-ads/SsoGuide" />

## Conclusion

Single Sign-On authentication is here to stay. Decentralized systems are becoming more and more common and authentication is an essential aspect of all of them. SSO solves a big problem: how to manage the increasing number of users across a whole ecosystem of applications and services. Frameworks such as [OpenID Connect](https://auth0.com/resources/ebooks/the-openid-connect-handbook?ref=blog) and services such as the one we provide at Auth0 make [integrating Single Sign-On](https://auth0.com/learn/how-to-implement-single-sign-on/) into your new or existing applications much easier. If you are implementing authentication for a new application or service, consider integrating SSO from the get-go.

![What is single sign-on separator 3](https://images.ctfassets.net/23aumh6u8s0i/5L0CZk6C2On5CTXSHlE3MF/50e145cd648e88dd800f90ca19cfa1e4/what-is-sso-3)

What Is Single Sign-On Authentication (SSO) And How Does It Work?

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

With an identity clearinghouse, you can stay focused on your business, not figuring out who your users are.



<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>


## What Is Federated Identity Management?

In the early days of the web, your digital identities were dispersed across all the different sites and applications that you used:

* Each time you went to a new site, you made up a username and password.
* They were then stored on that site.
* Every time you returned, you had to re-enter your credentials, and so on and so forth for each site you visited.

This was an unwieldy system. Users would never stay logged in across sites, even when those sites were managed by the same organization. It was like an amusement park where you had to identify yourself as a paying visitor at each ride.

![Non Single Sign On scenario](https://images.ctfassets.net/23aumh6u8s0i/3pAEBDQyBT2dAsPrW5xepc/0a232360554394e039154ff96d1855b3/non-sso-scenario)

The problem was that if an organization wanted to have user credentials carry over from one domain to another, then there would have to be a new system for authentication. As the internet grew more complex and more interconnected, developers started to realize that siloing authentication on individual domains was not a scalable system.

## How Federated Identity Management Works

[The web's early infrastructure was not built to permit federated identity management](https://resources.auth0.com/build-vs-buy-evaluating-identity-management/)—it worked against it. In fact, it was one of the earliest and most crucial principles, the same origin policy, that made the idea very difficult to implement:

* The same origin policy states that no cookies or other information stored on an end-user's computer can be accessed except by the original *creator *of that information.
* This is fundamental—it means that domain Y can't rifle through your data and find your username and password to domain X. Without this policy, the whole idea of internet security would be moot.
* What this meant was that companies with multiple domains, if they wanted users to have a seamless, fluid experience navigating between them, had to find another way to securely transfer information.

![Same Origin Policy Forbid this](https://images.ctfassets.net/23aumh6u8s0i/Y4uwUUFRMNldhozrmwmBI/38d2f66d0e665259c3019bf48c38df01/same-origin-policy-forbids-this)

All federated identity management systems are, in some way, methods of transferring data without violating the same origin policy. Here's how it generally works:

* You (the user) try to log into the client (an app)
* A request for authentication is sent from the client to an authorization server
* Authentication is returned from the authorization server to the client
* You (the user) are permitted to access the client (or not)

This way, if domain X and Y are related, and their owners want users to move freely between the two, they can simply triangulate around an external authorization server. This benefits overall security (by exposing the client to less overall log-in attempts, and therefore less risk) but the clearest result is a unified, smooth user experience.

## The Single Sign On Era

Today, we see federated identity everywhere, most noticeably in what we call “single sign on.” With single sign on, you can log into your GMail and then open up YouTube in a different tab, for instance, and you'll stay logged in. It all hinges on a central domain verifying the status of each user as they move across sub-domains:

* You log in once
* Authentication is done through a central domain
* A token or cookie is generated to authenticate you across other domains

![Typical Single Sign On](https://images.ctfassets.net/23aumh6u8s0i/4hakDPwQtaPfcDNwkd4C9x/e54ee76304953540b4b71fcccbaf690a/typical-sso-v2)

[Dozens upon dozens](https://auth0.com/docs/identityproviders#enterprise) of different SSO identity providers have cropped up to provide this kind of service to webmasters, each with its unique requirements, uses, strengths and weaknesses:

* SAML
* OpenID Connect
* Facebook Connect
* Microsoft Active Directory
* Twitter

Some are more enterprise-focused, while some authenticate through social media and are better for personal use. Some use a decentralized system—with SAML, for instance, any node in the SAML network is capable of accepting the authentication done by another node. Some don't—when you log in through Facebook Connect, all authentication is done by Facebook.

Emerging in popularity now are passwordless systems, where your access does not hinge upon a set of credentials but your possession of some other factor, like your cell phone or unique fingerprint:

![Passwordless Connections](https://images.ctfassets.net/23aumh6u8s0i/To08k5ZER7MI9Iv5VcODK/1a512270d5e87fce8ccd47043c412529/passwordless-connections)

When you're choosing an identity provider and means of authentication, you need to take into account each provider's limitations and benefits and choose the one that's best for your users and your needs.

[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/)

## The Problem With Decentralization

Of course, the profusion of different SSO services presents a dilemma. If you're running a site, you usually choose one. That means other authentication services won't work. And the problem just gets worse the bigger your organization gets. Today, you might have:

* A dozen internal tools and third-party tools rotating in and out of use just at your own company.
* Each tool is built on a different stack and speaks to the others with a different protocol.
* Customers with tens of thousands of employees, each with their own arsenal of third-party tools.

In the old days, all corporate software was stored on massive internal server racks. There was no need to worry about integration because everything you needed was stored in one place—everything was already integrated. Now there are endless different social and enterprise options just for logging into an app:

![Social Providers](https://images.ctfassets.net/23aumh6u8s0i/13Ied0gAWBe6wLbuCrXP6R/b82464213f04accf721fcd0422e7bff5/social-providers)

![Enterprise Providers](https://images.ctfassets.net/23aumh6u8s0i/4fvVxxcQm5nkKxe9GzfgaY/6c0a42804631b8de96c08a56e67a3145/enterprise-options)

Now, providing that kind of integrated experience means negotiating between all the different identity providers that your users authenticate with, but it also means dealing with different:

* **Authorization practices:** delineating specific access restrictions, i.e. “Can user X access Y section of the site?” and keeping those consistent.
* **Attributes exchange practices**: avoiding the duplication of user data created by the interactions between different identity providers.
* **User management practices**: being able to access, create, update, and delete user accounts.

All SSO can do is authorize different kinds of people when they come to use a service—it's just one aspect of a federated identity management system.

## Auth0 and Federated Identity Management  

Auth0 is both a classic identity provider and a federated identity management system. This means that you can set it up so that:

* Users see an Auth0 log-in box when they visit your site
* When they sign up, their credentials are stored with Auth0
* When they log in, their credentials are authenticated with Auth0

<include src="TweetQuote" quoteText="Auth0 is both a classic identity provider and a federated identity management system."/>

![Auth0's solution](https://images.ctfassets.net/23aumh6u8s0i/7yX585bQJMurpZkF2cg1Oq/a56b325dc9ce56f4dc5a5847eaf92622/auth0)

With this arrangement, Auth0 behaves as a normal single sign on app. You can then go to any other app or site that uses Auth0 and you will remain logged in if an administrator has enabled that option.

But with just a few lines of code, you can also

* Integrate with virtually any protocol you want to make available to your users: SAML, OpenID Connect, Facebook Connect, Microsoft Active Directory, Twitter, and more.
* Manage user accounts and check out your identity-based analytics right in the Auth0 dashboard.
* Leverage your users' social data to provide a personalized onboarding experience

Auth0 is a true federated identity manager in the sense that it doesn't *just *allow for you to stay signed in across domains. Auth0 also gives you access to the user accounts of everyone on your system, allows you to set specific access restrictions across identity providers, and keep all of this data consistent.

Auth0 can be a clearinghouse for the identities of all your users whether you're running a consumer-facing mobile app or an enterprise system with a SAML-based identity provider. One click is all it takes to turn integrations on and off, and to secure them with Auth0's [full lineup of security features](https://auth0.com/security).

[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/)


Why Federated Identity Management Matters

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" />


"federated-identity"