@TomScott, you and your team need to have a discussion to work out how to resolve these onging OAuth issues.
You mention that the Legacy API Key has many failings. You do realize that your development team made the original API key mechanism and you can easily fix all those problems. As far as I know the API Key was introduced in 2006, and it was not until 2014 (8 years later) that the OAuth Authorization was introduced. Now its 2018, it means the Legacy API Key has been in use for 12 years, and OAuth for 4 years.
The solution to most of the Legacy API Key issues that you reported can be resolved if you gave clients the ability to create Multiple API Keys. If a client generate a new API Key they can give it to the developer, or use it in a particular piece of software. If they needed more, they can go back to their account and repeat again. If they neeed to deauthorize the API Key, they could just delete that key. In regards to the other issues, that is something you can resolve, but I do not see how its been an issue after all these years.
If you have issues, you do not let it carry on for years and years, and then try to introduce something new to think it would resolve things. Actually you guys have gone from one set of issues (which can be resolved), to another set of issues with OAuth (which you cannot easily resolve now you use a 3rd party service).
In regards to OAuth, you guys think its perfect, reliable and easier to use. Sorry, but I disagree with that. Using OAuth makes things more complicated to develop and less reliable as well. I can understand from your point of view you wand to increase security, but did it have to take 8 years to come to that point? If it was an issue, it should have been resolved a long time ago before 1000s of API scripts have been developed.
I need to point out that using the Legacy API Key works in ALL Software Enviroments, be that being a Web Script, Desktop Application, Wordpress Plugin, Spreadsheet Macros, etc. But using OAuth generally requires the use of a Web Browser to authorise the connection, unless you go down the manual route. OAuth adds more complexity because you have to deal with the Tokens, which generally require a Cron Job to keep refreshing the Access Token. There is developers who make Desktop Applications and Wordpress Plugins, they would have to resort to developing Proxy Servers to deal with the Tokens. As you see those sort of complications do not help things, and can actually limit creativity.
You do realise that OAuth is a framework and not a protocol. Quoted from the Wiki: “Because OAuth 2.0 is more of a framework than a defined protocol, one OAuth 2.0 implementation is less likely to be naturally interoperable with another OAuth 2.0 implementation. Further deployment profiling and specification is required for any interoperability.”.
Unfortunately this had lead to companies creating dozens of variations of OAuth which range from the Good, the Bad and the Ugly. I have seen other OAuth implementations that have an Access Token that last forever, or 12 months, or 2 weeks. But usually the SDK has been designed to deal with refreshing the token. Unfortunately Infusionsoft SDK does none of that, and the devleoper has to deal with it.
As Igor pointed out, what happens when you have a Race Condition occuring, which can happen. What happens if the server went offline or was rebooted when the Cron Job was meant to run to refresh the Access Token. Then the script will stop working and would require to be re-authorised again. How would clients feel if that occured on a Friday night, and no one was able to fix it until after the weekend? In comparison to using the Legacy API Key that scenario would not be an issue.
In regards to moving forward, please explain why does the New Infusionsoft Interface still support the Legacy API Key? If you were moving forward, then that section would have been removed when the new interface was introduced.