Solution to access token timeouts SharePoint 2019 & Azure AD identity provider

Jacques398839883988 96 Reputation points
2021-01-14T21:35:09.183+00:00

Hi all,

i have recently migrated a SP2013 solution to SharePoint 2019 and implemented Azure AD as a Trusted Identity Token issuer using AzureCP as claim provider, migrating windows users to claim equivalents. Our users experience that they have to re-authenticate more frequently because of expiring access tokens. Before it was possible to configure access token lifetimes using app bound policies in Azure AD, but as i understood this is being replaced by Conditional Access - Sign-in frequency and access tokens will be set to a default of 60 minutes expiration as of January 30th. If i'm not able to extend the access token lifetimes, sadly i might have to revert back to using Windows Authentication.

I am trying to find a way to implement ADAL or MSAL to improve user experience, ideally silently acquiring access tokens based on the logged-in users' token. I am not sure if this is possible, since i don't interfere in the default authentication process. Instead I'm trying to acquire a token using the claims at hand, but if i understand correctly the claims principal i can access is not the actual Azure AD principal but one that's already processed by SharePoint. Just using the AcquireTokenSilentAsync method from the ADAL libraries, results in a token cache error (Failed to acquire token silently as no token was found in the cache. Call method AcquireToken). Probably because i don't initiate the authentication and don't have any Token Cache, but maybe also because i don't know what UserIdentifier i should use to acquire the token. I only have a UPN and NameId claim available which seem issued by the security token service of SharePoint.

I am thinking of customizing the authentication process, so that i can override the initial authentication process and manually redirect the user to microsoftonline, trying to catch the initial token and initializing a token cache item. I have no clue if this is even possible..

Can anyone point me in the right direction or is there an easier way to extend access token lifetimes from SharePoint context knowing that adjusting accesstokenlifetimes in AzureAD is not an option? Am I bound to ADAL because SharePoint Server can only handle SAML tokens or is MSAL with Integrated Windows Authentication a better option ?

Thanks!

SharePoint Server Development
SharePoint Server Development
SharePoint Server: A family of Microsoft on-premises document management and storage systems.Development: The process of researching, productizing, and refining new or existing technologies.
1,597 questions
Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
20,629 questions
0 comments No comments
{count} votes

Accepted answer
  1. Jacques398839883988 96 Reputation points
    2021-01-15T19:33:03.137+00:00

    okay... i feel pretty stupid...

    roadmap.svg

    When i try to run this command:

    $policy = New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"02:00:00","MaxAgeSessionSingleFactor":"02:00:00"}}') -DisplayName "WebPolicyScenario" -IsOrganizationDefault $false -Type "TokenLifetimePolicy"

    it results in:

    New-AzureADPolicy : Error occurred while executing NewPolicy
    Code: Request_BadRequest
    Message: Configure Token Lifetime for RT/ST (Refresh/Session Token) has been retired on May 30, 2020. New policy cannot
    be created anymore.

    Which lead me to believe that adjusting AccessTokenLifetime was also being retired. I had seen that above picture many times, and didn't understand why it said "no changes" to AccessTokenLifetimes.

    But this still works fine:
    $policy = New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"02:00:00"}}') -DisplayName "WebPolicyScenario" -IsOrganizationDefault $false -Type "TokenLifetimePolicy"

    Not yet able to verify if this solves my problem, but i think it will.


2 additional answers

Sort by: Most helpful
  1. Baker Kong-MSFT 3,801 Reputation points
    2021-01-15T03:07:36.117+00:00

    Hi @Jacques398839883988 ,

    Per the doc suggestion, you may need to turn to sign-in frequency in Conditional Access. For more details, please refer to

    Best Regards,
    Baker Kong


    If an Answer is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    0 comments No comments

  2. Jacques398839883988 96 Reputation points
    2021-01-15T07:27:55.547+00:00

    hi Baker,

    thanks for your reply.

    Sign-in frequency requires end-users to be redirected to Azure AD on a regular basis:

    "The sign-in frequency setting works with SAML applications as well, as long as they do not drop their own cookies and are redirected back to Azure AD for authentication on regular basis."

    I want to configure how regular this is, or automate this for users. Now, using sign-in frequency, our users are redirected to the SharePoint login page every ~60 minutes because Azure AD expires its accesstokens. In our case, we use FBA and Azure AD to login to SharePoint, and a custom login-page that lets users choose between these two. When the accesstoken expires, Azure AD users log out of SharePoint and are redirected back to the login page. Then they click the Azure AD sign-in link, and are being redirected back to SharePoint without having to sign-in again (Sign-in frequency works as expected). but again with an accesstokenlifetime of 60 minutes.

    As you will understand, suddenly being logged out of SharePoint while trying to save a form, losing your input, is not desirable. May be my only option is to show the users that their session is about to expire using javascript, but ideally i would like to silently acquire a new token for the logged in user, respecting their sign-in frequency. Do you know if and how that's possible?

    0 comments No comments