I've been helping a customer get to the bottom of token timeouts, sessions timeouts etc.
The two best links I've found are:
AD FS Single Sign-On Settings
Active Directory Federation Services (#ADFS) Single Sign On (SSO) and token lifetime settings
and a few lines in:
AD FS Frequently Asked Questions (FAQ)
that are:
"How long are ADFS tokens valid?
Often this question means ‘how long do users get single sign on (SSO) without having to enter new credentials, and how can I as an admin control that?’ This behavior, and the configuration settings that control it, are described in the article here.
The default lifetimes of the various cookies and tokens are listed below (as well as the parameters that govern the lifetimes):
Registered Devices
PRT and SSO cookies: 90 days maximum, governed by PSSOLifeTimeMins. (Provided device is used at least every 14 days, which is controlled by DeviceUsageWindow)
Refresh token: calculated based on the above to provide consistent behavior
access_token: 1 hour by default, based on the relying party
id_token: same as access token
Un-registered Devices
SSO cookies: 8 hours by default, governed by SSOLifetimeMins. When Keep Me Signed in (KMSI) is enabled, default is 24 hours and configurable via KMSILifetimeMins.
Refresh token: 8 hours by default. 24 hours with KMSI enabled
access_token: 1 hour by default, based on the relying party
id_token: same as access token"
And here we see the first problem - there is a major distinction between registered and unregistered (aka non registered) devices and most of the documentation is for the former.
A registered device is a device that has been provisioned via EMS / Intune. You could add domain-joined here. This allows a user to BYOD and still have access to a company's intranet.
So if you have a customer with a B2C type of scenario where their users have a wide range of devices and never need to access the company intranet, you start to see some problems.
The first issue is that of persistent cookies.
Set-AdfsProperties –EnablePersistentSso
These are not enabled for unregistered devices. You can turn them on with the KMSI (Keep Me Signed In) option.
Set-AdfsProperties -EnableKmsi $true
What you now see in a PC browser is:
The defaults have changed from 8 hours to 24 as above.
However, on some mobile devices, the onload.js has a:
style="display:none"
which means that it does not display and you are back to square one.
This may be because there is a:
"&prompt=login"
in the query string,
So assuming KMSI is on, you have:
access token = id-token = 1 hour
SSO cookie = refresh token = 24 hours
To change the default:
Set-AdfsProperties – KmsiLifetimeMins int32
and if KMSI is off:
access token = id-token = 1 hour
SSO cookie = refresh token = 8 hours
To change the default:
Set-AdfsProperties –SsoLifetime int32
Also note that there is a KMSI "user component" (which adds the box) and a KMSI "ADFS feature" (that changes the timeout values).
You don't want the refresh token to time out because that would force the user to re-authenticate.
So you can use the "authorize" endpoint to get a brand new set of tokens. Because the SSO cookie has not yet expired, ADFS will simply mint a new set without any login requirement.
The tokens are "brand new" e.g the id-token will be valid for another hour.
By a "new set", I mean an access token, a refresh token and an id-token.
You get the same behaviour if you call the refresh endpoint.
However, I noticed that although the value of the refresh token is different, it has the same
"refresh_token_expires_in": 72186
value (adjusted by the time it took to do the refresh itself).
So the new refresh token inherits the old "time to timeout".
Enjoy!
