Skip to main content

Hello Developers,


I’m developing a Monday app with a custom object view.

This is the kind of app that can be selected in the left navigation, and the entire view is served by the app in an iframe.


I’m implementing the OAuth flow to obtain the access token which the app uses on the backend to call the Monday API.


The OAuth flow works in all desktop browsers except Safari.

Let me show you the redirect/page flows in a working case and in Safari’s case.


All desktop browsers except Safari




  1. Customer chooses the app in the left navigation

    https://custom-object-app.com/?sessionToken=SESSION_TOKEN redirects to /oauth/authorize (HTTP 302)




  2. Our app starts the OAuth flow

    Redirects to

    https://auth.monday.com/oauth/authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE (HTTP 302)




  3. Monday receives the OAuth request, and redirects to the Scope confirmation page

    Redirects to

    https://our-subdomain.monday.com/oauth2/authorize?oauth_payload_token=OAUTH_PAYLOAD_TOKEN (HTTP 302)




Now let me show what happens in desktop Safari.


Desktop Safari OAuth flow




  1. Custom chooses the app in the left navigation.

    Same as above in 1)




  2. Our app starts the OAuth flow

    Same as above in 2)




  3. Monday receives the OAuth request, and redirects to a Login page

    Redirects to

    https://auth.monday.com/login?force_existing_account=true&oauth_payload_token=OAUTH_PAYLOAD_TOKEN




Please notice the different Monday URL and the “force_existing_account” query parameter Monday appends to the URL of the last request.


How can the Safari flow be fixed?

Could you please help?


Thanks, cheers:

Csaba

Hello there @infinea and welcome to the community!


Would you be able to please fill this form so our team can take a look into this? Please add as much detail about your case as possible.


Looking forward to hearing from you via the form!


Cheers,

Matias

It would be great to have the answer added here when established.


Hello Matias,


I’ve submitted the form.


Thanks, cheers:

Csaba

Fantastic! Our team will take a look then @infinea!

What was the answer?

Hi @Matias.Monday


we also have this issue with Eledo when trying to get authorized in monday app for Mac, the auth endpoint redirects to login instead of our oauth endpoint.


I have found we can workaround this by setting up integration recipe or automation to get authorized.


Is there any solution for this? I can guess it is related to the token we use for the oauth flow, but we are just using the token provided by monday and we have no other token to use.


Thanks,

Lubos

We have this same issue and it is causing problems. When users try to authorize access to the API in the monday app, the auth endpoint redirects to login instead of our oauth endpoint. How can that be avoided?

We have also experienced the same problem. It was disappointing to find there is no answer posted here. I’m going to submit a Monday support request and see if I can get an answer that way.

Hi Csaba,


You’re hitting a common problem with Safari’s Intelligent Tracking Prevention (ITP). Safari is blocking or partitioning the third-party cookies that monday.com’s OAuth flow relies on within your iframe, causing the authentication process to fail and redirect to the login page. The force_existing_account=true parameter is monday.com’s way of trying to get the user to re-authenticate when it can’t find the necessary session.


Here are the most common solutions and things to check:




  1. Ensure Monday.com Domain is Not Treated as Third-Party:



    • For the OAuth flow within an iframe, ensure auth.monday.com and your monday.com subdomain (our-subdomain.monday.com) are not being blocked by Safari’s privacy settings.

    • Crucially: The user might need to have visited their our-subdomain.monday.com directly (not just via your app) and logged in once in Safari for their session to be established as a first-party context. This “user interaction” helps Safari trust the domain.




  2. Pass force_login=false (If Applicable/Supported):



    • While monday.com is adding force_existing_account=true, try if adding force_login=false to your initial auth.monday.com/oauth/authorize request helps. This tells monday.com not to force a login if a session might exist, which can sometimes work around ITP if a partial session is present. (Confirm if Monday’s OAuth supports this specific parameter).




  3. Prompt User to Open in New Tab/Window (Workaround):



    • If direct embedding proves too problematic, a common workaround for ITP is to open the OAuth flow in a new browser tab/window instead of within the iframe.

    • Your app would detect Safari, and instead of redirecting the iframe, it would trigger window.open(mondayAuthUrl, '_blank');

    • After successful authentication in the new tab, monday.com would redirect back to your REDIRECT_URI, where you can then close the pop-up and communicate back to the original iframe (e.g., using window.opener.postMessage). This is a more involved solution but very reliable for Safari.




  4. Check for Other Browser Extensions/Privacy Settings:



    • While less likely the root cause, ensure no aggressive ad blockers or privacy extensions in Safari are interfering with auth.monday.com or your custom-object-app.com domain.




Given the force_existing_account=true behavior, Safari is very likely preventing monday.com from accessing its own authentication cookies within the iframe’s context. The most robust solution is often to perform the OAuth dance in a new window/tab.

If you’re doing OAuth in an iframe as @ZakiImtiaz suggests, then that it a very bad idea. The user should be able to see the web address of your OAuth dance so that they can decide whether to trust your app. Or not.


Always do OAuth in the top frame. So if the starting point is an iframe, you should open a new window.

Reply


Terms & ConditionsCookie settings