I have a client who's asking me to configure an OAuth JWT Bearer Token integration for them to retrieve delivery status information from a supplier. Salesforce is not the idP. Instead, the flow is essentially a Username, password flow that returns a JWT Bearer Token with a lifespan of 12 hrs. I'm trying to figure out how to configure Salesforce for this integration to work.

It seems that a Named Credentials configuration isn't appropriate since I can't set it up as OAuth since the endpoint isn't a recognized OAuth provider. I believe I'd need to create some kind of custom OAuth service handler. Also, the actual endpoint I need to call for the service I need to use requires a redirect that I don't think I can do with a Named Credential since that only allows me to append a snippet to the path which won't satisfy my needs (I need to go up a level before following a different path to the redirect).

Here's what the flow would look like:

Bearer Token OAuth Integration Flow

In the image above, I've shown the initial authentication using a password & username (returns the JWT Token and a refresh token), authentication requests using the JWT Bearer Token that return a new JWT Bearer Token and refresh token, authentication results made with an expired JWT Bearer Token, and finally passing the Bearer Token to the redirect for a return of data.

Any thoughts on how I need to code this to make the https request from Salesforce?

1 Answer 1


According to the specs you've provided, it makes sense that you cannot use Named Credentials or any of the standard ways of doing this. I assume the responses aren't standard either, so it makes it complicated.

If I were to code this, I would probably go with the following:

  1. A Custom Setting to hold the bearer token, which would be encrypted, and the time requested, just to let you know if it has expired or not.
  2. A Session Manager which would verify if the token has expired or not based on the date modified of the CS and, if it has expired, re-request it.
  3. you HTTP Client which would always request the token to the Session Manager so, in case it has expired, it doesn't have to bother about refreshing it because the manager would do it.

To be honest, it's more or less what you have already commented, but I think it's the simplest way of doing it. I interested in other people's responses though.

  • Thanks for the confirmation. I've been trying to avoid manually coding this. Do you think I need to build on something like the following force201.wordpress.com/2014/09/20/… as posted by @keithc, minus the token creation part?
    – crmprogdev
    Jul 5, 2018 at 14:47
  • 1
    @crmprogdev most probably. I think it's inevitable to code it. Keith's implementation looks like a good starter. You would have to add the session manager on top of it though. We have a small library for callouts where I work (github.com/Manzanit0/Httpex). Maybe you can also copy/paste some parts from it as boilerplate. Jul 5, 2018 at 15:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .