Server-side access to Monday.com APIs to poll board data

hi @paulmarshall

Welcome to the community! Have you checked this one: OAuth and Permissions

OAuth 2.0 is a protocol that lets your app request authorization to read or modify data in a user’s monday account. Basically, at the end of the OAuth process, your app gets an access token that belongs to the user, and grants access to specified permission scopes.

I’ve been through this documentation. This workflow assumes a client app (ui based) that a user will log into and use directly (hence the OAuth 2.0 workflow). This means that the token is the “user’s token”. I am working on a server-side only service that will have no user-based login. As such the service itself will need access to a token without a user authenticating.

I don’t think that will fly. How is the app / user of the app authenticated in monday?

I think you have misunderstood. Its not actually an app that I want to write. I am attempting to create an external 3rd party standalone service that will poll the Monday APIs for data. Have you come across the concept of a client credentials grant before? Essentially the service would have its own credentials (in a manner of speaking) and authenticate on behalf of itself. This is not a novel workflow, its something that operates on many third party APIs.

Hello there @paulmarshall,

I am not sure I follow. You mentioned there are apps that are doing this.

What would be an example? Which app?

Is creating an app in monday a possibility? I believe it would make things easier for you.

Looking forward to hearing from you 🙂

Cheers,
Matias

Hi Matias. The workflow I am describing is quite a basic one:

I am creating a “server-side only” service which is just code running in azure. It calls the Monday.com GraphQL API and queries some data. It then persists that data to a database (no user interaction required for this, its automatic). This service is running as a .NET “Azure Service App” (a completely different thing to a Monday.com “app”).

I am not talking about creating an “app”, as it would appear that, from the Monday.com point of view, an “app” is something that has a UI that users can view, interact with etc. I don’t need a UI, or a front end or anything users click on or use.

My problem is that to make the call to the Monday GraphQL API requires an API token. I am currently using my own “Developer Token” as acquired from the “Developer” portion of my Monday.com profile. This is not particularly secure as this token is long lived.

I want to know if there is a way for the service itself to authenticate against the Monday APIs. This is a common practise within the industry. It does not require a user. I gave the example of a “client credential” workflow (though there are others).

I mentioned that I had registered an app within Monday. I only did this to see if this was a possible route of obtaining a token that did not require an actual user.

Hello @paulmarshall,

I understand.

It is not possible to do this without a monday app.

Having said that, you can create a monday app with NO FEATURES, NO UI AND NO BUTTONS AT ALL and use it to get an OAuth token.

1. Create an app.
2. Select the scopes in the OAuth tab
3. Save your app
4. Go to the versions tab and promote the version to live
5. Go to the “Share” tab and share the link for someone to install the app
6. The account installs the app
7. Go to the OAuth tab in your app’s configuration screen and enter the “Redirect URLs” tab
8. Copy the URL that says “Making OAuth Request”

Whenever someone (who has the app installed) uses that URL, they will see a scopes authorization screen from monday and when they authorize the scopes, you will receive a token you can then exchange for the OAuth token as explained here.

What do you think?

Thanks for the suggestion but I am afraid this won’t meet the required levels of either security or automation. I think we are going to need to proceed with the Developer API Token pathway based on what you have said and figure out a way to do this within the scope of our licensing. Thanks anyway

@anon29275264 I am afraid you seem to have missed the point. This service is completely external to Monday. It doesn’t use a Monday trigger or a Monday.com custom event. It runs as serverless code within Azure within a completely secure environment and will poll based on a cron expression.

It should not require installation by anyone or require a user’s access token to work. Like I said, at the moment I am using a “developer token”. I could, based on the Monday documentation also use an “admin token” and it works just fine. No app required. The problem is that since this token is static, its is not really very secure (as confirmed by our infosec dept.). This is why I was hoping that Monday implemented something more secure for third party integration (I gave the example of a client credentials grant which is a common security standard for API integrations). Since it appears that this is not possible, I am going ahead with the admin token workflow and seeking to mitigate the security concerns through other means.

I would like to start by stating that I am not in an “it must work this way” type of thinking. I am simply asking questions about accepted industry standard ways of implementing security of 3rd party API integrations.

Thank you for taking the time to outline this solution. It does look similar to what I am after, however, it relies upon Monday.coms implementation of WebHooks. I have done some work and a PoC with Monday’s Webhooks alrady and I discounted them as the webhooks themselves require preconfigured access to an endpoint or function within my secure environment but without themselves being authenticated. The only way I have been able to integrate a webhook with anything like a secure workflow is to use a function key. The problem with a function key is that it is itself a static value that makes it less secure.

I am proceeding down the route of using a Service Account for now.

Hi @paulmarshall

Thanks for reaching out! I wanted to update that we are aware of this gap and are working to improve the experience around server side application access.

At this time, although it is not ideal, my best recommendation would be to create a service user that is only used for the API and use that account’s personal token to run the application.

I hope that I can share more info regarding the solution and timeline soon.

Happy Programming

Any update here? This should not be considered an edge case scenario. This use case is called “Client Credentials” (OAuth 2.0 Client Credentials Grant Type).

Requiring a UI for OAuth does not support a backend integration flow because it would introduce unnecessary complexity and dependencies on user interaction, which are not applicable in backend environments. Instead, using OAuth’s client credentials flow ensures secure authentication for backend integrations without the need for a UI or user interaction.

Hello there @david.kershaw,

We do not have an update on this but we will reply here if that changes 😀

Cheers,
Matias

HI Team, Do we have any latest update on OAuth Client Credentials support for Monday?

We have a requirement where we need a service account for pulling all the data across monday entities.

–Sai.

Hello there @sairamaraju,

What do you need to do exactly?

we are looking for a Super user token which can retrieve all entities of Monday.com across workspaces and boards/docs.

Is this possible to create a super admin user API token which can pull everything? We tried with admin account API token , but not able to get all the entities.

Thanks,
Sai.

Hello again @sairamaraju,

The only way for you to do that would be to create a user (or use an existing one) and give that user access to everything. And if new private workspaces/boards, etc. appear, that user should be invited to them as well. There is no way to create a “super user” that will always have access to all data in the account.