Monday.com External Api authentication

Firstly, there is actually a primary section called “monday apps & developers” dedicated to this kind of topic (the one you’ve found, is end users discussing apps and integrations, within platform discussions). monday Apps & Developers - monday Community Forum

monday.com does not integrate directly with any third-party API. Thats what your app will do. When you create an integration feature, you set an “authentication URL” that is for the monday.com OAuth process - at the most basic you redirect your request back to the monday.com authentication page to accept scopes, which then returns the user to your server to complete the process.

It is that final step where you can simply request an OAuth token from the monday.com server and redirect back to the monday.com URL provided to complete recipe creation - OR in your case get the OAuth token and then redirect the user to the authentication pages required for the third party service and collect the API token for that service.

You’ll now have the tokens (which you will want to of course encrypt and store securely). So all of that will likely be another lambda from the one which handles your actual app functionality.

Then your lambda that handles the actions (triggered by column changes) will receive a JWT that tells you the account, app, user, etc. that created the recipe, you can use that to look up the OAuth tokens required (both monday.com and the third-party service(s)). With that you then integrate the two together in your lambda. The JWT contains a short lived token (1 minute) so that may suffice for any simple changes you need to make. You could in theory in the Authentication process skip getting a monday.com OAuth token and rather direct the user directly to the third-party OAuth process.

But it is the OAuth process in monday that affords you the opportunity to redirect to the external authentication process. (All of this is driven by your code, except the initial call by monday to your OAuth process.) The OAuth process is triggered when a recipe is installed. You can of course check for existing tokens and immediately redirect them to finish creating the recipe if everything is already authenticated.

Having done this before, I’d recommend a couple things - use API Gateway (HTTP API) to handle routing your requests to the correct lambda. Ideally create a custom domain there, so that you can create multiple APIs and they share a domain. The only downside is that you cut your timeout for completing a request without queuing to 29 seconds from the default 60 seconds monday provides. That said, that should be enough for most operations. Without the API Gateway though, every action block or trigger is going to be a different function URL and get really ugly to keep straight unless you put cloudfront in front of everything - or build a monolith in a lambda which is usually considered an anti-pattern. I’ve found the Serverless framework or AWS CDK to make this rather easy to implement where there are separate APIs for the install webhooks, oauth process, and then then each app integration feature. Then each path in route in those apis is a separate lambda (unless there is a very specific overlap).

Hi Cody, can you provide some guidance here? I am able to get my 3rd party’s API Key through OAuth, I am wondering what is the best and most secure way to store this API Key so that it can be accessed and used every time my integration recipe is fired?

thank you for your help

While I cannot advise specific technologies since I don’t know what languages, databases, or environments you’re running in - general guidance is that you need to encrypt the token in your code when you get it, then you can store it in a database. Decrypt it after you retrieve it. The encryption/decryption should be happening on your server, this isn’t simple database encryption where its encrypting data on disk but decrypting the data when you query it.

The main consideration is that you don’t have the ability to access the keys to decrypt it, nor do any users. Only the server has the ability to access the keys and use them (and not stored in code!).

If you were to query the database what you’d get back is encrypted data, and no way for you to decrypt it - even if you tried.

Make sure you don’t log tokens anywhere of course!