Public Preview: Token Protection for Sign-In Sessions

[Guest paulgarn]

At the recent Microsoft Secure event, we announced a new feature called Token Protection for sign-in sessions. This is the first in a series of Microsoft Entra features designed to combat token theft and replay attacks.

 

 

 

As you may know, attacks involving token theft are becoming more frequent. To address this, we at Microsoft are making comprehensive investments to allow you to use Azure AD Conditional Access to better protect your critical resources.

 

 

 

Our solutions aim to provide better security characteristics than previous approaches to combat token theft. This includes resistance to malware attacks on user devices that steal tokens and malicious insider activity. Additionally, our solutions provide fine-grained control over policy enforcement using Conditional Access.

 

 

 

Token Protection ensures that tokens can only be used on the intended device. When enforced through Conditional Access policies, tokens authorizing access to resources must come from the device where the user originally signed in. This provides the best available protection for your high-value users and data against breaches involving token theft.

 

 

 

The first preview of this feature allows you to protect Office 365 resources such as Exchange mailboxes and SharePoint sites from illegitimate access using stolen Windows native client Refresh Tokens. We’re targeting Refresh Tokens for protection first as they tend to be longer-lived and more broadly scoped than other types of tokens and are therefore more valuable for an attacker to steal. Future releases will extend this protection to more applications and data, other client platforms, and other types of tokens.

 

 

 

I'll give you a brief overview of how you can enable this.

 

 

 

Conditional Access enforcement of token protection for sign-in sessions (preview)

 

 

 

 

 

 

 

By selecting “Require token protection for sign-in sessions” under Conditional Access Session Controls, sessions used to access resources defined in the scope of the policy will be required to be bound to the device the user signed in to using proof-of-possession. Proof-of-possession requires that the client can show it has access to a private key on the device. If access is attempted using a Refresh Token stolen from a user’s device and moved to a device an attacker controls, the proof-of-possession can’t be accomplished, and access will be blocked by the policy.

 

 

 

Here are some configuration notes specifically for this initial preview: Supported resources are Exchange and SharePoint. Support for Teams is coming soon, and other services will be added soon.

 

 

 

Registered Windows 10 or 11 devices and currently only native desktop applications are supported. To avoid blocking legitimate access from web apps and other client platforms: under the Conditions, Device platforms tab, you should select just ‘Windows’, and under the Conditions, Client apps tab, you should select Mobile clients and desktop apps only, leaving ‘browser’ unselected.

 

 

 

 

 

 

 

 

 

 

 

As with other policies, you should scope it to specific users or groups, and ensure you have specific accounts excluded to ensure there is always management access to your tenant. Please read the documentation carefully before planning to deploy an enforcement policy. For legitimate access, the policy requires that users have compliant OS and app versions that can perform the proof-of-possession steps. We highly recommend using Conditional Access report-only mode to evaluate the impact of the policy in your environment before turning it on. Also, please remember that protecting tokens using proof-of-possession should be regarded as one part of a Zero Trust defense-in-depth strategy, which should include device management and compliance, and the use of cloud-based phishing-resistant authentication.

 

 

 

Upcoming releases on the Token Protection roadmap include:

 

 

 

• More resources and access scenarios.
  
• The addition of web applications to improve defense-in-depth capabilities for web applications using MSAL.js.
  
• Sign-in session token protection to address refresh token theft scenarios on Mac, iOS, Android, and Linux clients.
  
• App session token protection, which limits theft and replay of access tokens.
  

 

 

 

We’re looking forward to sharing more about these. Look out for future blog posts for details.

 

 

 

 

 

Learn more about Microsoft identity:

 

• Get to know Microsoft Entra – a comprehensive identity and access product family
  
• Return to the Microsoft Entra (Azure AD) blog home 
  
• Join the conversation on Twitter and LinkedIn
  
• Share product suggestions on the Entra (Azure AD) forum
  

 

Continue reading...