Question:
Is it possible to have a standalone service (externally hosted app or serverless function) authenticate itself to obtain an API token (I am used to using client-credentials workflows for this in other contexts).
Context:
I am developing an Azure hosted app service that will poll data from a specific set of company boards. This app is written in .Net 6. So far I have successfully completed a PoC but the token I am using is my own personal developer token. I am aware that I can also, with correct permissions, use an admin API token but this seems somewhat insecure to use as a long term solution (even while using the likes of key vault to store it).
I was hoping that it would be possible to register a new app and use the client id and secret to obtain a token for the app itself but I am unable to find any documentation to this effect (leading me to believe that maybe it is not possible). Is anyone able to confirm this for me please or perhaps steer me in the right direction for achieving my aim?
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 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.
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.
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.
Create an app.
Select the scopes in the OAuth tab
Save your app
Go to the versions tab and promote the version to live
Go to the “Share” tab and share the link for someone to install the app
The account installs the app
Go to the OAuth tab in your app’s configuration screen and enter the “Redirect URLs” tab
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.
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
@codyfrisch 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.
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.
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.
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.
