Public Wordpress Plugin: oAuth risks


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_id and 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 client_secret and client_id securely

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:

  1. 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.

  2. 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 client_id and client_secret

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.

We are going to be releasing 2 new authentication methods probably this quarter. Personal Access Tokens (PAT) and Service Access Tokens (SAT). These will be behave very much like the legacy API keys. Hopefully we will be getting details about this out in the near future.

1 Like

Thank you, bradb! That’s fantastic news and I am looking forward to the announcement.

@bradb do you have any updates on the new authentication methods? You mentioned you would probably release them in Q1 of 2021, but now it’s almost thee end of the year and I haven’t seen an announcement.

Hey Kim,

We officially have released the PATs and SAKs feature! Here is some additional information around the new authorization as well as v2 endpoints now available.

Additional information is available here
Postman collection is available here
Documentation around currently available v2 endpoints can be found here.