andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

A deep dive into the differences between Single Sign-On (SSO) and Federated Identity, covering concepts, protocols, and implementation nuances.

In the world of identity management, we tend to play fast and loose with terminology. When discussing with your team the requirements to implement Single Sign-On (SSO) for a new partner portal, the term often evokes two different concepts: a centralized enterprise login page for some, and a social or third-party Identity Provider login (e.g., "Login with Google") for others.

While they both solve the problem of saving the user from remembering dozens of passwords, SSO and Federated Identity are related but subtly distinct concepts. Confusing these two can lead to some pretty awkward conversations with your security team.

In this article, we are going to break down what makes them different and let you understand the nuances for a better conversation and system design.

If you prefer watching a video instead of reading, here it is for you:

<AmpContent>
<amp-youtube
    data-videoid="qCavnUoN37g"
    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/qCavnUoN37g' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

## The Core Concept of Single Sign-On

At its heart, the goal of [Single Sign-On (SSO)](https://auth0.com/docs/authenticate/single-sign-on) is simple: allow a user to authenticate once and gain access to multiple related, yet independent, software applications without being prompted to log in again.

The "magic" usually happens via cookies or tokens. Once you are authenticated with the Identity Provider (IdP), a session is established in your browser. When you navigate to a different application that trusts the same IdP, that application checks with the IdP. Since the IdP sees you already have an active session, it confirms your identity to the application and you are in.

Historically, SSO was often implemented within a single security perimeter, such as a corporate intranet, using one centralized directory or authentication server.

However, what is relevant is that **SSO describes a user experience and authentication capability**, regardless of its implementation. Users don’t care about the technical implementation of the authentication process. They use one set of credentials to access multiple independent applications.

> To learn more about Single Sign-On, you can read [The Developer’s Guide to Single Sign-On](https://auth0.com/resources/whitepapers/auth0-guide-to-single-sign-on-sso?utm_source=auth0_blog&utm_medium=sc&utm_campaign=banner_sso_ebook).

## What Is Federated Identity?

Within a single organization, applications typically rely on a single Identity Provider to manage users and allow them to access multiple applications, thus enabling SSO.

But what if you want to grant access to users external to the organization?

Consider the case of a company that wants to grant access to some internal applications to users from a partner company. The company could create an account in its own IdP for those external users, but this would lead to a few problems:

* it forces external users to memorize a new set of credentials,  
* the company assumes the responsibility for managing these new users, with all the challenges of aligning with the user lifecycle within the partner company.

This last point is very important: what happens if the external user is disabled in the external organization, for example, if a user leaves the partner company?

This is where the concept of Federated Identity comes in.

**Federated Identity** is the architectural framework that **enables SSO across different security domains** or administrative boundaries. It is the mechanism that lets an application establish a technical trust relationship with an external IdP.

## The Architecture of Federated Identity

In a federated setup, the IdP and the application live in different organizations or security domains. There are no shared or duplicate users. Instead, there is a pre-established "circle of trust" based on standardized protocols and cryptographic keys.

But how is this trust established? Who is trusting who? Is the application or the internal IdP that trusts the external IdP?

In a Federated Identity architecture, both scenarios are valid, and the choice depends on where you want to handle the complexity of managing trust relationships. You can have two scenarios:

* **Application Trusts Multiple IdPs**. The application can directly establish trust with multiple Identity Providers (e.g., allowing users to sign in via Google, Facebook, or a corporate Okta instance). In this model, the application maintains configuration for each IdP.  
* **Identity Brokering**. Alternatively, the application can trust a single "Broker" or "Gateway" IdP (often the organization's primary IdP or a service like Auth0). This Broker IdP then establishes trust relationships with external IdPs. The application only manages one connection, while the Broker handles the complexity of federating with various external sources

## Protocol Standards and Handshakes

You cannot talk about SSO and Federated Identity without touching on the protocols that make them work. While some proprietary SSO systems exist, most modern implementations rely on standard protocols, which become much more relevant when you are going to implement Federated Identity.

When you implement SSO within an organization, the trust is often implicit. The app and the authentication server are part of the same entity. You can implement a proprietary protocol or use protocols like [LDAP](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) or [Kerberos](https://en.wikipedia.org/wiki/Kerberos_$protocol$), which are tightly integrated with the local network layer or assume one centralized directory.

In Federated Identity, the trust must be explicit and cryptographic. This is where protocols like SAML and OpenID Connect (OIDC) come into play. You establish a "circle of trust" where the IdP provides a public key or a metadata URL, and the application uses that to verify assertions. You don't need to know the user’s password; you just need to trust the digital signature of the IdP.

[SAML (Security Assertion Markup Language)](https://auth0.com/blog/how-saml-authentication-works/) is the old guard of federation. It is XML-based and very common in enterprise environments. It is great for passing identity information between a corporate IdP and a SaaS application.

[OIDC (OpenID Connect)](https://auth0.com/blog/the-openid-connect-handbook/) is the modern JSON-based layer on top of OAuth 2.0. This is what you see most often in "Login with X" scenarios. It is developer friendly, works great with mobile apps, and is the standard for most modern web architecture.

The interesting part is that these protocols can be used to achieve SSO not only in Federation, but even within a single organization. In other words, you can use OIDC to build an SSO experience for your suite of applications within your company. You can also use OIDC to federate identities from an external partner.

## Where the Lines Get Blurry

We often use Federation Identity to achieve SSO. This is where the confusion usually starts. 

If your company uses Auth0 to log in to Slack, Salesforce, and Jira, that is technically a "Federated SSO" setup. It is “Federated” because your company and Salesforce are different entities using a protocol like SAML to talk. It is “SSO” because the user only logs in once to Auth0 and gets into everything else automatically.

However, you can have SSO without Federation Identity. Think of an old school Kerberos setup on a Windows network. You log in to your workstation, and you are automatically authenticated to the file share and the printer. There is no SAML assertion or OIDC token involved; it is just a shared authentication protocol within a local network.

Conversely, you can have Federation Identity without SSO. Imagine a scenario where you use your GitHub account to sign up for five different developer tools. If each tool requires you to click "Login with GitHub" and re-authorize or re-authenticate every single time you open a new tab, you are using Federated Identity, but the "Single Sign-On" part of the user experience is broken or poorly implemented. However, consider that Federated Identity without SSO could be explicitly implemented for high-security transactions or sensitive resources.

## The Challenge of Global Logout

One of the most practical differences for developers is handling logout.

In a single-organization SSO environment, logging out of the central IdP can often clear the sessions for all connected apps. This is because they all share a common session management strategy.

In a Federated world, [Global Logout](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-idps) is a headache. If you log out of a SaaS app using your Google identity, you are not necessarily logged out of Google. And you certainly aren't logged out of the other three apps you accessed via Google federation. Each application maintains its own session based on the initial assertion. If you need a "kill switch" that ends all sessions everywhere, Federation makes that much harder than a centralized SSO setup.

> Read [this article to learn more about the challenges of logging out](https://auth0.com/blog/the-not-so-easy-art-of-logging-out/).

## SSO vs. Federated Identity: Key Takeaways

SSO is the experience of not having to log in again. Federated Identity is the architecture that allows an identity to be valid in places it does not *live*.

While we often use them together, keeping the concepts separate allows you to have clearer conversations with your stakeholders and possibly better systems. The next time you are architecting a new project, don't just ask for SSO. Ask if you are building a centralized identity system or if you are federating with external authorities. Your choice will dictate your protocol (SAML vs OIDC), your security model, and how much "identity debt" you'll have to manage down the road.

<FAQs>
  <FAQ>
    <FAQQuestion>What's the difference between federated identity and single sign-on?</FAQQuestion>
    <FAQAnswer>While often used interchangeably, they're distinct concepts. Single Sign-On (SSO) is a user experience where you authenticate once and access multiple related applications without logging in again. Federated Identity is the technical architecture that enables SSO across organizational boundaries by establishing trust relationships between applications and external identity providers. You can have SSO without federation (traditional corporate networks) or federation without SSO (requiring re-authentication with external identity providers).</FAQAnswer>
  </FAQ>

  <FAQ>
    <FAQQuestion>Can I implement SSO without using federation?</FAQQuestion>
    <FAQAnswer>Yes. Traditional Kerberos systems on corporate networks are examples of SSO without federation. Also, a web-based intranet can implement SSO without federation. These systems maintain implicit trust between applications on the same network without establishing formal trust relationships with external identity providers. However, this approach doesn't scale well across organizational or security domain boundaries.</FAQAnswer>
  </FAQ>

  <FAQ>
    <FAQQuestion>When do I need federated identity vs. SSO?</FAQQuestion>
    <FAQAnswer>Use federated identity when you need to authenticate users across different organizations, security domains, or when applications need to trust external identity providers. Use traditional SSO for applications within a single organizational domain with implicit trust relationships. Modern SaaS environments typically implement federated SSO, combining both approaches, to allow secure cross-organizational user management.</FAQAnswer>
  </FAQ>

  <FAQ>
    <FAQQuestion>What protocols should I use for federation?</FAQQuestion>
    <FAQAnswer>The choice depends on your use case. SAML (Security Assertion Markup Language) is XML-based and dominates enterprise federation scenarios. OIDC (OpenID Connect) is JSON-based, built on OAuth 2.0, and powers modern "Login with Google/GitHub" implementations and mobile applications. OIDC is increasingly favored for new implementations due to its flexibility and mobile-first design.</FAQAnswer>
  </FAQ>

  <FAQ>
    <FAQQuestion>How does trust work in federated systems?</FAQQuestion>
    <FAQAnswer>Federated systems require explicit, cryptographic trust established through formal protocols like SAML or OIDC. Applications and identity providers exchange metadata, certificates, or other credentials to verify each other's authenticity. This differs from traditional SSO, where applications within an organization often assume implicit trust based on network security.</FAQAnswer>
  </FAQ>

  <FAQ>
    <FAQQuestion>What's the biggest challenge with federated identity?</FAQQuestion>
    <FAQAnswer>Global logout is the most complex problem. In centralized SSO systems, logging out clears all connected sessions. In federated architectures, each application and identity provider maintains independent sessions, making it extremely difficult to coordinate a comprehensive logout across all systems. When a user logs out of one application, they may still have active sessions with other federated services.</FAQAnswer>
  </FAQ>

  <FAQ>
    <FAQQuestion>Can I use both SAML and OIDC for federation?</FAQQuestion>
    <FAQAnswer>Yes, but they serve different purposes within federation. SAML is better suited for enterprise-to-enterprise federation with formal trust relationships. OIDC is better for consumer-facing authentication and mobile scenarios. Many organizations use both protocols depending on the application and user context: SAML for partner integrations and OIDC for end-user applications.</FAQAnswer>
  </FAQ>
</FAQs>

Federated Identity vs. Single Sign-On: Key Differences

eric wu

With over 7 years of experience in product marketing, I am passionate about creating and delivering impactful marketing strategies that drive customer value, business growth, and competitive differentiation. I have a strong background in launching new products, especially in Security, Generative AI and Cloud domains, where I have led several successful end-to-end product releases. I currently work as a Staff Product Marketing Manager at Okta, a leading identity and access management platform that empowers organizations to securely connect their people and technology.

Staff Product Marketing Manager, Auth0

Eric Wu

Self-Service Single Sign-On (SSO) reaches General Availability (GA) status

As Independent Software Vendors (ISVs) quickly learn, in addition to building the core functionality of your software-as-a-service (SaaS) apps, you must also provide features that support your business customers’ administration, integration, and security needs.

One of the most challenging features to implement is Single Sign-On (SSO) due to the many competing standards and protocols available. Plus, merely supporting SSO is only one piece of the puzzle — it also has to get deployed:

* **From the perspective of each of your business customers**, setting up SSO for each and every app they’ve adopted can be a tedious process, often involving lots of back and forth with your customer service reps — and perhaps even your developers
* **For you as an ISV**, helping each and every business customer set up SSO for your app is just as tedious and time-consuming

Both parties benefit from a quick and simple deployment approach, which is why we’re excited to announce that our Self-Service SSO feature has reached General Availability (GA) status.

## SSO Is an Enterprise Imperative

Due to its associated benefits, Single Sign-On (SSO) — an Identity solution that allows multiple applications to use the same authenticated session — is an essential element of modern Identity and Access Management (IAM). SSO is so important, in fact, that it’s a foundational element of [the emerging Interoperability Profile for Secure Identity in the Enterprise (IPSIE) security standard](https://www.okta.com/blog/2024/10/oktane-2024-the-future-of-identity-security/).

On top of providing a convenient user experience, SSO dramatically reduces the number of credentials in use and helps to ensure that security policies are consistently applied across all of an organization’s applications, since the policies can be enforced at an organization’s Identity Provider (IdP).

Now that Identity has emerged as the primary enterprise security entry point, and with [organizations deploying more apps than ever before](https://www.okta.com/businesses-at-work/), SSO is needed more than ever.

### Simplifying SSO configuration saves time, reduces errors, and manages information risk

Self-service SSO refers to a flow that allows your business customers to set up and edit SSO connections themselves.

This capability delivers several valuable benefits, including:

* **Saving time for everyone:** Building Identity solutions isn’t your core business, and any time spent doing so pulls your team from product extension and innovation. With Self-Service SSO, your developers can focus more on your product instead of SSO integrations.
* **Reducing the potential for errors:** Manually configuring SSO introduces the risk of errors that impede productivity and undermine security. Self-Service SSO keeps manual tasks to a bare minimum.
* **Eliminating the need to share sensitive information:** Configuring SSO often requires the ISV and the business customer to share sensitive information (e.g., client IDs, SAML certificates, etc.), but Self-Service SSO eliminates these exchanges.

## How Self-Service SSO Works

Self-Service SSO requires minimal configuration in your Auth0 tenant and provides your customers with a setup assistant that guides them through the enablement process. After a customer completes their setup, the SSO integration is automatically added to your tenant as an [Enterprise connection](https://auth0.com/docs/authenticate/enterprise-connections).

Diving a little more deeply, Self-Service SSO uses three components to delegate setup to your customers:

* **Self-Service profile:** Defines key elements of customer SSO implementations, such as the IdPs they can use for SSO and which user attributes they must capture (e.g., email address)
* **Self-Service access ticket:** Grants customer admins access to the SSO setup assistant and sets specific details for their resulting SSO integration
* **SSO setup assistant:** A Self-Service Wizard that guides customer admins through the SSO setup process — enabling your business customers’ administrators to create, edit, and test SSO connections

You also benefit from additional **observability** features, including new tenant logs to monitor ticket consumption and the creation and enablement of connections; you can monitor logs to promptly initiate any tasks once the connection has been created.

At a high level, the Self-Service SSO workflow includes the following tasks:

1. You (the Auth0 by Okta customer) create a self-service profile in your tenant using the Auth0 Dashboard or the Management API.
2. Next, you use the Management API to create a self-service access ticket that allows customer admins to configure SSO.
3. You retrieve the ticket URL from the asset created in Step 2 and send this link to your customer admin.
4. Your customer admin launches the SSO setup assistant and follows the steps provided to create an application with their identity provider.
5. After the customer completes their setup, the SSO integration is automatically added to your tenant as an [Enterprise connection](https://auth0.com/docs/authenticate/enterprise-connections).

<include src="Vidyard" id="UPTUao1LfxdMLrnD38Gsxc" />

## Getting Started

As enterprises continue to adopt best-of-breed tools, IT and security leaders will increase their focus on access management strategies, like SSO, that can simultaneously support productivity and contribute to a strong security posture.

Whether you include SSO within your base product or offer it as a premium add-on, Self-Service SSO enhances your overall value proposition.

By empowering your customers to configure their own SSO integrations with your app, you can streamline your onboarding process and grant them more autonomy over their sign-on experience — while reducing the time and costs associated with managing SSO across your customer base.

**If you’d like to learn more about this new feature**, we invite you to peruse [the Self-Service Single Sign-On documentation](https://auth0.com/docs/authenticate/enterprise-connections/self-service-SSO).

**Want to launch a B2B SaaS application quickly?** Check out our reference application, [SaaStart,](https://auth0.com/blog/speed-up-your-customer-identity-journey-with-auth0-saastart/), a complete, working example of how to implement SaaS Identity with Auth0, built with the most popular frameworks developers use today. You can gain hands-on experience on Self-Service SSO and other essential CIAM features and quickly deploy a sample Auth0 template directly within the SaaStart [repo](https://github.com/auth0-developer-hub/auth0-b2b-saas-starter) or from [our new integration](https://vercel.com/integrations/auth0) in the Vercel marketplace.


Empower Your Enterprise Customers to Set up Their Own SSO Implementations

amanda-giannelli

Senior Software Engineer

Amanda Giannelli

Simplify logins, boost security, and enhance productivity with the power of Single Sign On!

## Introduction

Are you tired of juggling a bunch of usernames and passwords just to get your work done? You’re not alone. In today’s world, where we use so many different apps and services, keeping track of login details can feel like a full-time job. 

Enter Single Sign On (SSO), a simple yet powerful solution that lets you access all your apps with just one login. Let’s dive into what SSO is and why it’s such a game-changer for businesses.

## What is SSO?

You may have already used SSO without realizing it. Whenever you log into a website that leverages [identity providers](https://auth0.com/docs/authenticate/identity-providers) such as Google, Facebook, or Apple (to name a few), that is single sign-on in action.

SSO is a fancy term for a straightforward concept: log in once, and you’re good to go across all your apps. Whether it’s checking your email, collaborating on a project, or logging into your CRM with SSO, one login gets you everywhere you need to be. It’s like having an all-access pass to everything you need for work.

## How Does SSO Work? 

When SSO is enabled, and you attempt to authenticate to App A, you are sent to the authentication server to provide your credentials. Once authenticated, you are redirected back to App A and signed in. If you then access any other services (for example, another app) connected to the same auth server, you will be immediately authenticated into this application.

![SSO authentication and how it works](https://images.ctfassets.net/23aumh6u8s0i/1rHF8E9UCO7abbWzLRntV0/6856815f4ee9b078d83093d2a21a6bc7/typical-sso.png)

> Read more about [SSO authentication and how it works](https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/). 

## Benefits of SSO

Now that you have a general understanding of what SSO is, let’s take a look at some of the benefits.

### Enhanced User Experience

Remembering a bunch of different passwords is a hassle. With SSO, you only need to remember one password. No more struggling to recall if your password for App A has a special character or if App B requires an uppercase letter. Log in once, and you’re in — it’s that simple.

#### Goodbye, Password Overload

Keeping track of passwords can feel overwhelming. While a password manager is an option, SSO puts an end to needing scores of passwords. By reducing the number of passwords you have to remember, it’s less likely you’ll get locked out or end up using the same password everywhere (which, let’s be honest, [isn’t very safe](https://www.security.org/resources/online-password-strategies/)).

#### Get to Work Faster

SSO saves you time. Instead of typing in different credentials every time you switch apps, SSO gives you instant access. It’s like walking through an open door instead of fumbling for keys — you get to work faster and with less hassle.

SSO providers also typically provide a dashboard with all of the apps you have access to. Open the dashboard, select your app, and you’re in. 

### Boost Security

You might think that having one login for everything sounds risky, but SSO actually makes your business more secure. Here’s how:

#### One Secure Login Point

With SSO, all your logins are managed in one place. This means your IT team can keep a close eye on things and quickly respond if something looks suspicious. It’s like having all your valuables in one safe instead of scattered around the house.

#### Reduced Chance of Phishing 

[Phishing scams](https://auth0.com/blog/protecting-against-phishing-attacks/) — fake emails trying to steal your info — are a big problem. But with SSO, you’re not entering your password over and over, so you’re less likely to fall for a phishing trap. Fewer logins mean fewer chances for scammers to trick you.

#### Add Extra Security with MFA

Most SSO solutions let you add [Multi-Factor Authentication](https://auth0.com/docs/secure/multi-factor-authentication) (MFA), which provides another layer of security by requiring more than just a password to log in. Maybe you’ll need to enter a code sent to your phone or scan your fingerprint. This extra step makes it much harder for hackers to get in, even if they have your password.

### Lighten the Load on Your IT Team

SSO isn’t just great for users. It's also a lifesaver for your IT department. Managing user accounts and passwords can be a real headache, but SSO makes it a breeze.

#### Easier User Management

With SSO, your IT team can manage who has access to what from a single dashboard. Need to give new employees access to all the tools they need? Done in a few clicks. Need to remove access when someone leaves? Just as easy. It’s all centralized, which saves time and reduces errors.

#### Fewer Helpdesk Calls

Did you know that [up to 50% of helpdesk calls](https://agio.com/your-employees-are-wasting-30-of-their-time-resetting-passwords/) are for password resets? SSO cuts down on the need to [reset your password](https://auth0.com/learn/password-reset), freeing up your IT team to focus on bigger issues and your employees to work on what truly matters. Less time resetting passwords means more time to solve real problems.

#### Smooth Compliance and Reporting

If your business is in a regulated industry (such as finance or healthcare), SSO can make compliance a lot easier. It keeps detailed logs of who accessed what and when, so when it’s time for an audit, you’ve got everything you need at your fingertips.

### Scale Up with Ease

As your business grows, so do your tech needs. The good news? SSO grows with you. Whether you’re adding new apps or expanding your team, SSO makes it easy to scale up.

#### Integrates with What You Already Have

SSO solutions are designed to work with the tools you’re already using, whether they’re in the cloud, on your servers, or a mix of both. So, no need to overhaul your entire system — just plug SSO in and keep moving forward.

#### Works Across All Environments

Many businesses today use a mix of on-premises and cloud-based applications. SSO bridges the gap, providing a seamless login experience across all platforms. So, as you move more of your operations to the cloud, SSO keeps everything running smoothly.

#### Future-Proof Your Business

By implementing SSO, you’re setting your business up for success as you grow. No matter how many new apps or services you add, SSO will be there to keep everything secure and accessible, ensuring your team can stay productive without getting bogged down by tech hurdles.

### Better Collaboration with Partners

If your business works with external partners or clients, SSO can make those relationships smoother and more secure. Here’s how:

#### Secure Partner Access

SSO lets you extend secure access to your partners without compromising your internal security. You control who sees what, so everyone has the access they need — and nothing more.

#### Easier Collaboration

When your partners can log in easily without juggling multiple credentials, it’s easier to work together. Whether you’re sharing documents or managing a project, SSO makes collaboration a breeze.

### Challenges

For all of its amazing benefits, SSO is not without its challenges. Understanding these considerations can help you plan effectively and ensure that your SSO implementation is successful. Here are a few to keep in mind:

#### Single Point of Failure

SSO centralizes authentication, so if the SSO system goes down, users may lose access to all connected applications. This is why high availability coupled with redundancy for your SSO solution is critical to reduce downtime. High availability means the system is always on and available no matter what happens. Redundancy enables high availability by acting as a backup plan in the event of failure to ensure the services remain functional. 

#### Setup and Integration

Integrating SSO into existing applications can be complex and time consuming, especially when dealing with a mix of legacy and new systems. Careful planning and coordination between IT teams and application owners is crucial to ensure a smooth implementation.

#### Security Risks

While SSO can enhance security, it can pose a risk if not properly managed. If an attacker gains access to a user’s SSO credentials, they could potentially access multiple applications. Implementing strong authentication methods, such as MFA, is essential to mitigate this risk. 

#### User Adoption and Training

Users need to be educated on how SSO works and the importance of keeping their credentials secure. Without proper training, there may be confusion or resistance — especially in less tech-savvy organizations. 

## Conclusion

SSO isn’t just a buzzword. It’s a powerful tool that can make your business more efficient, secure, and scalable. By simplifying the login process, reducing security risks, and lightening the load on your IT team, SSO can help your business thrive in today’s fast-paced digital world.

If you’re not using SSO yet, now’s the perfect time to start. Whether you’re a small business looking to grow or an established company ready to streamline operations, SSO can give you the boost you need to stay ahead of the curve.

Benefits of Single Sign-On (SSO)

bonfida

Establishing your identity in a permissionless and censorship-resistant way using Solana. We give the power back to our users

Bonfida.sol

What about a single username for all the dapps that you have to sign up for? No passwords, no emails, just your SNS domain. One that is uniquely yours across Web3.

It’s no secret that an average internet user makes use of an array of emails, passwords, and username combinations spread across different apps to ensure logins. A process that prevails to be a logistical effort.

Today, however, we’re changing the game for Solana developers, their dapps, and users - to make the Solana “login” experience(s) a dream.

We present to you a tooling built by Bonfida and Auth0: **Sign-in with SNS** (SIWSNS). SIWSNS is a new authentication method for .sol domain name holders. A method that allows a domain holder to live interoperably, control their digital identity and build Web3 profiles under a single name across every dapp they interact with.

Following a few simple steps, developers are able to harness the power of Web3 domains and automatically populate the identities of users interacting with their projects. One that is secured by the technology of public-private keys and guarantees consistent identities across the space. Besides the security of this method, we are accelerating the onboarding process for users and enabling already existing personalities to nest themselves in the new projects they delve into. Carrying over their potential following.

This makes for a much simpler experience - where practically no information is required. Ultimately reducing the barriers to entry and stimulating a better and more convenient Web3 experience.

[View the Marketplace page for SIWSNS for developers.](https://auth0.github.io/marketplace-integrations/#/marketplace-integrations/preview/889/details/siwsns)

## A Better Experience for Solana Users

Domain names are unique. This means only one `[king.sol](https://king.sol/>)` and only one `queen.sol` can exist in our space. No, you don’t have to worry about signing into a dapp and not being able to use the same username you have on another.

Sign in with the Solana Name Service Powered by Auth0

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](https://auth0.com/docs/authenticate/single-sign-on). 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?

diegopoza

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

Sr Manager, Developer Advocacy

Diego Poza

How Single Sign-on (SSO) streamlines authentication and what makes for a good SSO solution.



Everyone who uses the internet agrees that life would be better with fewer logins. For users, logging in is a hassle that interrupts whatever they were trying to do and forces them to remember their password. What's bad for user experience is doubly bad for businesses, because a frustrated user is more likely to walk away from a transaction or browse a website without logging in.

The solution for a world with fewer logins is single sign-on (SSO), which allows a user to log in once and automatically gain access to a suite of connected applications. Companies that implement single sign-on properly benefit from improved user experience and heightened security. Below, we'll explain how single sign-on works and the differences between a good SSO policy and a bad one.

## What Is Single Sign-On?

Single sign-on is a method of logging in that lets a user enter in their login credentials (usually a username and password) just once and automatically be logged into multiple websites or applications. Single sign-on is one element of identity and access management (IAM), which is the entire set of tools and protocols governing how users log in and gain access to data.

An SSO solution is like a library card. A library card lets you check out books from every branch in a library system instead of having to get a separate card and a separate account for each one. This makes life easier for patrons, who can now access books from all of the local branches instead of just one. And it makes things easier for the organization because they know how people are using their services (and who owes late fees). SSO operates according to the same principle, except instead of uniting the different library branches in a city, it unites different digital properties used by a single company.

![Single Sign-On](https://images.ctfassets.net/23aumh6u8s0i/K75jZ7ram6DqcgeRpdk5E/b63faf3f58df73ff601059244656a438/single-sign-on-info)

The most widely known customer-facing example of single sign-on is Google's G Suite. Users log in to their Gmail accounts, and when they navigate to Google Docs or YouTube, they're automatically logged in. While end-user authentication is the most widely known use case for SSO, its also used in business-to-employee (B2E) settings.

Some companies also use SSO for their employees, so a single set of credentials grants access to a set of applications. For instance, if an employee logs into their employee portal, they'll be immediately logged into Slack and Zoom with their employee ID.

SSO is a part of the broader concept of [federated identity management](https://auth0.com/blog/why-identity-federation-matters/), which allows for someone to use a single identity across multiple different systems. SSO refers specifically to a single login giving a user access to multiple properties that are still part of a single organization.

Federated identity, meanwhile, means using the same identity to log in to properties owned by multiple organizations. It's possible to have a federated identity that isn't a single sign-on. For instance, an app could enable social login (logging in with something like Facebook, Google, or Apple ID) but still only use that login for a single property.

## How Does Single Sign-on Work?

On a technical level, SSO works by having users give their credentials to the SSO solution instead of logging in directly to a website or app. The SSO solution, in turn, checks these user credentials with the company's authentication server (a database of credentials) or identity provider.

An identity provider is a service that stores and manages user identities on behalf of an application. For end users, common identity providers include Google and Facebook. [Enterprise identity providers](https://auth0.com/docs/connections/identity-providers-enterprise) include Microsoft Active Directory, Azure AD, LDAP, and G Suite. Users can log in using an account they've already created with a separate identity provider, which saves them from filling out a new registration form. Using an outside identity provider saves businesses from having to store this information themselves on an authentication server. That's a security advantage for businesses because having databases full of passwords can make them targets for hackers.

When the SSO solution confirms that a user is logging in with the correct credentials, it issues them a token. Then, when they go to a new page, the token confirms that they're already logged in and don't need to do so again. There are multiple ways this interaction can take place using Security Assertion Markup Language (SAML) or Open Authorization (OAuth). For our non-developer purposes, the primary difference between these two is that SAML is used to verify a user's identity (authentication), whereas OAuth controls what resources users are allowed to access (authorization).

Most SSO solutions also include single log-out (SLO), which means that logging out of one site automatically logs you out of the rest.

## Single Sign-on Challenges and Benefits

The right SSO solution can create more streamlined user experiences, improve analytics, and increase security. Despite this, SSO adoption has been relatively low, even among businesses that use other cloud-based identity solutions. According to a [2019 Bitglass report](https://www.businesswire.com/news/home/20191105005310/en/Bitglass-2019-Cloud-Adoption-Report-Enterprise-Cloud), 86% of companies currently use cloud applications, but only 34% use single sign-on (SSO).

This slow adoption rate is due to security concerns and the technical challenges of implementing SSO in-house. Each of these issues deserves attention, but there are solutions for each.

### SSO security risks and solutions

With SSO, a user's login credentials act like a skeleton key that unlocks multiple applications. Unfortunately, the more doors a password opens, the more damage a hacker can do with it. That danger is greater for users who reuse their passwords. One of the biggest cybersecurity risks in recent years is [credential stuffing](https://auth0.com/blog/what-is-credential-stuffing/), in which hackers use credentials stolen in one data breach to hack into other sites. It's an effective tactic, precisely because many people use the same passwords for everything.

On the other hand, SSO can actually reduce the chance of compromised credentials because it reduces "password fatigue." The fewer passwords people have to create, the less likely they are to reuse old ones.

Still, the best way to ensure that SSO doesn't hurt security is to combine it with strong authentication protocols like [multifactor authentication (MFA)](https://auth0.com/learn/multifactor-authentication-customers/). MFA, also known as two-factor authentication (2FA), asks users to give additional credentials that prove who they are in the event of a suspicious login or which engaging in risky behaviors (such as accessing payment information).

Companies don't want to use MFA for every login: doing so will create too much friction for customers, so they need a customizable approach. Contextual MFA lets companies determine the situations in which to ask for more credentials. For instance, if a user is logging in on a new device, an MFA solution may ask them to confirm their identity. That may mean sending a verification code to their phone or email or using biometrics, such as a fingerprint.

![MFA](https://images.ctfassets.net/23aumh6u8s0i/iicHPmWM3HmnyEc2MPHBJ/3844cce0e03ebe9cd30b2f095f06d11a/manage-mfa-ss-43963efc4c)

The other critical element in keeping SSO safe is controlling session length (how long users stay logged in) based on risk. For example, a banking app might automatically log out users after a few minutes of inactivity. A video-streaming site, on the other hand, doesn't need to be so strict about access control and can allow for sessions that last for weeks before they ask users to verify their identities again.

### SSO implementation challenges and solutions

When companies try to design their own SSO solutions in-house, they run into some common and potentially expensive problems. For one thing, integrating identity across different types of directories is a challenge, especially for companies using legacy applications. Getting these applications to communicate is akin to trying to connect LEGO blocks with Lincoln Logs. Likewise, it's challenging to design an SSO solution that's compatible with different devices and operating systems, such as Android and IoS products.

Then there's the issue of user migration. Let's return to our library analogy and imagine that, until recently, all the local libraries kept their own databases of users, and now they're trying to combine them. This creates problems because some people have accounts at every branch and possibly have different information on file with each one. Migrating all that data into a single source of truth and correcting it as you go can be a huge headache.

That's why it's simpler and often more cost-effective for companies to use a third-party SSO solution instead of building one from scratch. With an outside SSO provider, integrations have already been solved, migration is simplified, and SSO can simply be plugged in and switched on.

![SSO Solution](https://images.ctfassets.net/23aumh6u8s0i/6MDhnlpJSVSBaFHs7Cpb2J/40794b467fc8ce1c707dd241497587f4/sso-integrations)

While some companies offer SSO as a stand-alone solution, it's usually part of a suite of services offered by an identity-as-a-service (IdaaS) company. The advantage of using an IDaaS provider for IAM is that it includes the tools you need to use SSO safely, like customizable MFA. Whether you're looking to implement SSO for your end users or your employees, the right IAM solution is the one that includes the integrations and customizability you need.

## The Right SSO Solution Helps Everybody

When an SSO solution has the right security safeguards, it can streamline the authentication process and lead to fewer headaches for all parties. People aren't overwhelmed by a ballooning number of user accounts, and businesses get fewer help-desk calls for lost passwords. It all depends on finding an SSO provider that handles a user's identity securely and efficiently.

<include src="asides/AboutAuth0" />


What Is Single Sign-On (A Non-developer's Guide)

auziros:mckenzie-mayer

Customer Identity (CIAM) Product Comms lead, driving collective storytelling across Okta and Auth0. Making technology accessible for everyone.

Customer Identity Product Comms Lead at Okta

McKenzie Mayer

The Israeli stock exchange integrates Auth0 for single-sign on and advanced security on its path to digital transformation and data accessibility



**TEL AVIV, Israel &mdash; August 3, 2020 &mdash;** [Auth0](https://auth0.com/), the identity platform for development teams, and its partner [MalamTeam](https://www.malamteam.com/), Israel’s largest local systems integrator, today announced they have been selected by The [Tel Aviv Stock Exchange (TASE)](https://www.tase.co.il/en) to provide secure single sign-on for all of its customer-facing applications. For the first time, users will be able to access TASE’s main website, ‘MAYA’ corporate website, mobile app, and many other digital services using a single set of credentials, with advanced security features to protect against cyber attacks.

The Tel Aviv Stock Exchange plays a major role in the growth and development of the Israeli economy. Building on the launch of an [English version of its MAYA website](https://www.prnewswire.com/news-releases/the-tel-aviv-stock-exchange-tases-maya-website-is-now-available-in-english-301084923.html) to make information more accessible to foreign investors, TASE wanted to provide a world-class login experience with a simple and secure customer identity and access management (CIAM) solution. They chose Auth0 for its security and [extensibility](https://auth0.com/blog/new-whitepaper-the-tao-of-extensibility/) &mdash; the ability to easily customize and add features like social login over time &mdash; and MalamTeam for its expertise as a local delivery partner.

Previously, each TASE application required a unique username and password. With the help of Auth0 and MalamTeam, TASE [standardized its identity management](https://auth0.com/resources/whitepapers/power-standardized-identity) and will offer SSO for customers across all of its current and future applications, including:

* TASE main website: [https://tase.co.il/](https://tase.co.il/)
* TASE info website: [https://info.tase.co.il/](https://info.tase.co.il/)
* MAYA corporate website: [https://maya.tase.co.il/](https://maya.tase.co.il/)
* TASE Open API website: [https://openapi.tase.co.il/tase/prod](https://openapi.tase.co.il/tase/prod)
* Mobile App - The Securities Exchange
* Document system for e-signatures

“The authentication solution from Auth0 represents a milestone for TASE that will allow us to better serve our customers and the Israeli business community. We no longer have to reinvent identity for every application, and that makes us more efficient and accessible as well,” said Uri Shavit, EVP, TASE CIO. “Our customers expect information at their fingertips, and this is the first time we’re enabling users to access all TASE applications with a single click. The flexibility of Auth0 means we can also customize the solution as our needs change.”

“We are grateful to Auth0 and MalamTeam for their support of our vision to make our data and information more accessible to investors and the fintech community,” added Assaf Kabakov, TASE project manager.

Auth0 also enables TASE to offer customers advanced security features like [Anomaly Detection](https://auth0.com/docs/anomaly-detection) and Multi-factor Authentication (MFA) for blocking attacks and detecting stolen credentials. Customers who already have an account with TASE will be migrated seamlessly to the Auth0 platform without needing to reset their username or password.

“The login experience is often a customer’s first interaction with a brand, and they expect it to be both convenient and secure,” said Bill Lapcevic, VP of business development at Auth0. “TASE is proving that security and customer experience are not mutually exclusive. We’re pleased to work with our partner MalamTeam to let the good users in, and keep the bad actors out of TASE applications.”

[Auth0 and MalamTeam](https://auth0.com/blog/auth0-expands-to-israel-with-malam-team-partnership/) signed a strategic partnership in Israel earlier this year. The two companies are committed to providing modern, componentized identity management solutions for Israel’s innovation ecosystem.

“With Auth0 and MalamTeam, Israeli companies have an opportunity to strengthen their user security and achieve great value for their organization,” said Amir Mesulam, CTO at Team Software, MalamTeam's software innovation division. “Auth0 provides TASE a single platform for all their authentication needs, internal and external, while enabling them to maintain robust security and advanced, yet simple control of their authentication flows.” 

## About MalamTeam
MalamTeam, the largest and the leading IT services group in Israel, provides a comprehensive range of computer services in the field of information technology. It is known for maintaining quality standards, customer service, and professionalism at an international level. The group combines innovation and decades of experience in setting up, implementing and integrating information systems. Its more than 3400 experts in a variety of information technologies are deployed throughout Israel at the facilities of the company and its customers. MalamTeam offers distinctive integrated solutions for all types of hardware, software, database and communications platforms; each of its business units specializes in a distinctive area.

<include src="asides/AboutAuth0" />

### Media Contacts
Mark Fowler <br />
Racepoint Global for Auth0, EMEA <br />
[auth0@racepointglobal.com](mailto:auth0@racepointglobal.com) <br />
+44 (0) 77 1124 4113 <br />


Auth0 and MalamTeam Secure Access to The Tel Aviv Stock Exchange Apps

bruno-krebs

I am passionate about developing highly scalable, resilient applications. I love everything from the database, to microservices (Kubernetes, Docker, etc), to the frontend. I find amazing to think about how all pieces work together to provide a fast and pleasurable experience to end users, mainly because they have no clue how complex that "simple" app is.

R&D Content Architect

Bruno Krebs

Learn how a B2C Company implemented Single Sign-On to provide seamless integration between different e-commerce portals.

Implementing Single Sign-On in B2C Applications

A potential programming mistake raises unexpected privacy concerns among users



[Pokémon](https://en.wikipedia.org/wiki/Pok%C3%A9mon) has been a subject of passion for grown-ups and youngsters alike for a long time. The newly released Pokémon GO app is no exception: it has been installed by thousands since its release a few days ago. What they don't know is that they have given [Niantic](https://www.nianticlabs.com/), the developer, full access to their Google accounts!  

<include src="TweetQuote" quoteText="Pokémon GO has been installed by thousands and the developer has full access to their Google accounts!"/>

**Update:** Ari Rubinstein from Slack has [dived deeper](https://gist.github.com/arirubinstein/fd5453537436a8757266f908c3e41538) and performed an analysis of what can be done with tokens obtained using this authentication flow. It appears additional steps must be performed to obtain a full access token. These steps *are* possible for Pokemon GO, as it is granted access to the necessary APIs, though the app does not appear to be using them. This issue may be attributed to programming mistakes and a permissive API on the part of Google. Both Google and Niantic are looking into the issue and attempting to provide a fix as soon as possible.      

**Update 2:** Niantic has released an [official statement](https://support.pokemongo.nianticlabs.com/hc/en-us/articles/222648408-Permissions-update) regarding the Pokemon Go iOS permissions problem. And also, the app has been updated in the [App Store](https://itunes.apple.com/us/app/pokemon-go/id1094591345?mt=8) with the correct permission scopes. 

-----

## A Pokémon fan's dream game
Pokémon GO, available in [Apple's App Store](https://itunes.apple.com/us/app/pokemon-go/id1094591345?mt=8) and [Google's Play Store](https://play.google.com/store/apps/details?id=com.nianticlabs.pokemongo&hl=en), is an augmented-reality game that lets users be part of a world full of Pokémon ready to be caught. Using the phone's camera and GPS, Pokémon are distributed in the user's vicinity. Hints are displayed to give the user a notion of where to find Pokémon.
To give you an idea of what this means for your average Pokémon fan: it's wild. We've already heard stories of people going into bars just to catch Pokémon (no drinking involved (!)), others [finding corpses](http://arstechnica.com/gaming/2016/07/gamer-stumbles-onto-dead-body-while-testing-pokemon-gos-gps-fueled-features/). This is pretty much every Pokémon fan's dream game: a game that fuzzes the boundaries between fantasy and reality and lets users be part of an ever changing semi-real world full of Pokémon.

No wonder the explosion in social media. And among the many eyes looking at Pokémon GO [some](http://adamreeve.tumblr.com/post/147120922009/pokemon-go-is-a-huge-security-risk) were keen enough to notice users were giving full access to their Google accounts!

![All access in Google account](https://images.ctfassets.net/23aumh6u8s0i/18NnCNuefCyzRMLyS8EDYl/35b993c7d31ec4a45b128d6c31fa3a6a/allaccess)

## How this happened: Single-Sign-On 
We've written a lot about [single-sign-on](https://auth0.com/blog/2015/09/23/what-is-and-how-does-single-sign-on-work/) in the past. It's great, and it helps [businesses grow](http://www.appcues.com/blog/single-sign-on-the-one-click-growth-hack-youre-not-using/). Security is hard, though, and this is no exception. Most single sign on solutions sport a flow similar to the following:

1. An application, on behalf of a user, requests to login through a login provider.
2. The application redirects the user to the login provider's login screen.
3. The login provider authenticates the user and then proceeds to create an authentication/authorization token for the application to use.
4. The token is passed to the application, which can use the token on behalf of the user to perform certain operations with his/her account.

If the application has never operated on behalf of the user with that login provider, an additional step is inserted between step 3 and 4. This step is crucial and defines **what access the application will have to the user data in the login provider's system**. It is this step that is not working right in Pokémon GO.

![Have you ever seen this screen?](https://images.ctfassets.net/23aumh6u8s0i/6fDxO1JfL3WeHnivkKK4S4/6caebe064f53c55a31f147b83f36e44e/permissions)

For some reason this screen is not showing and the app is still getting full-access to Google accounts.

This means **emails (reading and sending), Google Drive documents, your browsing history, your photos, your maps and locations** are *all* available to Niantic. As far as we know, the Android version does not exhibit the same issue (unless you log in with an account previously used on an iOS device for Pokémon GO), so it was probably not the developer's intention to do this. In other words, this is probably a bug or a simple coding mistake.

Until this issue is resolved, our advice is to simply revoke the application's permissions to your Google account by going to the [connected apps page](https://security.google.com/settings/security/permissions).

**Update:** now we know why this screen is not being displayed. Read the excellent [analysis](https://gist.github.com/arirubinstein/fd5453537436a8757266f908c3e41538) by Ari Rubinstein and then take a look at [what is necessary](https://duo.com/blog/beyond-the-vulnerabilities-of-the-application-specific-password-exploiting-google-chrome-s-oauth2-tokens) to get a full access token from the one obtained by Pokémon GO. Although possible, there is no reason to believe Pokémon GO is exploting this.

## Let the experts do the hard work
Authentication and authorization are hard. Even when using the [excellent documentation provided by Google](https://developers.google.com/identity/sign-in/ios/sign-in) for their single-sign-on solution, bugs and mistakes happen. And when you are growing as fast as Pokémon GO, mistakes can be costly.

Our single-sign-on solution gives applications only minimal access to account details by default. Google, Facebook, Twitter and many other login providers are all supported and available under one click. Using a simple, safe-by-default solution can make all the difference between a costly mistake and smooth sailing. <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Try Auth0 now</a> and focus on your app, not logins.

These are our default permissions for Google sign-in: 

![Auth0 default Google permissions](https://images.ctfassets.net/23aumh6u8s0i/4PCBGqxkULDuVzTZViQCgr/3e2d55768158bfb7029e06b22006586a/auth0-perms-2)



Gotta Catch'em All: Pokémon GO Catches All Your Data!

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

Use single sign-on, polish your listing, do internationalization, and deepen your integration to grow your app acquisition through marketplaces


In 5 short years, Pipedrive has grown from a small group of 5 co-founders to a global CRM software company with over [100 employees](http://blog.pipedrive.com/2015/09/5-years-100-people-and-lessons-learned/) and millions upon millions in annual revenue.

But like the rest of us, they started at 0.

When they launched in 2010, they had a product that their friends and family found useful, but they had no marketing plan. They reached out manually to people on Twitter to acquire one or two customers here and there, but they didn’t have any real sustainable and scalable way to get more.

What ultimately propelled them from 0 to 10,000 paying customers came as a total surprise. In 2011, when their growth exploded, a whopping 33% of new customers came directly from a totally unexpected source—the [Chrome Web Store](http://purde.net/2014/12/how-to-get-from-0-to-10000-paying-customers-in-saas/).

When you think [B2B SaaS customer acquisition](https://resources.auth0.com/unlock-b2b-saas-growth-iam/), you often think content marketing, advertising or direct sales. But it turns out that one of the cheapest, most powerful forms of customer acquisition are B2B app marketplaces.

## B2B App Marketplace Landscape

We’re all familiar with the Apple App Store and Google Play for consumer apps, but barely anyone seems to know about B2B app marketplaces like Chrome Web Store, Salesforce AppExchange, and Google Apps Marketplace.

Like on the consumer side, powerful platforms have emerged on the B2B side that give app developers access to millions of potential customers. That means the potential for massive, scalable growth where you’re getting customers nearly for free.

### Chrome web store

The Chrome Web Store contains every type of app imaginable, from B2B to games to Chrome browser themes. An app in the Chrome Web Store can mean as little as a bookmark to a website to what feels like a native app on the desktop.

The Chrome Web Store has grown in importance—especially for business—due to the incredible and continuing success of the Chrome browser and the Chromebook laptop.

1. Google Chrome the web browser is dominating with consumers—with a 25%+ market share and growing fast—and it’s also surpassing Microsoft Internet Explorer among businesses, too. According to Gartner, by 2016, [66% of enterprise users](http://www.computerworld.com/article/2932672/web-browsers/ie-loses-stranglehold-on-the-enterprise-as-chrome-makes-major-inroads.html) will be running Chrome.
2. Chromebooks are the fastest growing B2B laptop segment with [43% growth](http://www.zdnet.com/article/npd-chromebooks-outsell-windows-laptops/) during the first half of 2015. Chromebooks are laptops that only run the Chrome browser, so the only apps available to Chromebook users come from the Chrome Store.

Finally, Chrome is included as the default browser on all Android devices, and Android is taking market share away from iOS in the enterprise. That boosts the Chrome ecosystem for those who want a consistent experience across all their devices.

All of that adds up to massive opportunity for B2B SaaS developers to reach business customers via the Chrome Web Store.

### Salesforce AppExchange

Salesforce founder and CEO Marc Benioff first coined and trademarked the term “App Store,” before [gifting it to Steve Jobs](http://appleinsider.com/articles/11/08/26/salesforce_chief_gave_steve_jobs_app_store_trademark_as_token_of_appreciation) as a thank you for Jobs’s years of personal support. The AppExchange has been around since 2006 and it’s the earliest B2B cloud app marketplace.

The AppExchange doesn’t consist of only sales-related apps, although that’s its expertise. Just as Salesforce has expanded beyond pure CRM, so has the AppExchange, with apps ranging from project management to customer service to HR and more.

[71% of Salesforce](https://medium.com/@salesforce/power-of-the-platform-salesforce-appexchange-hits-3-million-installs-5168928ce94e) customers use apps, and app usage is growing: it took 6 years to get 1 million app installs, 2 years to break 2 million, and just 18 months to get to 3 million. What’s amazing about this number is that a single app install means that the app potentially gets deployed to hundreds or even thousands of employees inside of the company.

Entire businesses have been built on top of Salesforce using the AppExchange for distribution. ServiceMax, which just raised another $82 million in funding—helps companies service and maintain the equipment—and it has grown a huge business focused entirely on its partnership with Salesforce.

### Google Apps Marketplace

Like with AppExchange, the power of the Google Apps Marketplace is that a single install there can mean that the app is deployed to every person in the entire organization.

Google Apps is a suite of productivity tools that you need for work. It features email but it also includes online storage, calendars, collaboration, and more. Because Google Apps is based around email—which everyone in the company needs—it can easily become the central place in your company where you manage each employee’s identity and their access to the different tools they use.

That makes the Apps Marketplace the obvious place to install and deploy apps to the organization. According to a recent study, [33% of Google Apps administrators](http://www.appneta.com/blog/the-market-is-migrating-to-google-apps/) said that the existence of an app within the Google Apps Marketplace helped encourage its adoption by the whole business.

Among small businesses, the Google Apps suite of tools is #1 and owns [22.8% of the market](http://www.winbeta.org/news/office-365-overtakes-google-apps-in-business-market-triples-share-in-a-year). That makes the Apps Marketplace a really attractive place to acquire business customers.

<include src="TweetQuote" quoteText="Among small businesses, the Google Apps suite of tools is #1 and owns 22.8% of the market"/>

### And More

There are numerous other places where apps connect their customers to third party developers. These range from formal-style app stores with ratings, reviews and transactions—like the Shopify App Store—to a more informal listing of integrations—like the Yammer App Directory.

* [Microsoft Office Store](https://store.office.com/)
* [Shopify App Store](https://apps.shopify.com/)
* [Box App Store](https://app.box.com/apps/)
* [Yammer App Directory](https://developer.yammer.com/docs/yammer-partners)
* [Evernote App Center](https://appcenter.evernote.com/)

These smaller app stores usually focus around the specialty of the provider. If you’re building for e-commerce, you’re going to want to get into the Shopify App Store, and you probably won’t be interested in the Box App Store.

Don’t overlook them, though. These platforms are still huge and they can have a big impact of your business. If you narrow in and really nail the use case, you can rise to the top of the app store and thrive. For example, e-commerce receipt SaaS service [Receiptful](http://receiptful.com/) has grown from nothing to sending over 500,000+ receipts every month with the [Shopify App Store](https://apps.shopify.com/receiptful) as its primary source of customer acquisition.

## How to Succeed in the App Store

First, you just need to get into these B2B app stores. Then, you need to experiment to get your app discovered and find success.

The requirements of getting into an app store can range widely.

For example, Chrome apps take 3 forms:

1. Hosted Apps: a hosted app is a wrapper for a website  that can be as basic as just a bookmark.
2. Packaged Apps: a packaged app feels like a native desktop app.
3. Extensions: an extension extends the functionality of Chrome and the websites being viewed in it.

With the most basic hosted app, you only need to create a manifest, add a few images, write your ad copy, and you’ll have a listing in the Chrome Store in less than 30 minutes. On the other end of the spectrum, creating a packaged app or an extension can take months.

Each app store has a different set of requirements and approaches to finding success, but they can be abstracted into the following principles.

### Get into the app store with single sign-on

Often, the most basic requirement to get into the app store is to have single sign-on for the app store provider.

* It makes account management easy for the customer so that your app doesn't feel like yet another tool that has its own separate login credentials.
* It provides continuity between app experiences by authorizing access to user information to can be used to tailor the app experience.

For example, having Google login a pre-requisite to getting into the Google Apps Marketplace.

Even if, as with the Chrome Store, you aren’t required to integrate with Google login, putting up a listing without it available can be a recipe for negative reviews.

![Bad Chrome Comment](https://images.ctfassets.net/23aumh6u8s0i/56lUgBRnqSWwTzLSOMZolI/1b5afe376579b1f77674c3d9908ffa95/chrome-rating)

Single sign-on is the most basic integration possible, and it becomes something that users expect. If it’s not available, users will potentially revolt and tank your listing’s rating.

Setting the login up for one provider can be a huge pain—much less doing it for multiple ones—as you’ll have to deal with the peculiarities of the company’s login API and grapple with its documentation.

With <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Auth0</a>, all you need to do is flip a switch to activate a number of integrations.

![Auth0 Social connections](https://images.ctfassets.net/23aumh6u8s0i/1scqOByj04c3rmHQh1OwUI/48254e4f7418eac5ac9b006d1e3859fa/auth0-social)

### Polish your listing

Your app store listing consists of a few main components. Optimize these, and you’ll dramatically improve your chances of having your app discovered among the vast number of apps in the app store.

* Text
* Images and Video
* Ratings and Reviews
* Download Count

**Text**: You want to think of this the same way you think about SEO: What keywords do I want to rank for and how do I optimize for those keywords?

Put your most important keywords in your listing’s title and make sure they appear with some frequency in your listing body. However, don’t over-stuff your keywords as it will look spammy and lower your conversion rate from view to download as a result.

**Images and Video**: Don’t just include any images in any order—tell a story with your images. This is incredibly important because most people won’t read the text of your product description, so they rely on the images and screenshots to understand your product.

Wherever possible, use video, because it’s even more powerful than images in conveying what the product is for and the emotion behind your brand.

For your images, put your main screen that captures what your product does as your first image. Then, include the following images in a narrative order with short copy on each that explains the screen. This will help get your product from a view to a download.

**Ratings and Reviews**: A high rating and a good volume of positive reviews will increase your search ranking and make it more likely that will people download upon discovery.

Seed a solid score with ratings and reviews from your most loyal customers, your team, and your friends and family. That will  secure you decent initial placement and your first few downloads.

![Review screen](https://images.ctfassets.net/23aumh6u8s0i/1z9421reCAHo11xn9rngLW/b3fd77cf2f33b438292db6ff5a20fb7f/profile)

Create a positive feedback loop for continual ranking improvement by doing the following:

1. Segment your users by identity provider or referrer. You want to pull those customers who found your app via the relevant app store.
2. Create a sub-segment of those users who are likely to give your app a favorable review by looking to see if they’re active with the app. For example, you could pull those users whose latest login was fewer than 3 days ago.
3. Send those users an email asking them to review you in the app store. You can do this by hand early on. Use [Auth0 with Customer.io](https://auth0.com/blog/2015/09/11/7-ways-to-2x-your-revenue-growth-by-putting-your-user-data-to-work/)  to make this a systematic email that goes out once you’ve seen that this process works.

**Download Count**: The more downloads your app has, the more it will get. This is the factor of app store discovery that you have the least control over. However, if you iterate on the principles outlined above, you could find yourself with ever-increasing download numbers, and that means even more downloads.

### Grow through internationalization

App stores are typically region-specific. You’re able to adapt your listing to fit the local language which makes it easier for customers to buy.

The Chrome Store for Brazil, for instance, is in Portuguese, while the Chrome Store for France is in French. If your app is English-only, your app will appear in the Brazilian Chrome Store, but you’ll get outranked by apps that have been localized for Brazil.

![Internationalize your app](https://images.ctfassets.net/23aumh6u8s0i/44tGV5IPAOQMP7ySE9yjMD/ececb5e5ebfe5b79eba4f81a8c418c77/chrome-store)

The upshot is that if Chrome Store is working for you, you have a great opportunity to drive growth by internationalizing the app.

Pipedrive, for instance, “[translated the app](http://purde.net/2014/12/how-to-get-from-0-to-10000-paying-customers-in-saas/) and website to Spanish, German, Russian, Brazilian Portuguese, French and Estonian pretty early on.” They ended up seeing huge growth from the Chrome Store in Brazil, due to having a localized listing and getting mentioned in a prominent Brazilian blog.

### Deepen your integration

Start your integration with the app store provider by connecting single sign-on. Then, progressively make your integration deeper and deeper. Deep integration gives you two benefits:

1. Happier customers who are getting more value out of your product via improved workflows and better UX, and
2. The opportunity to get spotlighted in as a featured app.

App stores want to showcase apps that make the most of the platform they offer, and the difference between being above the fold and featured on the front page, and being beneath the fold and only accessible by browsing or by search is absolutely massive.

![Deeper integration in Chrome WebStore](https://images.ctfassets.net/23aumh6u8s0i/2iUQy7a9DfByRkjF82FBAN/eb97db7727c362c6d6036c7d6b2fd112/chrome-web-store)

When Google Drive launched, they looked for partner apps to showcase what you could do by integrating with Google Drive. [HelloFax](http://hellofax.com/)—an online fax tool—teamed up with them and built a Google Drive integration that made it easier to access and fax Google Docs. That got them [featured by the Chrome Store](http://blog.hellofax.com/uncategorized/nice-spot-in-the-chrome-web-store/) and they scored [50,000+ new customers](http://techcrunch.com/2012/05/10/hellofax-with-51k-installs-were-king-of-google-drive-apps/) in two weeks.

## Acquire Customers and Improve Your Product at the Same Time

Often, the hardest part of starting a company isn’t building product or innovating on technology—it’s acquiring customers. Building sales and marketing teams is particularly tough for engineering-focused founders.

<include src="TweetQuote" quoteText="Often, the hardest part of starting a company isn’t building product—it’s acquiring customers."/>

What’s most awesome about acquiring customers via apps marketplaces is that it turns the process of customer acquisition into a process of improving the product. As you add single sign-on and deeper integrations, you add and deepen your product’s functionality as the same time as you improve your product’s app store acquisition.

A few years in, the importance of the Chrome Store for Pipedrive’s business had dramatically decreased. Yet, those tailwinds provided by the free, frictionless customer acquisition via Chrome Store helped them build the rare, absolutely critical momentum that startups need to succeed in a big way.

They were able to focus 100% of their energy on improving the product, which got them from 0 to 10,000 customers and now has put them in a position to challenge the giants of CRM.

[Unlock B2B SaaS growth with modern identity management. Download free eBook here.](https://resources.auth0.com/unlock-b2b-saas-growth-iam/)


How to Get from 0 to 10,000 Customers with B2B App Marketplaces

d48b998c2dce49ca309710eba498c562

Former Auth0 Employee

Nathan Totten

Remembering usernames and passwords and login urls for all of these apps is a pain. With this app we take another step in simplifying the authentication experience.

<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>Update:</strong> The Single-Sign-On Dashboard referred in this article is now deprecated and has been replaced with the extension that can be found here: <a href="https://auth0.com/docs/extensions/sso-dashboard">Auth0 Extension: Single Sign-On (SSO) Dashboard</a>.
</div>

**tl;dr**: Control which apps your users can access with an SSO dashboard. Download the [code](https://github.com/auth0/auth0-sso-dashboard) or [deploy to Heroku](https://dashboard.heroku.com/new?template=https%3A%2F%2Fgithub.com%2Fauth0%2Fauth0-sso-dashboard) in 5 minutes.

Today, we are excited to announce the release of the Auth0 [Open Source Single-Sign-On Dashboard](https://github.com/auth0/auth0-sso-dashboard). This SSO dashboard is designed to solve a problem familiar to many people. Organizations of all sizes maintain a variety of different applications to handle various business functions like accounting, HR, development, support, etc. Remembering usernames and passwords and login urls for all of these apps is a pain. With this app we take another step in simplifying the authentication experience.

<include src="TweetQuote" quoteText="Today, we are excited to announce the release of the Auth0 Open Source Single-Sign-On Dashboard."/>



![SSO Dashboard](https://images.ctfassets.net/23aumh6u8s0i/52rZ04u2zwgwGtEGzjtim0/4c2a917d6d5fe7fd6a01b84a99e20db0/cfENOYpKxfL_)

You can find the entire source of this project on [Github](https://github.com/auth0/auth0-sso-dashboard) along with instructions on how to deploy and configure a dashboard for your own organization. Additionally, you can try out a demo version (with non-functional apps) at [https://ssodashboard.herokuapp.com](https://ssodashboard.herokuapp.com). Username: `publicdemo` Password: `TestUser123`. This demo only shows the user functionality; if you would like to see the full admin capabilities, please deploy your own instance.

A few key features of the SSO Dashboard:

* Landing page showing all apps that a user is allowed to access.
* Self-service user profile updates.
* Administrator interface for configuring roles, apps, and users.
* Completely customizable UI.

## Completely Open Source
Our approach to this project, like many projects at Auth0, was to build this as an open source app. This approach gives our users the most flexibility while still being very easy to maintain and receive updates.

* Node.js Backend (Express)
* React, Flux, and React-Router
* Bootstrap ([Paper Theme](https://bootswatch.com/paper/)) and [Material UI](http://callemall.github.io/material-ui/#/)
* [Babel](https://babeljs.io/) to enable ES6
* [Webpack](https://webpack.github.io/) for asset bundling

Feel free to fork and clone this project. We will accept pull requests and [issues](https://github.com/auth0/auth0-sso-dashboard/issues) if you want to contribute back.

If this is something you have been looking for at your company or organization do give it a try. Let us know what you think, we will be adding features based on feedback.

"single sign on"