Refresh token not returned for Office365 accounts purchased through GoDaddy

Question

Background

We have a feature that syncs calendar entries and contacts between our application and Office365, using the Office365 REST apis outlined here. We are using Version 1 of the API. For authorization we are performing authorization via Azure AD as outline here.

Problem

In the normal case (when using Office365 accounts purchased directly from Microsoft), our system works as expected: we are able to refresh the user's tokens when they expire and are returned a new access and refresh token in exchange.

In the second case, when testing with Office365 accounts purchased via GoDaddy, we encounter a blocking issue that can be outlined in this series of steps: 1. User is sent from our app -> Office365 Login page. 2. User enters email address 3. User is redirected to GoDaddy Office365 login page. 4. User completes authorization, and is redirected back to our app with an access code in the response. 5. App exchanges access code for an access_token and refresh_token from Office365. 6. Some time goes by, and access_token expires 7. App refreshes the user's access_token using the refresh_token

Expected Behaviour

At this point we are expecting to receive a new access_token as well as a new refresh_token, as we do when using a regular Office365 account

Actual Behaviour

Only for accounts purchased via GoDaddy, we do not receive a new refresh token in the response after refreshing for the first time.

Obviously when intending to have a long-running sync, this is a breaking case as the user will no longer be able to have their tokens refreshed beyond this point.

Postman traces (can save as .json and import to Postman for debugging https://gist.github.com/drunkel/7ec66ed33f66d0070148694651699d03 (IDs and secrets have been removed)

Question:

• Is this a known issue?
• Is there a workaround?

Bullen

Is there a detail error message shows why don't receive a new refresh token in the response after refreshing for the first time. or just get the access token but no refresh token returned after refreshing ? – Impecunious

@NanYu-MSFT There is no message, only the normal response without any refresh token. A 'bad' response will look like this: gist.github.com/drunkel/bf9fd7c8b9f69c5a03b0eb364a629262 – Bullen

+100 for a fix for this please GoDaddy. – Tokenism

I'm not familiar with GoDaddy's Office365 setup, but how come the user is redirected from Office 365 to GoDaddy Office 365? Are they signing in twice to Office 365? If so, could it be that the 'refresh_token' received initially is for the first sign in, but a second sign in invalidates it? Or vice versa, where the 'refresh_token' is for the secondary sign in, but the Office 365 Auth only recognises the first? – Atahualpa

Hey there, this is an interesting question that I would like to look into more. @Bullen can you try and grab a correlation_id from the request when you exchange the refresh token for new tokens? You can find this by using a network tracing tool like fiddler. – Cointreau

@DanielDobalian the only header that looks like what you're talking about is: x-ms-request-id →12a84a47-3ab6-4358-8bc8-eb54c48a0c00. Is this correct? – Bullen

Answer 1

I am a Software Engineer at GoDaddy and can confirm that this issue has been resolved. The reason for more frequent login requests under Modern Authentication is that as these are federated users and as you mentioned in your question, the refresh token was not being returned. This was caused by the StsRefreshTokensValidFrom attribute on the AAD user not being updated properly.

Deflate

Answer 2

Every provider can decide how to implement its own oAuth server with certain policies on how to act with certain grant type and policies about granting/revoking refresh tokens/id tokens/access token and their lifetime properties.

This is a known issue with go daddy when purchasing office 365 accounts. see here and also here and here.

So it seems like GoDaddy decided to implement their OAuth server with a restricted security policy about refresh tokens by not enabling and not sending back a refresh token to the API calling the OAuth authentication and authorization when you purchase office 365 accounts through GoDaddy.

This is security enhancement/block to disable your application not to hold a lifetime refresh token that can be lived forever (if refreshed) to these office 365 accounts purchased on Godaddy

Usually, OAuth servers implemented with integration with Azure Active directory have the following token lifetime (but you can change and decide to override configure them differently 3rd party implement their own server with their own policies about tokens)

Another important featurw which Go Daddy does not support multi-factor authentication(mfa) for office 365 accounts found here.

1. Azure lifetime policies: Azure Active Directory Configurable token lifetime properties

2. Another important issue is that if you want to be able to continue to refresh the token while the user is offline you must ask the user for access_type="offline", so during a time of inactivity from the user, you can continue to refresh the token and to hold long lifetime token for the account.

3. If the user decides to revoke the token for any reason - the token immediately expires.

Another issue in the steps you described is:

1. User is sent from our app -> Office365 Login page.
2. User enters email address
3. The user is redirected to GoDaddy Office365 login page. so now the refresh token for office 365 flow from server to the hands of Godday servers.
4. User completes authorization and is redirected back to our app with an access code in the response. (but without the refresh token obtained the in the last server to server step. Godaddy to keep security on behalf of 365 accounts keeps it to itself and not returning it to the end user.
5. The app exchanges access code for an access_token and refresh_token from Office365. 6. Some time goes by, and access_token expires 7. App refreshes the user's access_token using the refresh_token

Recaption