Infusionsoft SSO

I am trying to set up single sign on in our Java application that uses Infusionsoft as the IdP. Everything is working correctly, however everytime my application needs to authenticate with Infusionsoft, it asks the user whether to allow access. I would expect this to operate like other OAuth providers where it asks the first time, but thereafter does not ask. Is this a setting or something I am missing (I am using a sandbox user currently) or is there no way to do what I am after? Thanks in advance.

You have to manage the access and refresh tokens in a back end database and maintain the refresh every 24 hours (usually using a cron job)…I did a vid that covers this:

Yes what @John_Borelli said. The Authorization screen is not really meant for use as an IdP, but it can be used that way if you want. Once you have the access token and refresh token you need to store those and periodically refresh the access token with the given refresh token. John’s video explains all that, it is definitely worth a view or two :slight_smile:

Thank you both for your replies. I just finished watching that long video :sweat_smile:. Unfortunately, I’m not sure you understand my question as the video just seemed to have things from the manual in it, nothing regarding SSO.

Basically, SSO is where you have one system managing user credentials (the Identity Provider, or IdP) and another system that simply defers authenticating to the IdP (the Service Provider, or SP). Storing one access token in a database does not help me to know who each individual user is.

For instance, in other OAuth SSO implementations such as Facebook, the user is taken to Facebook to be authenticated. Once they are auth’d, they are returned to the calling app with the user information (basically what the user info rest endpoint gives). In my instance, if I store the access token, how will I know who the current user is (if there is one, it is possible they won’t be signed into Infusionsoft yet).

Is this not possible with Infusionsoft? I have done similar projects for other clients using OAuth, however I have never used Infusionsoft admittedly so I’m not sure if what the client wants is possible.

Just to reiterate, what I am looking for is a way to authenticate individual users using Infusionsoft. When a user tries to access my webapp, I want to check with Infusionsoft (where the user will sign in if not already) and then get their user info in my webapp so I know who it is. Hope that clears things up.

I completely understand what you are trying to accomplish. OAuth 2.0 itself does not have a specification for any kind of delegated IdP like you are wanting. There are specs on top of OAuth 2.0 that do provide that mechanism like Open ID Connect. We do have the user info endpoint like you mentioned which is OpenID Connect compliant. What you can be accomplished with a work flow like this…

  1. Send user to Authorize your application
  2. Once authorized use the returned Authorization Code and exchange it for an access token.
  3. Use the access token to get the user info (https://developer.infusionsoft.com/docs/rest/#!/User_Info/getUserInfoUsingGET)
  4. Store the user information, access token, and refresh token in your backend.
  5. If you want to keep the user “logged in” just put the access token into browser storage or something along those lines. Then you handle the refreshing of the token on the server on demand.

Doing this will never require the user to authorize again. If you need some sort of session management then the user will have to reauthorize the application.

To be clear we are not providing any sort open IdP for 3rd party applications using protocols like Open ID, SAML etc. It is just standard OAuth 2.0.

Hopefully that helps. If not let us know and we can help out.

1 Like

@Brian_Duffey,

To be specific, you do not have the option of actual SSO with OAuth and IS API/REST. There is a legacy api key method that will be phased out so OAuth is the only stable solution offered for authentication. That being said, what the video covers (which is actually not from any manual at all) covers the gotcha’s where people often mis-understand areas and uses. You can provide a one time authentication that can be maintained as if it were SSO from that point forward. That is the point here. While it’s not strictly SSO, you can manage OAuth in a similar way by maintaining a refresh cycle with the access/refresh tokens.