If you’ve done much API generation then you’ll that you don’t want to have to make your users authenticate multiple times just because your API is going somewhere external. For example, if you have an API that reaches into Salesforce but your app uses Google SSO, you don’t want to have to present an oauth screen to your user after they’ve already authenticated. To work around this, you can use a JWT Bearer flow to login on behalf of a user and get a access token to work with.

A very common use case for integrations with external systems is to have a service user that is authenticated and all subsequent interactions happen via that user. This flow is super easy when you can do username / password auth, but it becomes much harder when you’re only option is to use the oAuth flow.

Use Case

In a recent developer board post, a community user asked for help storing their credentials from the oAuth flow to box.com and then create a new folder whenever an account was created. The problem they were facing is that when you do the initial oAuth flow, you have to approve the use of the app and this requires human interaction. This is not something you can do inside of a trigger, so we’ll need to find another way to do it.

For the past couple of years I’ve dabbled in running and getting data from Runkeeper. I decided that I’d give it a try to have the entire process inside of Salesforce. This provided an interesting challenge for me, since it’s the first time I’ve setup the oAuth flow from Salesforce back to Salesforce. This post will likely be the first of a couple in this theme of pulling data from Runkeeper. The code included here is just a base for what can be done. I’ll be maintaining an updated version of the RunkeeperUtils class on my github, so make sure you check there for the most recent version of everything. So let’s go over how we can do this