As I understand it correctly on Service Desk API for Developers | Freshservice freshworks provides an API which uses some sort of API key.
But after testing it in Postman I see that the API is only using Basic Authentication as a security.
This means if someone knows our URL he can then iterate through API keys and always use a random password as this is not required. This seems to be insecure…
When will FreshWorks implement more secure API Authentication with OAuth 2.0 or/and bearer tokens?
Thanks for reaching out to our community. Yes, As you mentioned we support Basic Authentication for our APIs. However, we use a strong API key generation mechanism that cannot be guessed by an attacker. Also in the case of an API key, we do not expect a password to be filled, Simple “X” as a password should be sufficient.
“API Key” plays a crucial role in this authentication type.
Thanks for your answer.
The strong API key as you mentioned is hard to guess but not impossible.
Also it consists only from a single factor.
OAuth 2.0 would be the next logical solution for this.
Also there are for example 50 agents in our company. Each of them can have a API key generated.
There is no central control on who and where the API keys has used or when they expire.
This leaves us a huge dark black box on what key is used for what and by whom.
I would rather have centrally created API keys with an expiry date (1 year) which then can be used by 3rd party applications. Because now all the API actions are running under an agents name and therefore this name appears on for example each modified asset.
@Matthias I have to agree that the maintaining of API Keys should be available to those who use those keys. The issue of agent name appearing where the key is used made us have to pay for an additional agent license and name it “Help Desk” so that when it was invoked in workflow to add notes (for example) it would show that it was added via “Help Desk” and not just any agent who’s key we plugged into the webhook. Not the most elegant solution and can be costly too. +1 on finding a better solution if possible Take care!
Take care!