Long-lived token support

API Q&A
5

@Igor_Rinkovec and @Pav, there is a lot of stuff in this post, and I will try and address most of it. I want to first say we are all on the same team. We understand some of the frustration. We are trying to address some of these issues, and some will not be addressed. No one on our team has claimed that our implementation is perfect. The are always trade offs. Usually the two levers are security and convenience. In our case we have restraints on what we can and can’t do. There are several reasons why certain decisions have been made and certain actions taken. These include various things like PCI compliance, internal architectural restraints, staffing, budget, internal priorities, etc.

With that being said, here is what I have to say about a few of the issues in this thread. I am going to try and be thorough for anyone else that might come by this thread later.

Refresh Tokens

  • Refresh Tokens are single use but long lived (6 months)
  • When a refresh token is used the response includes a new refresh token that is good for an additional 6 months
  • This allows for indefinite refreshes with zero user interaction after the initial authorization.
  • Threading. This is part of life as developer. There are few options to handle the scenario of refreshing tokens in a multi-threaded environment.
    • Synchronize the call to get the token from your own storage. If it is expired then refresh the token inline. Then persist it. (This is my preferred approach)
    • If you don’t want to worry about threading you can build in some error handling. If two threads attempt to refresh the token one will succeed and one will fail. In the case of failure just refetch the token from storage (it should be the new one).
    • Cron - Refresh tokens in the background. If you want to protect against a server shutdown then you need to make your cron more resilient. We suggest that if you go the cron route then that cron needs to run often and refresh tokens ahead of expiration. For example run the cron every hour and refresh all tokens that will expire within 6 hours. This will give you 6 tries before the token actually expires.

User Interaction

  • The Authorization Code Grant is intended for Infusionsoft users authorizing 3rd parties.
  • We understand that the use case of an app owner wanting API access to their own application is not ideal for Authorization Code Grants.
    • In these scenarios there are many ways of generating the initial tokens.
      • Put yourself through the authorization
      • Use of 3rd party tools, such as Postman, can aid in running this generation. It is what we use in-house.
      • Generate a token using Account Central via API Access please note that there is an open known defect with Partners generating tokens using this method).
      • Personal Access Tokens will be shipping very shortly. These will still be standard OAuth tokens that need to be refreshed.

SDK

  • We have been working on autogenerating SDKs based on our OpenAPI spec.
  • We are hoping some sort of token management will be rolled into that.
  • It will also include additional languages. We have a Java version that is in alpha.

New Infusionsoft

  • Legacy API keys will be going away sooner than later. We expect to have announcements on this in the near future.
  • New Infusionsoft is basically a new front end to the existing backend. Since API calls go to the backend we didn’t want existing integrations to fail for New Infusionsoft apps. So we made the decision to keep it for now. We didn’t want to slow up delivery of New Infusionsoft while we migrate existing integrations off of legacy keys.
  • We are working on a new authentication mechanisms based on OAuth 2.0 to alleviate issues with moving away from legacy keys.

Proxies for Wordpress (and similar applications)

  • This is a unique case in which embedding your client_id and client_secret is not secure. The source is usually available for anyone to see. Browser extensions fall into this category as well.
  • We hope Personal Access Tokens will solve this problem. We are in the process of putting on the final touches and building out documentation.
  • There will be a specification that will allow this to be pretty seamless for users.

Hopefully I have answered a lot of the concerns. Feel free to ask me to clarify anything and I will do the best I can.

Thanks,
Brad

2 Likes