SharePoint 2013 authentication lifetime settings

When SharePoint 2013 authenticates a user, the Security Token Service creates a security token with the user's identity and several other claims. This token is then added to the Distributed Logon Token Cache so that it can be checked later to confirm that the user is authenticated.


When built, the token gets a lifetime that depends on the authentication provider used by the user to authenticate. For Windows and Forms (FBA) authentication, the lifetime is a fixed amount of time that is set on the Security Token Service configuration. For trusted providers like AD FS, the lifetime depends on the validity of the security token POSTed to SharePoint's /_trust/ endpoint.


This lifetime has a direct impact in how often the user will need to authenticate. When the user makes a request, the token in the cache is checked and if it is expired, then the user needs to authenticate again.


As explained above, the lifetime can be configured in the STS for Windows and Forms authentication. The current values can be reviewed with Get-SPSecurityTokenServiceConfig.




This lifetime applies to user sessions authenticated with Windows Integrated Authentication (NTLM/Kerberos).

The default value is 10 hours.


$sts = Get-SPSecurityTokenServiceConfig

$sts.WindowsTokenLifetime = New-TimeSpan -Hours 10





The same as above but applies to Forms/FBA authentication sessions.

The default value is also 10 hours.


$sts = Get-SPSecurityTokenServiceConfig

$sts.FormsTokenLifetime = New-TimeSpan -Hours 10





The lifetime of a token in the cache is deducted the window value when checking if it is expired. This means that the real lifetime of the token will be less than expected. The following diagram can be helpful to understand when a token is valid and the roles the lifetime and window play in the expiration.



The default value for the expiration window is 10 minutes.


$sts = Get-SPSecurityTokenServiceConfig

$sts.LogonTokenCacheExpirationWindow = New-TimeSpan -Minutes 10





When using FBA or a trusted provider, SharePoint will set a cookie on the client called FedAuth. I'll not go into the details of what's inside the FedAuth cookie. Of course, the FedAuth cookie will have by default a certain lifetime. Session cookies can be configured too making the cookie invalid after the closing the browser and then bypassing the value in this settings.


The default value is 5 days.


$sts = Get-SPSecurityTokenServiceConfig

$sts.CookieLifetime = New-TimeSpan -Days 5



So, if we are using a trusted provider, for example, AD FS, how do we control how long the token will be valid? It will depend on how you can configure the STS that creates the token but if it is AD FS then you can set this in the Relying Party configuration.


ADFS RP's TokenLifetime


This setting will change for how long the security token created by AD FS is valid. SharePoint will use this lifetime and set its security token lifetime to the same value.


The default value is 60 minutes (which appears as 0 if the setting has not been changed in the RP).


You can check the current settings with:


Get-AdfsRelyingPartyTrust | ft -auto Name,TokenLifetime


And to change the value for a RP:


Set-AdfsRelyingPartyTrust -TargetName "SharePoint 2013" -TokenLifetime 30


These are the main settings related to session lifetimes when dealing with user authentication. There are other values for applications and services but are kind of exotic and you won't usually need to change those.


There is one extra setting that is interesting to have in mind although it does not affect the authentication of a user.




SharePoint stores in the content database a token of the user that includes some claims like group memberships. This token needs to be refreshed from time to time to make features like "Check permissions" and other some security trimmed features work as expected.


These tokens will be refreshed at least every 24 hours. Some operations that require having a fresher token, like "Check permissions", will refresh the token at least every 60 minutes.


TokenTimeout will change the default 24 hours timeout to a greater or smaller amount. If the value is still greater than 60 minutes, some operations will still use 60 minutes as minimum.


$cs = [Microsoft.SharePoint.Administration.SPWebService]::ContentService

$cs.TokenTimeout = New-TimeSpan -Minutes 5


Comments (20)
  1. Pastasauce says:

    Fantastic article, clearly explained. thank you! :}

  2. Kyle says:

    This is by far the clearest article I have seen explaining SPSecurityTokenConfig values. Thank you!

  3. Richard says:


    Do you need a "iisreset" after these commands ?


  4. Mike says:


    Yes, No ?

  5. Richard, Mike, you usually don't need to do an iisreset after changing the configuration of the STS. However, depending on the authentication method you use, you may need to do something else to update the value you just changed, like clearing cookies on the client to get a new cookie with the new lifetime.

    Doing an iisreset will not affect the lifetime of the tokens in the Distributed Cache either, but you can force an update of the lifetime if you force the user to reauthenticate.

  6. Ian says:

    Hello there.

    You state the default is 10 hours above for the settings; do you mean this is what you are changing it to or that SP2013 is set to this value in a standard install

    How can I check what a server is set to now

    Users are complaining about their sessions being timed out in less than this amount of time forcing them to have to login again

    Thank you so very much for your help


    1. Phil says:

      Well its from February so hopefully its sorted by now but…

      Add-PSSnapin Microsoft.SharePoint.PowerShell
      $mysts = Get-SPSecurityTokenServiceConfig
      Write-Output “———————”
      Write-Output “Microsoft.SharePoint.Administration.SPWebService”
      $CS = [Microsoft.SharePoint.Administration.SPWebService]::ContentService;
      #TokenTimeout value before

    2. The default after a clean install is 10 hours. A part from timeouts you need to take into account also the size of you Distributed Logon token cache and/or the size of the worker process cache where logon tokens may also be stored. However, without more information about the authentication provider and your current settings, we’re just guessing here 🙂

  7. Jason says:

    Great Article , but i’m still struggling with the concepts..

    how to you go about making this config optimal?

    If i change the WindowsTokenLifetime and the FormsTokenLifetime token to a longer period ( 5days) so my employee’s only have to login once a week ?

    But set the Token-timeout to 15 minutes to accommodate for role changes or permissions changes i started getting “The context has expired and can no longer be used.” errors

    we’re using both NTLM and FBA Users with our own custom Provider , but essentially its a FBA SQLProvider Replica.

    @ian if you push out the variable

    $sts in powershell you will get all the values or alternatively $cs.TokenTimeout or$sts.WindowsTokenLifetime you will see the current value for that specific setting.

    Kind regards


    1. 15 minutes may be too short, specially if your users tend to leave things open in the browser.

  8. Richard says:

    Setting the ServiceTokenCacheExpirationWindow (SP2013) and the TokenLifetime (ADFS2.0), I was able to get a user session that expires after the difference. However, if a user logs into the SP site from a browser on Computer A, then logs into the same SP site from a browser on Computer B, it would appear that their user session on Computer A is extended to that of Computer B. Is this typical behavior?

  9. Thanks for Sharing, Nice and good explained 🙂

  10. Pritesh says:

    Very Helpful …

  11. Kevin says:

    I changed the WindowsTokenLifetime, FormsTokenLifetime, and LogonTokenCacheExpirationWindow settings yesterday and it resolved the issue of AD changes reflecting on Sharepoint quicker. I came in this morning and these settings were back to their default values. I am the only one with access. Has anyone heard of this happening and if so or not, why would they revert back?

    1. Sorry, I haven’t seen this issue before :/

  12. Bennnn says:


    We nested SP / AD groups in our implementation of SP2013. Because of this 10 hours window, some changes made on the AD groups are not reflected in SharePoint and therefore causing contradictory behaviors (Check permissions states some user do not have permissions though they effectively still have permissions…)

    Are there any con’s reducing the WindowsTokenLifetime to, let’s say, 2 hours? Knowing that it will be transparent to the user since we use Windows Authentication…

    Thanks for your insight,

    1. Just take into account that the number of connections from SharePoint to AD will increase to update the user information.

  13. Abhinav Agarwal says:

    Hi Jesus,

    We are facing an issue with Excel web app. When we are opening an Excel file in Excel web app, we are getting Session timeout issue after some time of inactivity of the user. For some times this error is coming after 1 hour but mostly this error is coming with in 15 Minutes.

    We have following settings for time out in our environment.

    $cs = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
    $cs.TokenTimeout = New-TimeSpan -Minutes 60
    $sts = Get-SPSecurityTokenServiceConfig
    $sts.WindowsTokenLifetime = New-TimeSpan -Minutes 2
    $sts.LogonTokenCacheExpirationWindow = New-TimeSpan -Minutes 1

    I am not sure what is happening but if these settings can be the cause of our issue.
    But none of our timeout settings are matching to 15 minutes of timeout as we are getting it timed out in 15 Minutes.

    We are using NTLM authentication in our environment.

    Can you please give some suggestions?
    Thank you!

    1. Hi, if you mean that the user gets a timeout message while viewing an Excel file within Excel Web App, it’s probably not related to any of these timeouts but to the configuration of Excel Services and the trusted location that matches the location of your document

  14. Hi Jesus,

    We are on SharePoint 2013 SP1 on-prem. SharePoint respects the the SAML token lifetime (set in the SAML relying party configuration) for web browser connections, and users are prompted to login again once the SAML token lifetime duration elapses.

    However, for connections from MS Office clients, SharePoint does not seem to be respecting the SAML token lifetime. Based on my investigation, MS Office clients use a separate FedAuth cookie from the web browser FedAuth cookie. And users are prompted to login again when using MS Office clients only when the FedAuth cookie expires (and not when the SAML token lifetime duration elapses, as I would expect).

    I think I can set the (Get-SPSecurityTokenServiceConfig).CookieLifetime value to the same value as the SAML Token lifetime to resolve the issue (longer than expected valid session duration) with MS Office clients. But I was curious if you had seen this behavior before or if you had any other thoughts on this.

    Thanks in advance,

Comments are closed.

Skip to main content