OAuth 2.1 is now open for all monday developers

Hey ​@YanivRidel,

A token migration endpoint would be very useful!

Just to confirm though, in the migration guide it states:

Refresh and access tokens have a maximum lifetime of 6 months from the original authorization. Once this limit is reached, the refresh token expires permanently and cannot be used to obtain new access tokens - even if you have been actively refreshing it. At that point, the user must go through the full OAuth flow again to re-authorize your app.

So every 6 months, whether the app is used regularly or not, the user needs to re-authorise the application?
Or does it mean that the refresh token expires after 6 months, so as long as we refresh the access token at least every 6 months, the newly provided refresh token will last for another 6 months after the latest refresh date?

hi ​@YanivRidel ,

yes, a migration endpoint would be useful. 

two things:

- could you please clarify what will happen to existing tokens once we activate the new flow? will they still work until the 1st of october? i think we'd need some sort of transition period where we can guide the users to do the re-authentication while the old tokens still work. otherwise, everything will suddenly stop working for every user once we enable the new flow.

- the expiry of the refresh token after 6 months will cause us big headaches. it means we'll have to bombard the users with "your token will soon expire" kind of emails. a lot of them will probably ignore these emails, so our app will suddenly stop working for them, and then they'll send us panic support requests. could this maybe be reconsidered?

- Simon

​

Hey guys, thanks for the questsions.
Feel free to ask them also in the community: https://mondaymarketp.slack.com/archives/C0BGFCC0YTH

Thanks for the feedback on the migration endpoint - noted, we'll take it into account.

Regarding the questions:

 ​@mitchell.hudson, the maximum lifetime of pair of tokens (access token + refresh) is 6months per authorization flow.

Meaning, you do the oauth flow, you get access token for 1day and refresh token for 3months.

Everytime you refresh, the tokens extends their expiry date accordingly, but the absolute expiry is always capped at 6 months from the original authorization date - refreshing does not reset that clock.

After 6 months, the users will have to re-authorize.

​@xatxat , we are right now in the transition period.

Both new oauth tokens and old tokens live together now, and work.

On 1st of October, the old tokens will stop work. It gives you enough time to do the change.

For the second question, sadly this cannot be changed currently, due to security requierments.

If a token will be provided, with unlimited refresh, the token will actually live forever, and we cannot accpet it.

Any modern system, asks you to re-authorize your session once in a while.

If I understand right, this will considerably degrade the experience for our users, who rely on background operation of our app:

1. When we do this migration, all existing tokens will break, so all of our users will have their background data operations halt.
2. Thereafter, users will all have their background data operations halt every six months or so until they find their way back into the application to reauthorize.
3. We will of course attempt to ameliorate this with email notifications, but over the last few years, email notifications barely work - busy people are inundated and mostly don't see them. Instead, they probably won't notice until their business is affected.

​@YanivRidel Thanks for shipping OAuth 2.1. Rotation and PKCE are the right direction and we're on board with them.

I do want to push back on one specific decision: the 6-month absolute maximum lifetime, where the refresh token expires permanently and forces a full re-authorization even when the app has been actively refreshing it. I'd ask the team to reconsider this before it becomes load-bearing.

Two reasons.

1. It isn't required by OAuth 2.1. The spec's actual mandate for refresh tokens is sender-constraining or rotation, both of which you're already doing. Neither OAuth 2.1 nor RFC 9700 prescribes an absolute lifetime ceiling; where they address expiry at all, it's inactivity-based and left to the server's discretion. So this is a monday policy choice, not a compliance necessity, which means it can be changed without weakening compliance at all. And since marketplace apps are confidential clients (client_id + secret, server-side), even the rotation requirement is stricter than the spec strictly demands for our client type.
2. It's stricter than the rest of the ecosystem and it costs everyone. Google (verified/production), Okta, and GitHub all use inactivity models, where tokens persist as long as they're actually used. monday's own current behavior (valid until uninstall) is the same spirit. Moving to a hard 6-month wall means every actively-used connection, the healthy ones, breaks on a fixed timer. For apps where a user connects once and expects background sync to keep working, that translates directly into silent failures, re-auth friction, support tickets, and churn. It penalizes precisely the integrations that behave well.

Concrete ask: keep rotation and sender-constraining as-is, but replace the 6-month absolute lifetime with an inactivity window of 3 months or less. A token that hasn't been refreshed in 6 months expiring is completely reasonable and meets the BCP intent (a leaked token can't live forever). A token that's been refreshed every hour for 6 months being force-killed is not.

Would appreciate the team's thoughts on whether the inactivity model is on the table.

Thank you for the response.

I would absolutely second Bas’s points above. Forcing customers to re-authorise every 6 months provides a poor user experience and adds unnecessary friction if they are actively using the access tokens.

I second Bas’s point and proposal as well. Please reconsider. Thanks!

Hey ​@YanivRidel,

+1 to Bas's proposal — an inactivity-based window (3 months or less) meets the security intent without breaking apps that are actively refreshing tokens. A flat 6-month wall punishes the well-behaved integrations.

Also strongly in favor of a migration endpoint — with ~2.5 months to the cutoff, bulk-converting existing tokens would save a lot of pain. (Also non bulk, just an endpoint we can run per token)

One question that affects our timing: if we migrate users now and you later revise the expiration policy, will that apply retroactively to already-issued refresh tokens, or only new ones? If not retroactive, we'd rather wait for the final policy than make users re-authenticate twice.

Any rough timeline on this decision?

Thanks!

In return I am echo-ing ​@ram_perel suggestion to provide a migration endpoint.

We would use a migration endpoint, though as mentioned, our app would provide a much better user experience if able to operate under an app identity with an app level token instead of acting as whichever user installs / configures it.

I second ​@baswienhoven‘s point.

Our apps run crucial background activity, and we rely on the oauth token being valid indefinitely.

If after 6 months, each user has to re-auth, it would lead to significant downtime and issues in the user’s workflow whichever user is using the app.

I request you to please reconsider this decision, as this would basically break the entire workflow of our app that relies entirely on the OAuth token being valid across multiple users and boards.

​@YanivRidel