About changing lifetime of refresh token

Question

About changing lifetime of refresh token

Phu Le 40

Dear Microsoft Advertising API team,

I read the below article

You can't configure the lifetime of a refresh token. You can't reduce or lengthen their lifetime. Configure sign-in frequency in Conditional Access to define the time periods before a user is required to sign in again. https://learn.microsoft.com/EN-US/azure/active-directory/develop/refresh-tokens#token-timeouts

and executed following steps

Go to my registered application
Security > Conditional Access, create a policy
In create new policy screen, section 「Session」, tick checkbox 「Sign-in frequency」and set-up Periodic reauthentication (1 hour)
Authenticate my application througth Microsoft ads account to get refresh token
Waiting for more than 1 hour with in-active refresh token
Use refresh token to create access token

Expected: get error that refresh token is expired

Actual: call request successfully→refresh token is still active

May I lack of any configuration ?

Thanks & Best regards

Phu

Accepted answer

1 additional answer

Your answer

Answer 1

Akshay-MSFT 17,951 Microsoft Employee Moderator

@Phu Le

Thank you for your response. As per your policy screenshot you have opted for Sign in frequency- periodic reauthentication- after every on-hour, which means the user session will be revoked after an hour.

User's image

As per Refresh and session token lifetime policy properties

After the retirement of refresh and session token configuration on January 30, 2021, Azure AD will only honor the default values described below. If you decide not to use Conditional Access to manage sign-in frequency, your refresh and session tokens will be set to the default configuration on that date and you'll no longer be able to change their lifetimes.

Refresh Token max inactive time is 90 days, if the user session continues it would renew without impacting the session but not when session controls are applied.

User's image

Please do let me know if you have any further queries in the comments section.

Thanks,

Akshay Kaushik

Please "Accept the answer" (Yes/No), and share your feedback if the suggestion works as per your business need. This will help us and others in the community as well.

Phu Le 40 Reputation points

2023-03-01T18:48:17.46+00:00

@Akshay-MSFT

Thank you for your response

Let me summarize my situation

I create my own application in Azure Active Directory > App registrations

Then I created a conditional access policy about Sign-in frequency (Periodic reauthentication 1 hour) applied to my application

After that I used OAuth 2.0 authorization code flow to get the initial access and refresh token

With above policy setting, I imagine that my refresh token will be invalidated after 1 hour but it was still validated.

Please help to confirm that my understanding about that policy is wrong or I did config some thing lack

Thanks & Best regards

Phu
Phu Le 40 Reputation points

2023-03-02T05:57:44.0233333+00:00

Dear @Akshay-MSFT

Thank you for your response.

Firstly, I registered my own application from Azure Active Directory > App registrations. After that I created new conditional access policy by setting Session- Sign-in frequency Periodic reauthentication 1 hour

Then use OAuth 2.0 authorization code flow to get pair of refresh token and access token to access data of my customer

With above policy setting, I understand that my refresh token will be invalidated after 1 hour. Is it right?

But actual my refresh token still validated. May I understand wrong about Sign-in frequency policy or lack of any config.

Thanks & Best Regards,

Phu
Akshay-MSFT 17,951 Reputation points Microsoft Employee Moderator

2023-03-03T05:50:59.95+00:00
@Phu Le ,

This is because the token you have requested token via AuthCodeGrant via lets say a service principal and it is valid for default time, but the application you would be using has a session token (cookies) of 1 hour (in control of IDP). Expiring either of refresh or session token will ask the user to reauthenticate.

As per https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/users-revoke-access#session-tokens-cookies :

When a user opens a browser and authenticates to an application via Azure AD, the user receives two session tokens. One from Azure AD and another from the application.

The authorization policies of Azure AD are reevaluated as often as the application sends the user back to Azure AD. Reevaluation usually happens silently, though the frequency depends on how the application is configured. It's possible that the app may never send the user back to Azure AD as long as the session token is valid.

Thanks,

Akshay Kaushik

Please do let me know if you have any further queries.

Answer 2

Andy David - MVP 157.4K MVP Volunteer Moderator

Hi, not every app honors the policy. so that could be your issue

https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-session#sign-in-frequency

User's image

Phu Le 40 Reputation points

2023-02-28T12:39:36.3+00:00
Dear @Andy David - MVP

Thank you for your reply quickly.

I have registered own application as below guide link

https://learn.microsoft.com/en-us/advertising/guides/authentication-oauth-register?view=bingads-13

You mean that own applications is not honor to 「Sign-in frequency」policy

How does my own application config or register charged service to honor this policy?

Incase cannot use 「Sign-in frequency」policy, the default lifetime of refresh token is 90 days as described in below link

https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes#refresh-and-session-token-lifetime-policy-properties

Please help me to confirm which ones is correct

refresh token will be expired after 90 days

refresh token will be expired after consecutive 90 days in in-active state ( mean that if use refresh token everyday, it will not be expired)

Thanks & Best regards

Phu

Share via

About changing lifetime of refresh token

1 additional answer

Your answer