OAuth example in React / Visual Studio Code

Hi!
I’m Moshik and I’m working on the integration apps feature at monday.com.
We’ve recently had a remote hackathon where developers from all over the world used our apps infrastructure for the first time.
During the hackathon we’ve had a short talk where we explained on how to implement OAuth as part of integration apps.
This is a link to a video which explains the functionality: Moshik Eilon's Personal Meeting Room - Zoom
And here’s a repository with a simple server to server example usage of the monday.com OAuth functionality in general: https://github.com/yuhgto/monday-oauth-example

Let us know if you need any more information 🙂

Moshik Eilon,
monday.com R&D

Hi @moshik,

Thank you, it helped me to get on the correct path. I do understand how to configure the app with the callback and where / how to implement this is the code. The missing piece is how to get the access token (knowing the accountId and userId) that can be used for all monday GraphQL queries and how to store this (probably in a cookie?).

Many thanks,

As a best practice, we recommend implementing a database in your app to store the tokens.

I don’t believe storing the key as a cookie would work because the integration feature will ping your app from the backend – in this context, your app won’t have access to the user’s browser cookies because it will be responding to an event coming from the monday server.

@moshik – anything to add here?

Sounds like a plan 🙂. My initial thoughts are:

• Create an endpoint (e.g. /authorization), which is used in the integration feature
• This gives me accountid / userid and backtourl
• Check db for token for accountid / userid
• If token exists in DB use it and redirect to backtourl
• If not found redirect to monday oauth (clientid / state) with a callback
• In callback check state and if same create token and store in DB and redirect to backtourl

When the endpoint (/authorization) needs to redirect to oauth, do I need to set the scope form code or is this done based on the scope of the app?

Anything to add?

Hi @dipro, @moshik

That makes sense, I will store the tokens in a database. Got this partly working now. I do get the access token (do not store it yet) and the flow is looking good. When user adds the integration to the board he gets the messages that the app needs access and when approved I do get the access token.

Before doing the next step (store the token in a database) I want to understand what the lifetime of the access token is. When making the request I got the access token, but the refresh token is returned as null. So basically my question is: can I use the access token forever?

My second question is: is the access token bound to a specific board? If the user wants to use the same integration app on another board, can I rely on the stored token or should I send the user to another authorization session?

Many thanks for the help so far.

Omg thank you! I have been searching for something like this.

Hi @basdebruin @moshik @dipro

I have a question relating to oauth flow when setting up integrations.

my read of the documentation is that this authorization / token handshake is supposed to take place when a user sets up an integration on a board in the account. The advice seems to be to get a token once for each (integration recipe, board) tuple and use it forever.

Is my understanding correct? If so, does it not mean that, if a recipe is triggered by another user on the same board (not the user who set up the integration), the external app will receive a JWT which will contain the user id (i.e. the user whose action triggered the recipe) but will have to use the first user’s token (the user who configured the integration and associated it to the board) to make any API calls. This could potentially introduce an asymmetry (i.e. the user triggering the action may not have the same access rights than those included in the API token which will be used).

This is not creating an immediate issue for any of my use cases, but i am just trying to ascertain whether I am understanding the situation correctly when it comes to providing monday API tokens to our external apps that are linking up to monday via integrations.

Thanks

hi @jaacquees

“The advice seems to be to get a token once for each (integration recipe, board) tuple and use it forever…” There is nor reason to request a token for the same recipe on another board. I store my tokens with an accountId + userId key.

“If so, does it not mean that, if a recipe is triggered by another user on the same board (not the user who set up the integration)…” if a recipe is triggerd by an action from another user the trigger action still runs under the credentials of the user who sets up the integration. That is: if you use that token in your action.

Does that answer your question?

Hi @basdebruin
on the first paragraph -> I agree and it makes sense. If you have a user setting up an integration on a second board, after having done it on one board already, there is no need for another token.

on the second paragraph -> thanks for confirming my understanding. The action will be performed with the privileges of the user who “installed” the integration on the board, not the user whose action triggers the recipe. It is good to keep in mind.

Thanks for the swift and detailed response as ever!

Following up on this question. I am trying to pass to my server-side app the ID of the user whose action triggers the column change. I am querying the user ID based on the JWT sent with the trigger --> I get the user ID of the user who set up the automation. I also tried using the ‘Context’ argument “userId” but this also returns the ID of the user who set up the automation.

Is there a way to do what I am trying to do?

hi @jaacquees
I don’t think you have access to the user that initiates the automation through the API. That’s also why the acitivity logs always shows the user who inserted the integration on the board.

Thanks @basdebruin. That is a shame. I am trying to send notifications to the user responsible for the triggering (to inform them if there are any validity issues with the data they are updating).

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.