---
title: "Using federated authentication with Sitecore"
slug: "using-federated-authentication-with-sitecore"
abstract: "Describes how to use external identity providers"
---
# Using federated authentication with Sitecore

Historically, Sitecore has used [ASP.NET membership](https://msdn.microsoft.com/en-us/library/yh26yfzy.aspx) to validate and store user credentials. With ASP.NET 5, Microsoft started providing a different, more flexible validation mechanism called [ASP.NET Identity](https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity).

ASP.NET Identity uses [Owin](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/owin) middleware components to support external authentication providers. These external providers allow federated authentication within the Sitecore Experience Platform.

Sitecore:

- Uses Owin middleware to delegate authentication to third-party providers.
- Gets claims back from a third-party provider.

Federated authentication is enabled by default. To disable federated authentication:

- In the `\App_Config\Include\Examples\ folder`, rename the `Sitecore.Owin.Authentication.Disabler.config.example` to `Sitecore.Owin.Authentication.Disabler.config`.

You can use Sitecore federated authentication with the providers that [Owin](http://owin.org/) supports. Most of the examples in our documentation assume that you use [Azure AD](https://docs.microsoft.com/en-us/azure/active-directory/active-directory-whatis), Microsoft’s multi-tenant, cloud-based directory and identity management service.

Owin.Authentication supports a large array of other providers, including Facebook, Google, and Twitter.

Federated authentication works in a scaled environment.

You can use Federated Authentication for front-end login (on a content delivery server), and we recommend you always use Sitecore Identity for all Sitecore (back-end) authentication.

Sitecore 9.1.0 or later does not support the Active Directory module, you should use federated authentication instead.

<details>
<summary><h2>Cookies and federated authentication</h2></summary>

If you do not use Sitecore.Owin.Authentication, the default authentication cookie name is `.ASPXAUTH`. You can change this in the `Web.config` file:

```xml
<authentication mode="Forms">
    <forms name=".ASPXAUTH" cookieless="UseCookies" />
</authentication>

```

If you use Sitecore.Owin.Authentication, however, the `.ASPXAUTH` cookie is not used. Therefore, you must not use this cookie directly from code.

Because Sitecore.Owin.Authentication overrides the `BaseAuthenticationManager` class and does not use the `FormsAuthenticationProvider` class underneath, it is not a problem that the `.ASPXAUTH` authentication cookie is missing for any code that uses the `AuthenticationManager` class.

When using Owin authentication mode, Sitecore works with two authentication cookies by default:

- `.AspNet.Cookies` – authentication cookie for logged in users
- `.AspNet.Cookies.Preview` – authentication cookie for preview mode users

These cookies let users log in and log out as different users in the Experience Editor Preview mode, and view Sitecore pages as different users with different access rights.

Sitecore constructs names are constructed like this:

- `".AspNet." + AuthenticationType + AuthenticationSource.`
    - The `AuthenticationType` is `Cookies` by default and you can change it in the `Owin.Authentication.DefaultAuthenticationType` setting.
    - The `AuthenticationSource` is `Default` by default. It is not included in the cookie name when it is `Default`. The `AuthenticationSource` allows you to have multiple authentication cookies for the same site.

You configure Owin cookie authentication middleware in the `owin.initialize` pipeline.

</details>

<details>
<summary><h2>Virtual and persistent users</h2></summary>

Federated authentication supports two types of users:

- Persistent users – Sitecore stores information about persistent users (login name, email address, and so on) in the database, and uses the Membership provider by default.
- Virtual users – information about these users is stored in the session and disappears after the session is over.

There is a limitation when Sitecore creates a persistent user to represent an external user: you can only change a user's password in the corresponding identity provider.

For a persistent user, the roles obtained after transformations are added to the user account as Sitecore roles. Before adding these roles, all previous roles are cleared from the user account. This enables an external user to have a set of roles assigned to their account and the process runs each time the user logs in to Sitecore.

We recommend that you manage users on the external identity server and assign roles to user accounts using [transformations](https://doc.sitecore.com/xp/en/developers/105/sitecore-experience-manager/configure-federated-authentication.html#UUID-c618bb48-a5b6-1e52-0c13-882e0666f797_N1614939275100 "Map claims and roles").

</details>