Sign-In Frequencies in Azure AD:
You might have seen on Azure Active Directory a new feature called Sign-In Frequency. In this post we are taking a closer look at this feature. First, we need to understand how authentication works and which tokens we are receiving. When you sign-in to an application which is dependent on Azure Active Directory, you need to sign-in to Azure AD in the first place. That is where your first token (might) come from. In the case of Federated logins (if you use Okta, ADFS, other) your first authentication token will come from that system.
Next, when a user opens an application, the user is forwarded to AAD and AAD issues an application based token and a redirect back to the application where the user can use the token to indicate successful authentication, and possibly also some other attributes which the application requires.
Once the application receives the application token, the token has a start and an end date/time. It is ultimately up to the application to adhere to those times, but let’s say, all the developers in the world are perfect and indeed your application wants a new token for the user, once his/her token lifetime has expired. In an oAuth token, this lifetime is shown in a “linux” time format as we can see below:
The yellow marked entries are those time stamps. You can convert them to UTC time using a simple converter such as on: https://www.unixtimestamp.com/index.php
In SAML, there is another field in the token that is based on the NotOnorAfter attribute, but it uses the same principle.
Session Timeout versus IdleTimeout
When a token expires, ideally the application requests a new token from Azure AD to continue working in the session. This is where AAD can influence the way it issues a new token as the user is being redirected from the application back to AAD for validation. The thing to remember here is that AAD has no way to validate how the token is being used and even more if the token is being used or if the application itself is being used. In short, AAD cannot determine if the user is actively using the application or not.
As a result of the above, IdleTimeout cannot be implemented on Azure AD side. Period. An Idle-Timeout must come from the application itself, and if a timeout is detected, the application can invalidate the existing token (although it’s lifetime may still be valid) and redirect the user back to AAD. In case a new authentication has to happen, the application can send the user back to AAD with a particular parameter in the URL that forces re-authentication for that application only. (in SAML: ForceAuthN=True & for oAuth see: https://hajekj.net/2017/03/06/forcing-reauthentication-with-azure-ad/)
But what we can do is, ensure that the token AAD sends to the application only has a specific lifetime, so we ensure (if the application adheres to all the standards) that the user is sent back to AAD frequently so if needed, we can apply the re-auth rule ourselves. This is called Sign-In Frequency within Azure AD. Note that it does not matter if the user actually used the application or not. If the session timer is up, he/she needs to put their credentials in again (and MFA if required):
Scenario’s
So when would you use this? There are multiple. From a very secure application to shared terminals or the use of internet cafés. Given the implementation is actually through a Conditional Access Policy, we can add a lot of conditions to it, for example:
- The session-timeout only occurs on machines from a specific IP address (shared terminals)
- The session-timeout only applies for browser-based applications, not mobile applications
- The session-timeout only applies to certain users, applications or devices
- The session-timeout does not occur on managed devices (or certain locations)
- etc
So how to configure this?
As indicated, its part of the Conditional Access policies. Meaning you need at least Azure AD Premium 1 licenses for it to work.
I’ve created a new policy, for a specific user and in there I configured the following:
- Specific user: <selected users>
- Applications: All Cloud Apps Included
- Condition – Client Apps: Browser only
- Sign-In Frequency: 1 hour
Now, I can login to my myapps.microsoft.com and do whatever I need to do there. But after working for 1 hours (+5 minutes – as 5 minutes is the deviation factor for tokens), I am redirected back to my login screen.
The reason I removed the Mobile Apps and Desktop Clients, is that I don’t want to over-use the renewal tokens on devices that users usually personally use. Like their home computer for example, obviously I’d recommend using only Intune Managed Devices (and base all policies on that), but sometimes that’s just not doable.
The results
The result is that a user can login and open any application they have access to. But, when clicking an application that falls under the session-timeout policy, the token lifetime of that application will be reduced to the lifetime specified in the session-timeout (+ 5 minutes). Once the user has used the application for 1:05 hours, they will be redirected back to Azure AD and will see the login screen.
Now, if the user had multiple applications (that fall under the session-timeout) open, they only need to authenticate once to regain access to all the applications.
(PS. While the official documentation (https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime) shows support for oAuth or OIDC protocols, it actually works on the custom F5 deployment I wrote about in an earlier blog).