5e074956ee8ba1fea26e30d28c190495?s=300 avatar

5e074956ee8ba1fea26e30d28c190495?s=300

Full stack developer creating content at Auth0. I love taking a deep dive into hard-to-understand concepts and creating content that makes them easier to grasp. In my free time you can usually find me reading, hanging out with my dogs, or curling in the squat rack.

Former Developer Content Manager

Holly Guevara

Learn what SAML is and how to set up a SAML identity provider

In this article, you'll learn what SAML is, how it works, and how you can configure a SAML identity provider using Auth0.

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

## What is SAML

Before jumping into the technical jargon, let's look at an example that demonstrates _what_ SAML is and _why_ it's beneficial.

You just started working at a new company, Wizova. They've given you a work email address and access to a dashboard. Once you sign in to this dashboard, you're presented with the icons of all of the external services the company uses: Salesforce, Expensify, Jira, AWS, and more.

You click on the Salesforce icon, some magic happens in the background, and before you know it, you're signed into Salesforce without ever entering any credentials.

As you might have guessed, the "magic" was actually SAML in action. So what's going on here?

SAML stands for Security Assertion Markup Language. It is an XML-based open-standard for transferring identity data between two parties: an identity provider (IdP) and a service provider (SP).

Identity Provider — Performs authentication and passes the user's identity and authorization level to the service provider.

Service Provider — Trusts the identity provider and authorizes the given user to access the requested resource.

In the scenario above, the identity provider would be the IdP that Wizova uses, Auth0. The service provider would be [Salesforce](https://www.salesforce.com/blog/sales-management-dashboards/). The Wizova employee signs into the Wizova dashboard with Auth0. They click on the Salesforce icon, and Salesforce recognizes that the user wants to log in via SAML. Salesforce sends the employee back to Auth0 with a SAML Request that asks Auth0 to authenticate the user. Since the employee has already authenticated with Auth0, Auth0 verifies the session and sends the user back to Salesforce with a SAML Response. Salesforce checks this response, and if it looks good, the employee is granted access.

## Benefits of SAML Authentication

- **Improved User Experience** — Users only need to sign in one time to access multiple service providers. This allows for a faster authentication process and less expectation of the user to remember multiple login credentials for every application. In the example above, that user could have clicked on any of the other icons in their dashboard and been promptly logged in without ever having to enter more credentials.

- **Increased Security** — SAML provides a single point of authentication, which happens at a secure identity provider. Then, SAML transfers the identity information to the service providers. This form of authentication ensures that credentials are only sent to the IdP directly.

- **Loose Coupling of Directories** — SAML doesn't require user information to be maintained and synchronized between directories.

- **Ability to Alter, Audit, or Revoke Access Centrally** — Because SAML doesn’t require synchronization between directories for each application, it isn’t necessary to notify each service provider to revoke or change access levels, meaning that access can be revoked quickly if necessary for a single service or across an enterprise. Similarly, auditing who has access to which services is easy with SAML because authentication logs are centralized.

- **Fewer Password Reset Requests** — Users only need to remember one set of credentials, so IT can focus on supporting your workforce without having to respond to numerous password reset requests.

- **Scalability** — Adding new users, applications, or services is straightforward, minimizing the overhead necessary for your organization to grow.

- **Reduced Costs for Service Providers** — With SAML, you don't have to maintain account information across multiple services. The identity provider bears this burden.

![how saml works separator 1](https://images.ctfassets.net/23aumh6u8s0i/21h3c71TFRMhR4nbU7AIkY/1c70c92d02ad10a334ab90144721d809/how-saml-works-1)

## How Does SAML Authentication Work?

Now that you've seen the high-level overview of how SAML authentication works, let's look at some of the technical details to see how everything is accomplished.

SAML single sign-on authentication typically involves a service provider and an identity provider. The process flow usually involves the _trust establishment_ and _authentication flow_ stages.

Consider this example:

- Our identity provider is **Auth0**
- Our service provider is a fictional service, **Zagadat**

> **Note**: The identity provider could be any identity management platform. 

Now, a user is trying to gain access to **Zagadat** using SAML authentication.

Let's break down how the different components of the diagram interact with each other to make authentication with SAML possible. The following diagram gives you a high-level overview of how SAML works:

![Process flow diagram](https://images.ctfassets.net/23aumh6u8s0i/3R8llxfSq6UuhWdagCaJjZ/1b2fd3d2e3645d35697b2016e25d3dd3/01_saml_flow.png)

Here is a description of each numbered step in the diagram:

1. The user tries to log in to Zagadat from a browser.
2. Zagadat responds by generating a SAML request. ![Typical SAML Authentication request](https://images.ctfassets.net/23aumh6u8s0i/2q3DgHFxiJCn8OB57rIaZ3/9b6da4bcbab9987d88dedc1bd42dbb8d/samlrequestzg)
3. The browser redirects the user to a [Single Sign-On (SSO) URL](https://auth0.com/docs/authenticate/single-sign-on), **Auth0**.
4. **Auth0** parses the SAML request and authenticates the user. This could be with username and password or even social login. If the user is already authenticated on Auth0, this step will be skipped. Once the user is authenticated, Auth0 generates a SAML response. ![Typical SAML Authentication response](https://images.ctfassets.net/23aumh6u8s0i/60UOe2pqoOcYFJqeGMzfA7/e0dd3cdd9a12b682fa648f27869b9588/SAMLResponse)
5. **Auth0** returns the encoded SAML response to the browser.
6. The browser sends the SAML response to **Zagadat** for verification.
7. If the verification is successful, the user will be logged in to **Zagadat** and granted access to the resources that they are authorized to view/modify.

Note the attributes that are highlighted in the SAML request and response. Here's a glossary of these parameters:

- **ID**: Newly generated number for identification
- **IssueInstant**: Timestamp to indicate the time it was generated
- **AssertionConsumerServiceURL**: The SAML URL interface of the service provider, where the Identity provider sends the authentication token.
- **Issuer**: The EntityID (unique identifier) of the service provider
- **InResponseTo**: The ID of the SAML request that this response belongs to
- **Recipient**: The EntityID (unique identifier) of the service provider

## SAML Authentication with Auth0

When it comes to implementing SAML, Auth0 is extremely extensible and able to handle several scenarios:

- Auth0 as the [identity provider](https://auth0.com/docs/protocols/saml/saml-configuration/auth0-as-identity-provider)
- Auth0 as the [service provider](https://auth0.com/docs/protocols/saml/saml-configuration/auth0-as-service-provider)
- Auth0 as the [identity and service provider](https://auth0.com/docs/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider)

For this example, you'll learn how to implement SAML authentication using Auth0 as the identity provider.

<include src="TweetQuote" quoteText="When implementing SAML, Auth0 can serve as the identity provider, service provider, or both!"/>

### Prerequisites

- **An [Auth0](https://auth0.com/) account** &mdash; If you don't already have one, you can [sign up for a free account here](https://a0.to/blog_signup).

- **An account with a service provider that supports SAML** &mdash; Generally, most service providers require you to have a business account or some paid plan to configure SAML.

<include src="SignupCTA" text="Try out the most powerful authentication platform for free." linkText="Get started →" />

The following image shows a list of the service providers Auth0 supports out-of-the-box, but you also have the option of [**configuring a custom service provider**](https://auth0.com/docs/protocols/saml/saml-configuration/auth0-as-identity-provider#manually-configure-a-sso-integration) in the dashboard.

![configuring a custom service provider](https://images.ctfassets.net/23aumh6u8s0i/1oKJfsjlupfnWeTZ013s31/2ab99a5fd2bcc7be780b530d6fdecbb2/03_saml_flow.png)

### Configure the service provider

This tutorial will use [Zendesk](https://zendesk.com/) as the service provider, but you can follow along with any SP of your choice.

To configure your chosen service provider, run through the following steps in your [Auth0 dashboard](https://manage.auth0.com/):

1. Click on SSO Integrations in the sidebar under **account > security**
2. Click on the **blue** button in the top right corner, Create SSO Integration
3. Select **SAML**
4. Enter the name and/or any identifying information required and press Save ![Configure the service provider](https://images.ctfassets.net/23aumh6u8s0i/3x0opMZ7nl5I5UYazGT3dk/c57eae72f111740c979170a80c065cf9/04_saml_flow.png)
5. Follow the instructions under Tutorial for your specific service provider

> **Note**: This step will require you to input some values on the service provider's side.

Here's what that looks like for **Zendesk**.

First, go into the **Admin Center** in the _Zendesk dashboard_ and click on Security. Next, click on SSO, and you'll find the SAML configuration settings. This is where you'll paste in those values from the Auth0 dashboard.

![Zendesk SAML setup](https://images.ctfassets.net/23aumh6u8s0i/3ghqY6FLvOLKAJwUfFTMpD/7d3192482acdb9039642446a5d04a1e9/05_saml_flow.png)

![Auth0 Zendesk tutorial setup](https://images.ctfassets.net/23aumh6u8s0i/3hEM5UYnYgHZ98uzhtKfBm/3546f05a32fac11df4a380fae1e41d5c/06_saml_flow.png)

Once these values are copied over, the last step is to enable external authentication for the users that should be able to login with SAML. Zendesk allows you to enable this for end-users, staff users, or both.

![Zendesk Auth0 end-user external authentication](https://images.ctfassets.net/23aumh6u8s0i/1GSsL2KvJFBlG4nhfqT4s3/67b635d77b4fcbd31c33d39049181700/07_saml_flow.png)

### Test it out

Now that everything is set up on both ends, it's time to test it out! See the video below for a demonstration of what the final flow should look like.

<AmpContent>
<amp-video controls
    layout="responsive"
    width="480" height="270">
    <source src="https://cdn.auth0.com/blog/what-is-saml/zendesk-auth0-demo.mp4"
    type="video/webm" />
</amp-video>
</AmpContent>
<NonAmpContent>
<video controls="controls">
  <source type="video/mp4" src="https://cdn.auth0.com/blog/what-is-saml/zendesk-auth0-demo.mp4" />
</video>
</NonAmpContent>

As you can see, once you go to your Zendesk URL, you're redirected back to Auth0, the identity provider, to sign in. Once authenticated, Auth0 sends this information back to Zendesk. Zendesk verifies the response, determines it valid, and grants you access to your Zendesk dashboard.

> **Note**: You may have noticed that in the video, the user signed in with Google SSO. This can be enabled in the Auth0 dashboard. You'll see how to implement this in the next section.

If you go back to your Auth0 dashboard, you'll now see a record of the user that just signed in.

![Auth0 SAML Zendesk new user login](https://images.ctfassets.net/23aumh6u8s0i/75LHYuDkJSmqGqSFYcGo1c/0be08541c1f08ba6950e8f2568ba5191/08_saml_flow.png)

> **Note**: If you'd like to debug a SAML response, check out [https://samltool.io](https://samltool.io/). This tool can decode a SAML response and serves as a useful debugging resource.

### Enable SSO (optional)

Now that your service provider is set up with Auth0, your users can sign in using an email and password by default. A common use case, especially with SAML authentication, is to have users sign in using single sign-on (SSO) with a social provider.

Auth0 supports several [social identity providers](https://auth0.com/docs/connections/identity-providers-social) that you can enable with the click of a button.

In your dashboard, click on Connections > Social in the sidebar. Select the provider you'd like to use and fill in the details required for that provider.

> **Note**: Make sure you [use your own keys](https://auth0.com/docs/connections/social/devkeys) for the selected provider. You may use the default Auth0 developer keys for testing, but they should not be used in production.

![Auth0 social connections](https://images.ctfassets.net/23aumh6u8s0i/2UTEiyqothV4PS6Ia6F2gp/f2a7e2a5d73ffc09c815149ab3f4c52b/09_saml_flow.png)

Once you've selected the social connections you want to use, go back to the SP you configured under SSO Integrations. Select the SP, and under Connections, you should see the social connection you just created. Click on the switch to enable it, and now your users are ready to sign in with any of the connections listed.

> **Note**: Some SSO integrations are very easy, and simply require the user to enable them as described above; however, a few of the SSO options require additional steps that are specific to the social network. For example, Facebook requires the user to create an app on the Facebook Developers site, and requires some additional fields and steps like supplying an App ID. Some applications may require a review process. While a comprehensive guide to all of these processes is out of scope for this tutorial, each network typically publishes their own guide for configuring SSO. Facebook’s guide can be found here: [Enable single sign-on for your organization’s managed Meta accounts in Admin Center](https://www.facebook.com/help/624731485413747).

![Auth0 SAML SSO connections](https://images.ctfassets.net/23aumh6u8s0i/6NEsKC1MtjzRjkcw7Ur1vz/ab52ae9016b48836218f0ffcf3efef25/10_saml_flow.png)

## More Auth0 SAML Configurations

Auth0 is adaptable when it comes to SAML configuration. Here are some of the other ways you can configure Auth0:

- Configure [Auth0 as a Service Provider](https://auth0.com/docs/protocols/saml/saml-configuration/auth0-as-service-provider) in a SAML federation
- SAML Configurations for SSO Integrations such as Google Apps, Hosted Graphite, [Litmos](https://auth0.com/docs/protocols/saml/saml-apps/litmos), [Cisco Webex](https://auth0.com/docs/protocols/saml/saml-apps/cisco-webex), [Sprout Video](https://auth0.com/docs/protocols/saml/saml-apps/sprout-video), [FreshDesk](https://auth0.com/docs/protocols/saml/saml-apps/freshdesk), Tableau Server, [Datadog](https://auth0.com/docs/protocols/saml/saml-apps/datadog), and more
- Configure Auth0 to use other identity Providers such as [Okta](https://auth0.com/docs/protocols/saml/identity-providers/okta), [OneLogin](https://auth0.com/docs/protocols/saml/identity-providers/onelogin), [PingFederate 7](https://auth0.com/docs/protocols/saml/identity-providers/ping7), [SalesForce](https://auth0.com/docs/protocols/saml/identity-providers/salesforce), [SiteMinder](https://auth0.com/docs/protocols/saml/identity-providers/siteminder), and [SSOCircle](https://auth0.com/docs/protocols/saml/identity-providers/ssocircle)
- Configure Auth0 as both the [service provider and identity provider](https://auth0.com/docs/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider)

![how saml works separator 3](https://images.ctfassets.net/23aumh6u8s0i/3JxeMOsMizQrSavWXxZ3Ud/84c3b1775f4de7ac78860dea7f9aae1b/how-saml-works-3)

## Conclusion

You have covered how SAML authentication works, the benefits SAML provides, and how to implement SAML with Auth0 as the identity provider. If you have any questions, feel free to reach out below.


How SAML Authentication Works

matt-raible

Matt Raible is a well-known figure in the Java community and has been building web applications for most of his adult life. For over 20 years, he has helped developers learn and adopt open source frameworks and use them effectively. He's a web developer, Java Champion, and Developer Advocate at Okta. Matt is a frequent contributor to open source and a big fan of Java, IntelliJ, TypeScript, Angular, and Spring Boot. 

Developer Advocate

Matt Raible

Learn how to build a Spring Boot application that authenticates against Okta and Auth0 with Spring Security's SAML support.

Get Started with Spring Boot and SAML

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?

eHk3ciM

I am the Group Manager, Developer Content at Okta, and a Google Developer Expert in Web Technologies and Angular. I'm passionate about identity, authentication, constant learning, and developer communities. As a developer advocate, engineer, mentor, and international speaker, I love learning from and sharing with other inhabitants of the tech space.

Group Manager, Developer Content

Kim Maida

This new series of short screencasts walks through common scenarios for integrating Auth0



Auth0's Developer Success Engineers work with customers around the world to make it as easy as possible to integrate Auth0 into their products. Working at the front line of real-world implementations, they know what difficulties to watch out for, as well as the solutions that keep things running smoothly.

We're excited to share this knowledge in a new, ongoing series of **Developer Success videos**, now available on the [Auth0 YouTube channel](https://www.youtube.com/auth0)! These short screencasts walk through solutions to the most common issues addressed in support tickets. The video series will be updated regularly, so make sure to [subscribe to the Auth0 YouTube channel](https://www.youtube.com/auth0?sub_confirmation=1) if you'd like to be notified about new releases.

We're kicking things off with five brand-new videos:

### Integrating Auth0 with Azure AD

<iframe width="560" height="315" src="https://www.youtube.com/embed/tV-2nQRFCio" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

> "In this tutorial we'll show you how to quickly integrate your Azure AD instance with Auth0 and be up and running in minutes...Now we just need to configure our connection in Auth0. In the Auth0 dashboard, go to connections, click Enterprise, and then at the bottom here you'll see Microsoft Azure AD. Click the little plus button on the right."

You can read more about [connecting your app to Microsoft Azure Active Directory](https://auth0.com/docs/connections/enterprise/azure-active-directory/v2) in our docs and leave feedback on this video in our [community forum](https://community.auth0.com/t/how-to-integrate-auth0-with-azure-ad-video-walkthrough/22517).

### Setting up a Custom Database Connection in Auth0

<iframe width="560" height="315" src="https://www.youtube.com/embed/Go_rvdYuF5c" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

> "In this video, I am going to show you how to set up a custom database connection, including user migration. I will also show you how to troubleshoot the connection. Before creating a connection in Auth0, we will set up an external database and create some demo users. To make it simple, I am going to use mLab, which is a fully managed cloud database service featuring automated provisioning and scaling of Mongo databases."

You can read more about [authenticating users using a custom database](https://auth0.com/docs/connections/database/custom-db) in our docs and leave feedback on this video in our [community forum](https://community.auth0.com/t/how-to-set-up-custom-database-connections-video-walkthrough/22518).

### Configuring SAML when Auth0 is Service Provider with Identity Provider Initiated Flow

<iframe width="560" height="315" src="https://www.youtube.com/embed/hZGYWeBvZQ8" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

> "Identity provider initiated SAML login flow starts by the user logging into the identity provider. The identity provider's responsibility is to send the SAML token, aka the assertion of the authenticated user, to the service
provider, once the user provides valid credentials. Once Auth0 is configured as the SAML service provider, it acts as an intermediary. We decode the received assertion from the identity provider and extract the user information, amongst other things required by the SAML protocol."

You can read more about the [SAML protocol](https://auth0.com/docs/protocols/saml/saml-configuration/auth0-as-service-provider) in our docs and leave feedback on this video in our [community forum](https://community.auth0.com/t/how-to-configure-saml-when-auth0-is-service-provider-with-identity-provider-initiated-flow-video-walkthrough/22519).

### Custom Domain Issues

<iframe width="560" height="315" src="https://www.youtube.com/embed/f6fkOkS1RFA" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

> "This video addresses some common support issues associated with setting up custom domains in Auth0. After you have enabled your custom domain, there's some simple but important settings that we need to be aware of. This is especially true when using Universal Login."

You can read more about [custom domains](https://auth0.com/docs/custom-domains) in our docs and leave feedback on this video in our [community forum](https://community.auth0.com/t/how-to-solve-common-custom-domain-issues-configuration-video/22520).

### Connecting Auth0 to an ADFS server

<iframe width="560" height="315" src="https://www.youtube.com/embed/ICW6sGP9ht8" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

> "In this tutorial, we'll show you how to quickly integrate Auth0 with your ADFS instance...Let's move on to the final step, configuring our ADFS connection in Auth0. First, let's go to our Enterprise connections. Click the plus
sign next to ADFS to configure a new connection."

You can read more about [connecting Auth0 to your ADFS server](https://auth0.com/docs/connections/enterprise/adfs) in our docs and leave feedback on this video in our [community forum](https://community.auth0.com/t/how-to-connect-auth0-to-an-adfs-server-video-walkthrough/22521).

## We'd Love Your Input!

Are these videos helpful? Please share any and all feedback you may have in the comments below. We also welcome suggestions and requests for topics to cover in future videos — what can we do to make your Auth0 integration ASAP (*as smooth as possible* 😉)?


Streamline your Auth0 Integrations with These Quick Tip Videos

kapehe-jorgenson

Kapehe is an R&D Content Engineer for Auth0 with a passion for learning and teaching. With her primary focus on ReactJS and JavaScript, she is impressed with what code can create for the web. Technology and web development are constantly evolving and naturally bring that need for continual learning. She enjoys writing tutorials, hosting local meetups, and learning with others to expand coding knowledge.

R&D Content Engineer

Kapehe Jorgenson

A brief overview of the top identity open standards used today.



**TL;DR:** In this overview, we will go over what open standards are and why they matter. We will also go over the top open standards used for identity including OAuth 2, OpenID Connect, JWT, and SAML. Open standards are important to understand but one can easily get overwhelmed by the technical specifications.

<include src="TweetQuote" quoteText="An overview of the top open standards used for identity including OAuth 2, OpenID Connect, JWT, and SAML."/>

## What is an Open Standard?
Identity, and the infrastructure that goes behind making identity **secure**, **lightweight**, and **reliable**, can be a challenge, one that can take up a lot of your team’s time to get just right. One way to reduce the overhead is to utilize open standards, rather than reinventing the wheel.

Open standards are community and industry-driven specifications that can define roles for an app, whether that role is the user, the identity provider, or the service provider, and how those roles talk to each other. Standards also define how apps are able to communicate with each other and to service providers. This can all happen without compromising key details or code.

Open standards can be implemented across many languages, platforms, and technologies, making it easy for a wide variety of organizations to utilize their benefits. 

The formation of open standards has created a uniform way of expressing the fundamental keys of identity across the industry, while still allowing flexibility around the specific path of implementation.

<include src="TweetQuote" quoteText="Open standards can be implemented across many languages, platforms, and technologies, making it easy for a wide variety of organizations to utilize their benefits."/>

### Open Standards You May Know

Modern web development relies on a range of well-known open standards that you may already be familiar with. They cover many facets of web development, from **JSON** (JavaScript Object Notation), used to structure data in a readable format, to **HTML** (HyperText Markup Language), used for creating web pages, all the way to **SAML** (Security Assertion Markup Language),  which is used for enterprise identities as described below.

## Four Common Open Standards for Authentication and Authorization

### OAuth 2
OAuth 2 is the latest version of the OAuth protocol, allowing for **better authorization flow across many devices and applications**. Users can grant a third-party website limited access to their information on another website without exposing their credentials. 

OAuth 2 is one of the most widely used open standards for delegating access, one that you as a user probably see implemented often. For example, when you log in to a website that wants access to information from your Google account (i.e., contacts), you grant authorization via OAuth 2. You can find the official docs for [OAuth 2 here](https://tools.ietf.org/html/rfc6749) and view [Auth0's thorough overview of OAuth 2](https://auth0.com/blog/oauth2-the-complete-guide/).

### OIDC (OpenID Connect)
OpenID Connect is an extra identity layer built on top of OAuth 2 that specifies a process for checking a user’s identity by ensuring they are who they say they are.

> OIDC is able to retrieve the user’s basic profile information from the identity provider. 

For example, when a user visits a website and can log-in via Google or Facebook, that application will then go to Google or Facebook and get those user's credentials. The application then does not have to store the user's basic profile and can utilize Google or Facebook and their storage of the user's information to grant access and verify their identity.

OpenID Connect is _API-friendly_ and can be used across mobile applications, web-based applications, all JavaScript clients, and many other types of clients. OIDC also requires the use of JSON Web Tokens which we will get into next. You can find the official docs for [OpenID Connect here](https://openid.net/connect/).

### JWT (JSON Web Tokens) 
Sending information, such as user data, across many different applications can be done using **JSON Web Tokens**. JSON web tokens hash information into a long, encoded string of characters that can be broken into three parts:

* The header that declares the hashing algorithm and the token type. 
* The payload or data where you could have the name of the user or other relevant information like the token expiration time or the subject. 
* The verifying signature made up of the header, payload, and a secret all hashed together. 

The JWT can get long, but this open standard provides a straightforward way to transfer information. If you visit [jwt.io](https://jwt.io/), there is a tool there where you can put in any encoded JWT and it will decode it for you as follows:

**JWT - encoded:**

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
```

**JWT - decoded:**

Header:

```json
{
  "alg": "HS256",
  "typ": "JWT"
}
```

Payload:

```json
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}
```

Verify Signature:

```
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
) secret base64 encoded
```

JWTs can be verified and trusted because they have a **digital signature**. That digital signature verifies that nothing was changed while the JWT was being passed. You can find more information on [JWTs here](https://auth0.com/learn/json-web-tokens/).

### SAML (Security Assertion Markup Language)
An XML-based open standard, SAML ensures that there is a secure communication of identities between organizations. This is a great tool for businesses when they want to communicate user authentication and authorization information to other organizations that their employee may need access to. Some benefits include:

* Increased security through a single point of authentication
* Improved user experience by utilizing a single sign-on access point.
* A centralized user access control allowing for a one-stop authentication point

SAML utilizes a _SSO (single sign-on) format_. Digitally signed XML documents are passed between the business and multiple third-party entities they have partnered up with. You can find [more information on SAML here](https://auth0.com/blog/how-saml-authentication-works/).

---

## Summary

As we have learned, the flexibility of open standards allows for the identity industry to be on the same page, reduce overhead, and create a uniform way of expressing the **fundamental keys of identity**. When everyone implements a standard way of doing things, then the _flow_ over different languages, projects, and teams can go as planned with authentication and authorization.

At Auth0 we use open standards so that we can connect our product to users and clients alike in a **standard and secure** way. Identity can be tricky, but here at Auth0 you can rest assured that your users are backed by industry-defined open standards. We use open standards to provide you with a secure solution that can be implemented in a matter of minutes. We have you covered, open standards and all.

Want to continue learning about these open standards? Visit the Auth0 docs for the above mentioned open standards: 

* [OAuth 2](https://auth0.com/docs/protocols/oauth2)
* [OpenID Connect](https://auth0.com/docs/protocols/oidc)
* [JWTs](https://auth0.com/docs/jwt)
* [SAML](https://auth0.com/docs/protocols/saml/saml-configuration)

<a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up for a free Auth0 account here</a>


An Overview of Open Standards

sam-judson

Former Auth0 Employee

Samuel Judson

Duo Security announced the discovery of a new class of SAML response vulnerability affecting SSO. Auth0 is not vulnerable to this issue.



On February 27, 2018, [Duo Security](https://duo.com) announced the discovery of a new class of vulnerability affecting SAML-based single sign-on systems. This flaw can allow an authenticated attacker to fool SAML systems into logging in as a different user, even without knowledge of the victim’s password. Note that this type of attack can be prevented by Multi-Factor Authentication, even if software used is vulnerable.

Malicious impersonation of this type can have a broad range of risks, including (but not limited to) compromising the victim as well as the system. An attacker could potentially impersonate a user with greater permissions, as well as elevate their own privileges.

Researchers from [Duo Labs](https://duo.com/labs), Duo’s security research team, identified several vendors affected by this class of vulnerability. You can read more information on SAML, details of the exploit, and affected vendors in Duo’s announcement here: [Duo Finds SAML Vulnerabilities Affecting Multiple Implementations](https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations).

## Auth0 is Not Affected by the Vulnerability

As [cited in Duo’s disclosure](https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations), all three of the following items are needed in order to enable this vulnerability:

1. SAML Responses contain strings that identify the authenticating user.
2. XML canonicalization (in most cases) will remove comments as part of signature validation, so adding comments to a SAML Response will not invalidate the signature.
3. XML text extraction may only return a substring of the text within an XML element when comments are present.

The library that Auth0 uses internally to parse SAML responses prevents the third requirement for exploitation. This prevents the vulnerability being exploited when  Auth0 is used as a SAML Service Provider (SP).

## Am I Affected?

Auth0 is not vulnerable to this issue, therefore, Auth0 customers do not need to take any action if using Auth0 as a SAML SP. However, if you are using Auth0 as a SAML Identity Provider (IdP) and are _processing SAML responses in your own code_, you will need to verify whether the libraries you are using are vulnerable as per [the original disclosure from Duo](https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations). If you are using a vulnerable library, you must ensure that **any affected software is updated to patch the vulnerability**.

Auth0 provides the [passport-wsfed-saml2](https://github.com/auth0/passport-wsfed-saml2) Passport strategy as open-source software. This strategy is **not vulnerable** to this SAML security vulnerability reported by Duo. If you or your company are using this strategy, you do not need to take any additional action.

If you have any further questions or concerns, please [open a support ticket](https://support.auth0.com/) or [ask in our community forum](https://community.auth0.com/).


Auth0 Not Affected by SAML Vulnerabilities Identified by Duo Security

bc94ff6211e645a2bdb4fdc60e23ad85

Kassandra Perch

This is the start of the Lock screencast series, where we show how to implement Lock in a web application


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

---
So today we're introducing a new screencast series for Lock, which will include ways to get started with Lock, customizing it, and taking a look at the API. Today we'll start with the basic implementation of Lock in a web app:

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

The demo is an Express application with a login and logout route, and some Javascript on the front-end. We can login using either Twitter or username/password, and logout.

Let's start with our assumptions for this exercise: you have a server with the following routes:

* `/users/authenticate`, which Lock can call that will register a user as logged in
* `/users/logout`, which Lock can call that will end a user's session and log them out

If you need help with these, [we have quickstart guides in our docs](https://auth0.com/docs), including [the Express quickstart](https://auth0.com/docs/quickstart/webapp/nodejs/) that I used to set this tutorial up.

We also have some elements in our Jade page layout:

* `.js-login`, which corresponds to our 'Login' button
* `.js-logout`, which corresponds to our 'Logout' button

Finally, we have imported the following libraries into our client-side environment:

* JQuery
* [Lock](https://github.com/auth0/lock)

That all being said, let's write our code to construct an instance of Lock that we can use. You'll need your ClientID and Auth0 domain, which you can find [in the dashboard](https://manage.auth0.com) under 'Apps/APIs', and clicking your App's name.

```javascript
var lock = new Auth0Lock('YOUR_CLIENT_ID', 'YOUR_DOMAIN.auth0.com');
```

Now, let's set up showing the lock dialog when we click `.js-login`:

```javascript
$('.js-login').on('click', function(event){
  event.preventDefault();
    lock.show({
      callbackURL: 'http://localhost:3000/users/authenticate',
      rememberLastLogin: false
    });
});
```

The first argument is the options object. We'll go into detail on more options in the next episode, but we should talk about the two ways Lock can operate:

* Redirect mode: this mode *is the recommended usage*, and used for regular web apps that use typical navigation
* Popup mode: this mode is specifically designed for single-page applications, and uses tokens instead of redirects

To set redirect mode, we set `callbackURL` to our server's `users/authenticate` route.

We also send `rememberLastLogin` as `false` -- this prevents Lock from prompting us with the last user to log in.

Next, let's take a look at logging out when the user clicks '.js-logout':

```javascript
  $('.js-logout').on('click', function(event){
    event.preventDefault();
    lock.logout({
      returnTo: 'http://localhost:3000/users/logout'
    });
});
```

The `returnTo` option tells Auth0 where to redirect the user once it has logged out our user, allowing the server to clean up.

That's it! With just a few lines of code you have implemented Lock in your web app! In the next episode we'll talk about the options you can use to construct your Lock instance-- things like what login types to show, remembering which user was logged in last, etc.

<include src="TweetQuote" quoteText="With just a few lines of code, you can implement Lock in your web app"/>

Thanks for reading!


Getting Started with Auth0 Lock Series: Implementing Lock

Setting up SAML authentication with Auth0 is as easy as setting any social connection (like Google!)



Today's video is about how easy it is to make the switch from social identity providers like Google to more complex providers, like those using SAML, using Auth0. We'll cover how in minutes, with no change to client or server code, you can easily allow users from SAML systems to log in to your Auth0 application. We've included the video, as well as a short written summary, below:

<iframe src="//fast.wistia.net/embed/iframe/2xrll0d056" allowtransparency="true" frameborder="0" scrolling="no" class="wistia_embed" name="wistia_embed" allowfullscreen mozallowfullscreen webkitallowfullscreen oallowfullscreen msallowfullscreen width="640" height="400"></iframe>
<script src="//fast.wistia.net/assets/external/E-v1.js" async></script>

Today we'll talk about how easy it is to integrate SAML authentication with Auth0.

So let's start with a hypothetical: you're building a SaaS product, and some of your enterprise customers want their employees to be able to access your product through [Single Sign-On (SSO)](https://resources.auth0.com/definitive-guide-to-single-sign-on/?utm_source=blog)...and their Identity Provider (IdP) happens to use SAML for authentication.

SAML is a complex standard, and so implementing Federation yourself, even with [already existing libraries](https://www.npmjs.org/package/saml2-js) can be quite a nightmare, and require lots of code and maintenance.

Luckily, Auth0 supports SAML authentication (you can even use [Lock](https://auth0.com/lock)) with just a few lines of code and some configuration.

<include src="TweetQuote" quoteText="Auth0 supports SAML authentication with just a few lines of code and some configuration."/>

So what we're going to go over today is how to get that started and how easy it is to switch over to SAML authentication from a social login provider like Google.

First, we have an Express implementation (you can read more about this in [our quickstart guide for Express](https://auth0.com/docs/quickstart/webapp/nodejs/)) of Auth0 logins. All I needed to do is include [passport.js](https://npmjs.org/package/passport) and [the Auth0 strategy](https://npmjs.org/package/passport-auth0). I then use these tools in my route to check that the user has logged in once Lock has redirected the app, and logged out once Lock's logout function has redirected me:

```javascript
var express = require('express');
var router = express.Router();
var passport = require('passport');

/* GET users listing. */
router.get('/', function(req, res, next) {
  res.send(req.user);
});

router.get('/authenticate',
  passport.authenticate('auth0', { failureRedirect: '/error' }),
  function(req, res) {
    if (!req.user) {
      throw new Error('user null');
    }
    res.redirect("/");
  });

router.get('/logout', function(req, res){
	req.logout();
	res.redirect("/");
})

module.exports = router;
```

So on the client side, once you've [required the Lock.js library](https://auth0.com/docs/quickstart/webapp/nodejs/#6-triggering-login-manually-or-integrating-the-auth0lock), we just need to call `lock.show()` and `lock.logout()` to allow users to log in and out, respectively:

```javascript
$(function(){
	var lock = new Auth0Lock('FIluNL0AWyBE3hYs3exbawhJD9rZNdh3', 'kperch.auth0.com');

	$('.js-login').on('click', function(event){
		event.preventDefault();
		lock.show({
			callbackURL: 'http://localhost:3000/users/authenticate',
			rememberLastLogin: false,
			// connections: ['google-oauth2', 'auth0']
		});
	});

	$('.js-logout').on('click', function(event){
		event.preventDefault();
		lock.logout({
			returnTo: 'http://localhost:3000/users/logout'
		});
	});
})
```

So let's enable Google logins and see how this works. First, [go to the dashboard](https://manage.auth0.com/), and select 'Connections', then 'Social' from the menu on the left. Click 'Google' to open the configuration menu:

![Google connection configureation window](https://images.ctfassets.net/23aumh6u8s0i/zKLP0IHODZYay2QJG9V0s/1b0c4cf46af56319ae11efcb0f5c2da9/configure-google)

We're going to leave the 'Client ID' and 'Client Secret' blank in order to test using Auth0's API keys. So, simply hit 'Save' at the bottom of the window. You can now use Google accounts to log in to your app.

Next, we'll take a look at how to configure SAML authentication without changing *any* of the code we've already written.

First, you'll need some information from your SAML IdP. We have [documentation on many common third-party IdPs in our docs](https://auth0.com/docs/saml-configuration), including a list of the information you'll need for this tutorial:

* SSO Sign In URL
* SSO Sign Out URL
* X509 Signing Certificate

First, I turn off my Google provider. Then, click 'Enterprise' under 'Connections' in the left menu. Click 'SAMLP Identity Provider' to enter the connection management menu. Click 'Create new Connection'.

![SAML Authentication Configuration Window](https://images.ctfassets.net/23aumh6u8s0i/TlriqJpB9lCePy9U2674m/94201f76a38af63df85c3d83759f8f47/configure-saml)

Enter a name in 'Connection Name'. Then, place your SSO Sign In and Sign Out URLs in the fields labeled 'Sign In URL' and 'Sign Out URL', respectively. Finally, upload the X509 Signing Certificate by clicking the orange 'Upload Certificate' button.

You can enter domains under 'Email Domains' in order to tell Lock which user emails should be filtered through to this SSO connection.

That's it for SAML authentication configuration! Click 'Save' and 'Continue'. You will see a list of instructions-- you will need to provide these instructions to your IdP in order to complete the process (if you are using a third-party, like we do in this tutorial with SSOCircle, check [our docs](https://auth0.com/docs/saml-configuration) to see if your next steps are up to you).

Once you have done this, you can test your new SAML connection in the Dashboard. Go to 'Connections' > 'Enterprise', then select 'SAMLP Identity Provider'. Next to your connection name, you should see a play icon. Click it to try your SAML login from the dashboard. If this works, you are ready to log in using SAML authentication in your Auth0 app!

With just a few minutes and no code changes, we have incorporated a SAML SSO into our Auth0 app! Want to learn more? [try our free plan](https://auth0.com/pricing), and you can checkout the [30+ social IdPs](https://auth0.com/docs/identityproviders#social) and the [enterprise IdPs](https://auth0.com/docs/identityproviders#enterprise) that we support.

I'm Kassandra from Auth0, and thanks for reading!

[Want to learn more about Single Sign-On? Get The Definitive Guide on SSO (74-page free eBook) here.](https://resources.auth0.com/definitive-guide-to-single-sign-on/?utm_source=blog)


Switching from Social Authentication to SAML in Minutes with Auth0

eugenio-pace-new-avatar

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

CEO and Co-Founder

Eugenio Pace

You probably noticed that we are adding apps at a very fast pace. This past week we added SpringCM and EchoSign.

You probably noticed that we are adding apps at a very fast pace. This past week we added [SpringCM](http://www.springcm.com) and [EchoSign](http://www.echosign.com). And we have a few more in the pipeline, as customers request them. There's no magic here, and we are a small team. So, how we do it? The secret is that it really takes very little effort. Auth0 ships with a generic __SAML App__ that is completely configurable:

![](https://images.ctfassets.net/23aumh6u8s0i/5gryzbD9bCDQz8nMENZoz4/07006ec99cc55807d25b3928e9f9b22c/saml2-config)

Supported apps like Box, Dropbox, Zendesk, Salesforce, SpringCM, EchoSign, etc. are just _templates_ to simplify and streamline configuration. But they are not strictly needed.

###Any app that supports __SAML__ is automagically supported by Auth0.

The integrations that have taken longer to publish, are with those companies that have chosen not to offer a self-service experience, and require us to call their support and enable/setup the feature for us. Human intervention adds a lot of latency in the process.

> Special kudos to [SpringCM](http://www.springcm.com) and [EchoSign](http://www.echosign.com) for a fantastic onboarding experience and great support.



##Setup

Configuring a SAML aware app is usually a matter of tweaking a few parameters. We've chosen to surface these as a Json object that you can edit online:

![](https://images.ctfassets.net/23aumh6u8s0i/2RR5VG7cYH4AR0JFBuSAPL/c66d0885a484e42bc7491fe0f1782aca/saml2-config-param)

We've even included an online __SAML debugger__ that shows exactly the `SAMLResponse` (encoded and decoded) that we generate. One step forward in simplifying troubleshooting of integrations. When you click on __Debug__, we will initiate the authentication process to whatever identity providers you have configured. After successful authentication we will return and display the result:

![](https://images.ctfassets.net/23aumh6u8s0i/3a2JzhvpM5xyp9WlyNzUAK/1e05595a27b1d83921100077844ee4fb/saml-debugger)

You can easily look for attributes, mappings, signatures and other SAML artifacts to quickly identify mis-configurations.

So, if you don't see the app you need on our list, fear not! Use this feature or let us know:
[open a support ticket](https://support.auth0.com)

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

[Want to learn more about Single Sign-On? Get The Definitive Guide on SSO (74-page free eBook) here.](https://resources.auth0.com/definitive-guide-to-single-sign-on/?utm_source=blog)

"saml"