Recipe automation authorization

Hello there @ThisIsIgrek and welcome to the community!

I hope you like it here 💪

To create a screen where you can ask for credentials, you can use the Authorization URL. It will not look exactly like the screenshots you sent, but it is the feature you need to ask for credentials for integration features 😀

Cheers,
Matias

Hi @Matias.Monday,

I want to see is if I understand this correctly:
I read about credentials field in the integrations’ docs, and there they require 3 URLs, for getting, setting and deleting.
I still miss the part of what should I code in order to have the ability of asking the user for his 3rd party API token, for example.
If I just use the Authorization URL (in the credentials field) then the user will be redirected to a UI which will be asking him/her for this input?

Thanks,
Eyal

credentials URL is a URL where you respond with a list of already saved credentials - this way if they’ve already added one, they can reuse it.

authorization URL will take them to a page of your choice where you can take them through whatever process you need, providing the API token for the service, oauth for the service, whatever method is needed. At the end you redirect them back to the back_to_url that was in the JWT sent with the initial request. This authorization URL is essentially the same as the existing authorization URL on an integration feature except its only called when a user clicks the option to add a new credential in the credentials field. You need to create these pages and serve them from your backend. There is no native functionality here from monday - beside making the initial call to the URL.

delete URL - does what you’d expect, sends you details to delete an existing credential from the list you return in the credentials URL.

Thanks @anon29275264 for taking the time and explain.
So basically, from reading this it looks like that credentials URL and delete URL are only needed in the multiple credentials use-case, in order to have the ability to choose from different credentials.

And in the other hand, if an integration only requires single authorization per an account (i.e. 1-to-1 relation), it only needs to have authorization URL.

Thanks for clarifying the process of providing extra authentication options for the integrated service.

Well, there is another consideration.

The redirect to the back-to-url with the authorization URL is SLOW. Like 10-20 seconds. If you use the authorization URL (standalone) then EVERY time a user configures a recipe, it will call the URL only for you to immediately redirect them (since you have already gotten a credential). This means a 10-20 second lag for the user every single time.

Using the credential field instead, even if you only need one credential, the call to look up existing credentials (credential URL) should take <1s. The user may have to reselect the credential each time, but there isn’t a long redirect delay involved (except the first time.)

This is the benefit of the credential field (which has a manually invoked authorization URL) and the “authorization URL” at the feature level which is invoked every time a recipe or action is configured from a feature.

It all depends on your app and how you expect people to use it. How often and how many recipes need to be configured?

@anon29275264 I only anticipating the users will be configuring the recipes when adding the recipe in the automations.

I’m also wondering if any security consideration on my backend serving the tokens retrieval (that you mentioned it’s my app responsibility) needs to be taken? I saw your general advice in this post reply - I understand the storing consideration, is there anything else that I should be aware of when building a simple form for pasting an API key (for the 3rd party integration I’m building)?

Well, the main question is how many times will they be adding recipe to boards? just to one board one or two times? Or possibly to dozens of boards?

Monday.com includes “secure storage” which is a feature you can access from the front end or a back end running in monday-code. If you have the option, that is what I would recommend using at this time for storage.

As far as other considerations, I would say “adhere to industry best practices” is the best advice I can give. I know its kind of meaningless but I can’t really make specific recommendations beyond that.