Authentication from custom Mobile App/ 3rd party app

  • 19 May 2023
  • 2 replies
  • 69 views

Badge

Hi,

I do not know why FreshService team decided to remove basic authentiation, using username & password and propose solution to use API Key since I believe they are not interchangable.

I have difficulties when my customer wants to develop a custom mobile app for agent, integrated with Freshservice system. However, without authentication using username & password, user will need to input api key (obtained from their account in Freshservice webpage) to be able to login to system. The API Key is not designed for user to input to Password text field because it is generated by system under a certain complexity policy.   

Product team please consider option to keep authentication method using Username/ Password.

Thanks

 Trung.Le


2 replies

Userlevel 6
Badge +11

Hi,

I do not know why FreshService team decided to remove basic authentiation, using username & password and propose solution to use API Key since I believe they are not interchangable.

I have difficulties when my customer wants to develop a custom mobile app for agent, integrated with Freshservice system. However, without authentication using username & password, user will need to input api key (obtained from their account in Freshservice webpage) to be able to login to system. The API Key is not designed for user to input to Password text field because it is generated by system under a certain complexity policy.   

Product team please consider option to keep authentication method using Username/ Password.

Thanks

 Trung.Le

 

Basic authentication has its roots in accessing internet resources, where easy access for users is paramount. Usernames and passwords are stored in the Web header field in plain text with base64 encoding, using SSL to encrypt the headers and ensure user credentials are kept secure. The problem is that even when more secure HTTPS is used, basic authentication has several drawbacks and vulnerabilities.

  • Authentication headers can be seen for each access request, which makes it much easier for a bad actor to capture those user credentials. 
  • Passwords are usually cached right in the browser, which introduces another vulnerable access vector. 
  • Basic authentication isn’t able to limit grades of access permission, so one point of access to an application potentially opens up multiple avenues to all the data a user has access to. Users should have access only to the data needed for a particular function, nothing more. 
  • Fundamentally, usernames and passwords are an antiquated and inadequate method of protecting vital data and information. 

Source: https://www.simplilearn.com/modern-authentication-vs-basic-authentication-article

 

Most services are switching to Modern authentication due to Security concerns, and Freshworks should not stay behind. From a security point of view, this was a smart decision.

You may check other examples:

https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online

 

This other article explains in great detail these changes and impact:

https://www.apps4rent.com/blog/modern-authentication-vs-basic-authentication/

 

Hope this helps to clarify on why FW also took this decision.

 

 

Regards,

Badge

Hi,

Thanks for your clarification.

As my experience, most of systems now support issuing JWT Token or Access/ Refresh token mechanism to access API after first authentication (using username & password). 

I think FW should notice customer and leave the decision to customer rather than remove the mechanism. System engineers will aware of the risk and the business needs then they will decide to use suitable and secure mechanism.

Regards,

Trung.Le

Reply