When a Mimecast client application successfully authenticates with Mimecast for the first time, the Mimecast service creates a token. Once the token has been issued, Mimecast uses this token to validate that all requests are from a specific client application, and therefore the token itself serves as the authentication method. Each token is valid for a period of time before it expires, at which time the application must re-authenticate and obtain a new token.
The list of Mimecast applications that respect tokens include the latest generation Mimecast for Outlook, Mimecast for Mac and Mimecast Mobile.
Using tokens results in a significant performance gain, greater stability, and more consistency during a Continuity Event. Some of these benefits are detailed below:
|Decreased Authentication Overhead||Certain authentication methods create significant overhead, and take time to complete. For example, Integrated Windows Authentication (IWA) can take several seconds to negotiate a successful login. The user experience of running a search and browsing through a number of results would be frustrating if each request for data had the overhead of the authentication negotiation. Using tokens results in these heavyweight authentication methods only being performed occasionally, and therefore significantly improves the user experience. Once authenticated, all subsequent calls utilize the authentication token for client validation|
|Decreased Network Traffic||Utilizing authentication tokens dramatically reduces traffic to the customer’s infrastructure, allowing a smaller number of authentication resources to scale to a large number of users|
|Fewer Connectivity issues||Authentication tokens ensure that connectivity issues, such as request timeouts or server downtime, do not interfere with the user’s ability to use of the application|
|Improved Continuity experience||During a mail server outage scenario, it is possible that either the Active Directory or EWS server (if using IWA) will also be unavailable. Service disruption to end users can be seamless as long as the user has a valid token at the time of the outage. During a Continuity event, the life of the token is automatically extended until the Continuity event is over. As a result, users who have valid sessions established can continue to work without the need for cloud passwords|
Token Cache Timeout
Administrators can set how long tokens are stored for, which determines how often an end user must be re-authenticated. This is configured in an Authentication Profile, and the default life for a token is set to 3 days.
To ensure that relevant end user applications do not have to authenticate every time they get used Mimecast uses an authentication time-to-live (TTL). Please select the appropriate value for your business. Note: this option is not available when more secure authentication methods are being enforced such as "2-Step Authentication" or "Enforce SAML Authentication for End User Applications".
The longer the token cache timeout is set, the longer the user has access to Mimecast via the application without explicitly authenticating.
Authentication tokens are secured in a number of ways. This ensures they cannot be shared or maliciously used by anyone, besides the person who was originally authorized to use it. While the tokens cannot provide a mechanism for non-authenticated users to gain access, they do afford an authorized user to gain access until the token expires.
Administrators will be familiar with preventing users gaining access to the application by disabling their access. However with authentication tokens even if a user’s account is disabled, the time to live of the token does not immediately disable access via the app. Administrators should therefore be aware of this delay in account lockout, and disable the user's account in the Mimecast Administration Console as well.