When trying to secure our applications and its data, we cannot interact with the session itself. It’s potentially a big security issue, that no one has managed to solve.
Today’s enterprises consume an increasing amount of modern applications. These applications are built on web technologies rather than proprietary protocols and custom-built user-facing clients. With this trend comes the possibility of centralizing the act of authentication and authorization providing control for IT departments and a Single-Sign-On experience for end-users.
This is all good and helps secure your applications. With a centralized point for access decisions, you can focus your investments and have a very strong solution gatekeeping your applications as a result.
Application Backend Controls the Tokens
But there’s a gap with this approach that I’ve been thinking about for some time. I’ve searched for a good and universal solution but haven’t found one.
Once a user has been authenticated and authorized by the central system, the user is handed over to the application. Now, the application knows that the user is authorized and can grant access to the application and its data. For the application to keep track of the requests and sessions, the user and client will be passed an access token by the application back-end. The access token makes sure client requests, passed to the application, are valid and the session is kept secure.
The problem is that these access tokens tend to have a fairly long time to live (TTL) – ranging from an hour, a full working day, a week, a quarter or in worse case indefinite. The access token creates a relationship between the client/end-user and application backend. The centralized authentication and authorization system are not involved, and can’t control the session.
Let’s say the user behavior or the client’s posture dramatically changes, dictating that access should no longer be allowed. Not until the access token has expired, the centralized point of access can interact with the access request and deny it. There is today no universal method of intercepting and terminating a session.
Looking at the market, there are methods and solutions trying to solve this. But so far none are truly universal, offer acceptable user experience, or can be applied to protect all of your different kinds of applications – not only the modern ones. Here’s a brief list of different solutions, and their shortcomings, as I see it:
Lower The Access Tokens Time To Live
The first obvious method would be to lower the time to live of the access tokens. For this to work, the application backend needs to support it, and if you force a reauthentication too frequently, your users will not be pleased. Even if you offer a seamless and zero-touch method of authentication, the users’ session will be interrupted and the user experience will suffer.
Revoke The Tokens
Another alternative could be to revoke existing tokens via APIs. This way the centralized point of access can, when noticing a change in the user and client trust level, send commands to the application back-end, revoking the access tokens. This will force a new authentication flow and thereby bring the central system into the loop.
The main problem with this approach is that it doesn’t scale very well. Very few applications support this API integration today, and if they do, it is hard to maintain non-standardized API integrations with many different applications and vendors.
In-line Proxy
Google, with its BeyondCorp, has a most competent identity-aware application proxy capable of intercepting and terminating existing sessions. This is possible since the proxy is in the line of communication. But this only supports modern applications that can be proxied via this component. And as far as I know, the solution is only available for applications in Google’s cloud.
Microsoft Office 365/Azure AD offers conditional access that can interact with the session every time the access token is renewed using the refresh token. This allows for a seamless access validation much more frequent than a typical solution, often as frequent as every hour. The problem is, this is only valid for Microsoft applications. Again, not a universal solution.
Cloud Access Security Brokers (CASB) have the capabilities to interact with an existing session since they are often in the line of communication. But as the name indicates, CASBs are only suitable for modern SaaS-based applications. I’ve yet to see a CASB capable of controlling legacy applications, often hosted on-premises.
Device Management
Your Unified Endpoint Management system can identify changes in device posture and, depending on policies, wipe individual applications, your corporate area or the whole device. However, this doesn’t necessarily close an existing session; nor, does the complete uninstallation of all applications categorically wipe all access tokens. It also requires the device to be under some kind of management, which makes Bring Your Own Device (BYOD) scenarios hard to support.
Routing Traffic
Forcing all traffic to flow via something like a VPN-Tunnel allows for greater control. At any point in time, you can decide to terminate the tunnel. Another benefit is that it can support pretty much any application. The downside is routing all traffic through a fixed component, often hosted on-premises, which doesn’t resonate very well with the whole SaaS access model. VPN also requires some locally installed components on the device.
User Prompt
Some applications ask the user if they want to keep the session, after a certain period of inactivity. While not entirely a security validation method, anyone in front of the client can click the button to keep the session; it still helps with allowing for a lower time to live while not forcing the user that is active to reauthenticate.
Blocking Access to the Device
Continuous authentication is something that is being researched and looked at by many vendors. Since these solutions are supposed to be able to interact with the application access immediately upon a change of behavior, it faces the problem with long-lived access tokens like few others.
I’ve seen solutions that basically locks the device the user is using. While effective, it is not impacting individual applications, but rather the whole machine. This makes it not very suitable for BYOD scenarios. Secondly, it is hard to achieve universal support, including all possible client devices, since it requires a locally installed component.
No Universal Solution in Sight
Considering the above, I claim that today, we as an industry, have no good answer to this problem.
I’m a strong believer in Zero Trust, a modern security architecture trying to make use of much more data – specifically dynamic data – before making an access decision, as an answer to the rapidly growing security requirements. While implementing a Zero Trust architecture today provides higher security than a traditional perimeter-based model, it won’t really shine until it can interact with established sessions, for all applications and any device.
With this post, I hope someone will enlighten me about a solution that takes care of this. If that fails, I would like the industry to step up and start to discuss this and invest in finding a solution. Perhaps establishing a consortium, specifying standardized ways of inserting a proxy in the flow of communications or API methods to revoke access tokens would be some initial steps to kick off the discovery around a better solution.
Final Thoughts
In the meantime, what can you do? I would say you will have to use a mixed approach. Make use of what is there, such as the conditional access for O365. While not helping with all your apps, it can certainly help with the Microsoft ones. If you can use CASBs, that would help in some circumstances.
What often can be done – and with minimal investments – is to lower the time to live of access tokens. Make sure you are not allowing ridiculously long TTLs like 90 days. Having a time to live of 8–9 hours is often acceptable by users. Especially if you are offering a seamless and zero-touch method of Single-Sign On.
With that, I thank you for taking the time to read this blog post. I hope you, as much as I, find this topic interesting. The more people who think about it the more likely we’ll come up with a good and universal solution.
Peter Björk, Senior Staff EUC Architect, EUC Technical Marketing
Peter specializes in Identity and Access Management, and is a speaker at events like VMworld, VMUG and vFORUM. He’s also an author of two books as well as numerous white papers and blog posts. When the work day is over, he volunteers as a Scout leader for the local Sea Scout troop outside Stockholm, Sweden. Twitter: @thepeb
