I would like to create a wordpress plugin that connects to the Infusionsoft API. But I am having issues figuring out how to authenticate securely, since the plugin code will be available in the wordpress directory.
Option 1: Embed my
client_secret in the WP code
This is the easiest option, but it seems extremely risky, since anyone would be able to authenticate any Infusionsoft app and tie that connection to my developer account.
If they do something mischievous with them I have the risk that my developer account gets banned.
If my developer account gets banned, then all my plugin users’ API connections will stop working and that would lead to data loss.
This is not just a huge risk for me, but a huge risk for every single user.
Option 2: Create a proxy server that handles
The second option is to make my wordpress plugin communicate with a proxy app that stores the client_id and client_secret on my server and simply returns the access and refresh token to the WP app for further use.
This was suggested in a few other threads here on the forum.
This is a little better, but opens up two problems:
They still have access to API tokens tied to my developer accounts
Even though they don’t have the client_secret or client_id, they still have access to the tokens that are tied to my developer account. It’s still a huge risk for me and my users.
I now have access to the tokens and access to their Infusionsoft data
Even though my users would self-host the plugin, they would essentially expose all the content of their Infusionsoft app to me. This is a big risk for them and a huge responsibility for me.
In this case it’s simply a level of access that I, as the developer, don’t need and users shouldn’t have to give to me.
Option 3: I ask the users to create their own developer accounts and use their own
This is the most secure option for everyone involved…
- I don’t have access to my plugin users’ API tokens and Infusionsoft app
- My users API usage is not tied to my developer account
But it’s a usability nightmare. Having to ask non-technical users to create developer accounts and juggle several keys is going to make adoption a lot more difficult.
Option 4: Stick with the legacy SDK and API keys
My final option would be to stick with the old SDK and continue using legacy API keys.
This option is simple and secure for everyone involved.
But the risk here is that the SDK is not being developed anymore and may in the future stop working with newer PHP versions.
Infusionsoft may also decide to kill off that authentication method completely in the future.
Am I missing something?
Am I overestimating the risks here? Or am I missing something?
I have read many other issues here and Infusionsoft developers have dismissed API keys as unnecessary, but clearly there is a need for it.
Wordpress is the most popular web platform and not having an API authentication scheme that works with it is unreasonable for your users and frankly damaging to Infusionsoft.
I noticed that there are countless WP plugins that integrate Mailchimp, Active Campaign and other marketing software, but very, very few that integrate with Infusionsoft. And I haven’t seen a single plugin that used oAuth. They all used the legacy API keys.
I think this may be one of the reasons for this.