Hello. I am trying to do a system-level integration with InfusionSoft via the API. In this case, I don’t have any logged in user - the initiation of this flow is actually from an IS campaign, which does a post to my external service. My service then generates some data, which I want to put back into a contact record. Unfortunately, from what I can read, it does not appear that the IS API supports this flow, and the example code that I see linked on this site is frankly ancient. I’ve also watch this video: Using OAuth2 and Infusionsoft API/REST - YouTube, but it just talks about the authentication code flow.
We only support the Authorization Code flow right now, but all you need to do is get an access token once and you can perpetually refresh it. It is common for people to use Postman for this. You can also generate one under API Access in Account Central if you have your client_id and client_secret. A caveat is the refresh token is single use, and you will be issued a new refresh token every time. You will need to manage the access/refresh token pair.
I understand the suggested solution, but I would also add to the request for better support for server-to-server authorization, such as the client credentials OAuth flow. Persisting tokens in applications that don’t persist state (e.x. running in Kubernetes) is not as convenient as using client credentials to retrieve tokens on application startup.
it may not be ‘as convenient’, but more convenient always equals less secure. This is brought up a lot but it hasn’t (and shouldn’t) change for security reasons, especially for those that are looking to be GDPR, PCI DSS and/or HIPPA compliant (which obviously there are many people that those things have to matter to). For that reason, the policies cannot change, otherwise those compliances go out the window.
All due respect, but that’s simply not true. There is nothing inherently insecure in the OAuth2 client credential flow. It is widely used across the industry in all sorts of scenarios. It is designed specifically for this type of use case - when I want access to my resources without having to impersonate a user. For Example, Auth0 specifically talks about supporting this, and they certainly claim to be GDPR, PCI, and HIPPA compliant. I have not personally researched the accuracy of that claim, but given they are one of major identity provider players in the marketplace, I would tend to accept that claim. To not support client credentials flow means you are intentionally only supporting integrations which required an end user with credentials. That is certainly InfusionSoft’s right - it is your api, after all - to claim that he other OAuth2 flows are less secure is simply wrong.
The issue is OAuth tokens are scoped not only to the client but also the tenant it is accessing. We currently don’t have a reliable way to tie a client to a tenant. They are different systems. Just because you have a developer account doesn’t mean you have a Keap account and vice versa. You could also have access to more than one tenant. So there isn’t even a way to know which tenant you want to access. We have played with ways to solve this in then past but didn’t like any of them. This was mostly due to our old API Proxy provider Mashery. We switched to Apigee at the beginning of 2020 and we have new capabilities. We actually will be releasing Personal Access Tokens (scoped to specific user and tenant) and Service Access Tokens (scoped to a specific tenant with Admin access) shortly. These tokens (really OAuth client_ids and client_secrets) will be generated from within the tenant so we have all the metadata required.
2 Likes
This makes sense to me. But, what doesn’t make sense is that Postman request using API (key/secret) to /app/oauth/authorize returns a login form that wants me to authenticate via email/password. Isn’t that the point of the API key?
If this is correct, how do I then get past that step to generate the token within postam to move past this step… I’ve been stumped for a couple hours…
Actually that’s the first leg which is the authorization step. Once someone logs in on that screen an auth token is returned. This is often mis-understood to be and access token but with oauth, that’s not the case. The auth token says that the user has given you permission to request the access/refresh token pair. You use the auth token to request access/refresh tokens at …/token. I’ll drop my video on this process and it should help to step you through the process better 
1 Like
Figured it out.