SharePoint Authentication and Session Management

What is authentication?

1. A security measure designed to protect a communications system against acceptance of a fraudulent transmission or simulation by establishing the validity of a transmission, message, or originator.
2. A means of identifying individuals and verifying their eligibility to receive specific categories of information.

Authentication is essentially the process of validating a user is who they say they are, such that they can gain access to a system – in this context, the system is SharePoint. Authentication is not authorization, which is the process in determine if a known user is permitted access to certain data in the system, after successful authentication.

SharePoint, much like any content management system, relies on user authentication to provide user access to secured content. Pre-SharePoint 2010, SharePoint relied on NTLM, Kerberos, or basic (forms-based) authentication protocols (their discussion out of scope of this text). SharePoint 2010 introduced Claims-based-Authentication (CBA), also present in SharePoint 2013. CBA consists of authentication abstraction, using a Secure Token Service (STS), and identification of users with multiple attributes –claims – not just the traditional username and password pair.

A Secure Token Service implements open standards. A typical STS implementation communicates over HTTPS, and packages user identity information (claim data) via signed and encrypted XML – Secure Assertion Markup Language (SAML). Examples of STS implementations are the STS engine in SharePoint 2010/2013, ADFS, and third party applications build using the Windows Identity Framework.

SharePoint Session Management

A user session in SharePoint 2010/2013 is the time in which a user is logged into SharePoint without needing to re-authenticate. SharePoint, like most secure systems, implements limited lifespan sessions – i.e. users may authentication with a SharePoint system, but they’re not authenticated with the system indefinitely. The length of user sessions falls under the control of session management, configured for each SharePoint Web Application.

SharePoint handles session management differently, depending on the authentication method in play (Kerberos, NTLM, CBA, Forms, etc.). This article discusses how SharePoint works with Active Directory Federated Services (ADFS) – an STS – to maintain abstracted user authentication and user session lifetime. The following is a sequence diagram of the default authentication and session creation process in SharePoint 2010/2013 when using CBA with ADFS.

The following is a summary of the authentication process, shown in the sequence diagram.

  1. A user requests a page in SharePoint from their browser this might be the home page of the site.
  2. SharePoint captures the request and determines that no valid session exists, by the absence of the FEDAUTH cookie.
  3. SharePoint redirects the user to the internal STS – this is important because the internal STS handles all authentication requests for SharePoint and is the core of the CBA implementation in SharePoint 2010/2013.
  4. Since we have configured SharePoint to use ADFS as a trusted login provider, the internal STS redirects the user to the ADFS login page.
  5. ADFS acquires credentials and authenticates the user.
  6. ADFS creates a SAML token, containing the user’s claims, as encrypted and signed.
  7. ADFS posts the SAML token to the internal SharePoint STS.
  8. The Internal STS saves the SAML token in the SAML Token Cache.
  9. SharePoint creates the FEDAUTH cookie, which contains a reference to the SAML token in the cache.
  10. The Internal STS redirects the user back to SharePoint, and then back to the original requested page.

Session Lifetime

The lifetime of a SharePoint session, when using ADFS, is the topic of much confusion. Ultimately, SharePoint determines whether a user has a current session by the presence of the FEDAUTH cookie. The default behavior of SharePoint is to store this persistent cookie on the user’s disk, with fixed expiration date. Before sending a new FEDAUTH cookie back to the user’s browser, SharePoint calculates the expiration of the cookie with the following formula:

SAML Token Lifetime – Logon Token Cache Expiration Window

The above values are important since they govern the overall lifetime of the FEDAUTH cookie, and hence the session lifetime. The following table describes each value and its source:

Configuration Value Description
SAML Token Lifetime This value, in minutes, is provided by the token issuer – ADFS. In the case of ADFS, each Relying Party configuration (one for each instance of SharePoint farm) has this value as part of the configuration.By default, SharePoint sets the session lifetime the same as this SAML token lifetime.

You can change this value using PowerShell and the ADFS command: Set-ADFSRelyingPartyTrust.


Add-PSSnapin Microsoft.ADFS.PowerShell

Set-AdfsRelyingPartyTrust –TargetName “Relying Party Name” –TokenLifeTime 10

Logon Token Cache Expiration Window This value, in minutes, is provided by SharePoint STS and governs how long the SAML token remains active in the cache, and therefore how long the associated user session remains alive. For example, if ADFS sets the SAML Token Lifetime to 10 minutes and this value is set in the STS as 2 minutes then the overall SharePoint session lifespan is 8 minutes.


$ap = Get-SPSecurityTokenServiceConfig

$ap.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 2)



Sliding Session

A siding session is one where the session expiration time changes as a user interacts with the system. By default, SharePoint 2010/2013 does not offer sliding sessions. Each new session expires on a fixed time, based on the aforementioned formula, earlier in this text.

Use of a sliding session does not mean that we must compromise security. Should a user become inactive, a sliding session will timeout just as the fixed session, the main difference that a user can extend a sliding session with continued use of the SharePoint system.

Creation of sliding session requires configuration of the Relying Party in ADFS and the SharePoint Logon Token Cache Expiration. The following PowerShell configures the Relying Party to 60 minutes, which is the absolute maximum time that a session remains active should the user become inactive:

Add-PSSnapin Microsoft.ADFS.PowerShell
Set-AdfsRelyingPartyTrust –TargetName “Relying Party Name” –TokenLifeTime 60

The following PowerShell sets the Logon Token Cache Expiration in SharePoint STS, which forces the sliding session lifetime to 20 minutes.

$ap = Get-SPSecurityTokenServiceConfig
$ap.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 40)

The above settings are only part of the solution. On their own we have a fixed session duration of 20 minutes, determined by the earlier mentioned formula subtracting the logon token cache expiration from the RP token lifetime. To make sure the session renews with continued activity, we must refresh the session (and FEDAUTH cookie), which we can achieve with an HTTP module. The following code is an excerpt to refresh the session with each HTTP request.

Persistent verses Session Cookies

By default, SharePoint stores the authentication/session (FEDAUTH) cookie as a persistent cookie on disk. This allows the user to close and reopen their browser and access SharePoint without having to re-authenticate. This behavior is not always desirable.

Fortunately, we can ask SharePoint to use in-memory cookies (session cookies) for the authentication (FEDAUTH) cookie, as follows:

$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true

5 thoughts on “SharePoint Authentication and Session Management

  1. Rob

    Hi Rob

    We dont want SharePoint to store the authentication/session (FEDAUTH) cookie as a persistent cookie on disk.

    Shifted back to in memory as you suggested.

    The problem is that it breaks Office integration (which we can live with).

    But even when turn off app integration at server level – we cant open office docs from std sharepoint library view without a login control coming up.

    Have you ever seen this before?

    We are Office 2010 and SharePoint 2010.

    Many thanks…


  2. Andrew Beno

    Hey Rob,

    I’m curious to get your opinion on a scenario we’re trying to achieve. We have FBA users logging into a SP2013 site using the OOTB forms login page. Ideally, we’d like to have the users re-authenticate when they close their browser, but it appears you need to set UseSessionCookies = true, but that then causes “problems” when accessing Office documents (the user is prompted to authenticate more or less every time). So, we have to then use persistent cookies. We’re then left with 3 variables to configure as far as I’m aware: FormsTokenLifetime, LogonTokenCacheExpirationWindow, and CookieLifetime. As far as I can tell, when your session will expire has nothing to do with FormsTokenLifetime or LogonTokenCacheExpirationWindow. For example, if we set the FormsTokenLifetime to 5 minutes, LogonTokenCacheExpirationWindow to 4 minutes, and CookieLifetime to 10 minutes.. the user can logon and be inactive for 8 minutes and not have to reauthenticate.

    I thought about configuring it as follows, but I’m not sure if there are any performance concerns with this setup and tokens being reissued:
    $sts = Get-SPSecurityTokenServiceConfig
    $sts.FormsTokenLifetime = (New-TimeSpan -Minutes 30)
    $sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -Minutes 20)
    $sts.CookieLifetime = (New-TimeSpan -Minutes 15)

    My understanding on the above would be if a user logs in and is active for the first 10 minutes, no token would be re-issued (since that’s in the FormsTokenLifetime – LogonTokenCacheExpirationWindow time period). After that first 10 minutes, if the user issues just one request within the next 5 minutes, the cookie lifetime will be extended by 15 minutes. If they are instead inactive for 5 minutes, the cookie would expire as it’s lifetime is 15 minutes and the user would have to reauthenticate. I’m not sure if these settings would be something to worry about performance wise, I suppose it depends on the number of users accessing the site at a given time. I also still need to do more testing on what happens after the token is re-issued (do the same time windows/constraints apply?).

    Anyway, nice post on this topic.. we’re not using ADFS but I still found it helpful.


  3. Rob Garrett

    Rob and Andy,

    Yes, Office integration is a real pain with session cookies, and does require use of a persistent cookie. It really comes down to a choice – in my case, my client was dead set on having the session expire when they closed the browser, and didn’t mind losing Office integration.

    Since April 2011 CU, SharePoint 2010 supports sliding session, see here:

Comments are closed.