Share via

Frequently Asked Questions about Modern Authentication in Office 2013

  • Article

How do Single Sign-On experiences work between applications with Modern Authentication?

Prior to the updated Authentication features, Office provides users with Single Sign-On between applications. What this means is that after a user signs into Word, that account is available in Excel, PowerPoint, etc.  However, accounts added to Outlook are not immediately available to the other Office Applications (or the other way around).  This is still the expected behavior with the updated Authentication features. 

How long are access and refresh tokens valid while using Modern Authentication?

When a user successfully authenticates with Office 365 (Azure AD), they are issued both an Access Token and a Refresh Token. 

The Access Token is very short-lived (valid for around 1 hour). 

The Refresh Token is longer-lived - in some cases the token may be valid for up to 90 days if:

  1. It is frequently used
  2. The user hasn't changed their password

The Access token is what is used to actually gain access to Resources such as Exchange or SharePoint Online.  When the Access token expires, the Office client will present the Refresh token to Azure AD and request a new Access Token to use with the resource.   The default lifetime for a Refresh Token is 14 days (expires 14 days after issue if not "used").  Features such as Conditional Access Policies may force users to sign-in again even though the Refresh Token is still valid.  Once the Refresh token expires, users will need to sign-in again.  If your company has been configured for Single Sign-On (SSO) through Federation, you may not need to explicitly do anything (SSO will just work!). 

 

Changing logical (IP address) or physical locations after the Refresh Token has been acquired by the Office client will not impact the validity of the token.  For example, if a user is on the corporate network during business hours and performs authentication, they will be issued both Access and Refresh tokens.  When the user leaves the office and travels to an off-site location (no longer on the corporate network), their refresh token will still be valid even though the geo-location (as determined by IP address) for the user's machine has changed.  The validity of Refresh tokens are not re-evaluated until the Refresh Token expires.  Some other events, such as a managed user changing their password, will also cause their refresh token to be invalidated.  Federated user password changes do not result in this behavior.

 

Similarly, if a user has successfully authenticated, and then the user's administrator enables them for Multi-Factor Authentication, the user will not need to perform Multi-Factor Authentication on that device (Refresh Tokens are "per-device") until the refresh token is invalid.  The next time the user is forced to authenticate, they will be required to configure Multi-Factor Authentication if not previously configured, then perform MFA to be successfully issued their Access and Refresh Tokens.

What is the expected experience while using Alternate Login IDs with modern authentication?

Alternate Login ID is a feature of Azure AD that allows certain customers (that are synchronizing their directories with Office 365) to use a different value than their on-prem UPN.  Documentation on configuring Alternate Login IDs may be found here: http://social.technet.microsoft.com/wiki/contents/articles/24096.dirsync-using-alternate-login-ids-with-azure-active-directory.aspx. 

If you have configured Alternate Login IDs prior to participating in the Public Preview Program, you may encounter issues in 2 scenarios:

  1. Federated customers that have configured Alternate Login IDs and have on-premises UserPrincipalNames that are using non-routable domains will not be able to perform silent single sign-on in certain cases.  This is because silent single sign-on is dependent on a process called Home Realm Discovery.  Home Realm Discovery is a process that leverages the user's UserPrincipalName domain to identify the correct authentication endpoint for the user.  Home Realm Discovery will not work correctly for Federated Customers that have configured Alternate Login IDs as the discovery will be based off of the user's on-premises UserPrincipalName domain (which is not publically routable, therefore not resolvable via public DNS infrastructure).  In this case, the user will be prompted to enter their email address, and once inputted, should be signed-in in most cases without additional input.
  2. It breaks AutoDiscover for some users in companies with Exchange Hybrid Deployments: Federated customers that have configured their company for Exchange Hybrid Deployments will not be able to use the Alternate Login ID feature as this interferes with the Autodiscover protocol.