JWT Validation policy and salesforce named credentials

In the last article, I described how to secure your services with the JWT Validation policy. To test it, I used Salesforce hands-on org from the trailhead. Imagine now that the Salesforce developer or admin reaches you and is asking you some questions about named credentials to set up JWT header. To make it smooth, I wrote below what is what, as a reason, your conversation may be more comfortable. And the overall goal reached – that is JWT setup.

Named credentials

Named credential is the feature of the Salesforce that allows us to configure the authentication method for given URI. Here I will focus only on the part helpful in setting up the JWT authentication header. It has some configuration limitations, but it is a convenient tool to setup credentials quickly.

To setup JWT authentication in Salesforce you must pick Named Prinicipal as identity type and JWT as authentication protocol.


On the graphic below, you can see what from Salesforce Named Credentials suits JWT Validation Policy configuration details. Let’s go through each highlighted element.

Salesforce named credentials - JWT Validation Policy details
Salesforce named credentials – JWT Validation Policy details

After I pick Named Principal, I need to provide Named Principal Subject. This is the identity that is sent for all requests. As you can see, we may correlate it with client id validation. In the presented example I put client id into principal and MuleSoft perform validation against it. Salesforce during JWT payload creation put this value into the sub property.

Next, there is Audiences property. This results in adding aud property to the JWT payload. Just to quickly remind you, the audience is for who the intended token is for. In our case, it is intended for MuleSoft APIs. I put here the DLB hostname – api.patrykbandurski.com. On the diagram, you can see that it suits the audience validation claim. I turned it on and I provided two possible values that MuleSoft can accept in the aud property.

The next part is the token validation. I suggest setting it for a relatively short period of time, from security reasons. The default seven days may be too long. As you can see I decided for twenty minutes. On the JWT Validation policy we can just turn on that expiration claim is mandatory – like in the diagram above.

Our JWT token contains a signature part that is signed with the private key and on the MuleSoft side decrypted using the public key part. In JWT signing Certificate you can pick the certificate defined in Salesforce that will be used for that purpose. As I described in the last article we just need the public key to configure the MuleSoft part.

Last but not least we have in callout options section Generate Authorization Header. Once you tick it, Salesforce uploads the JWT token into Authorization header. As on the diagram, it suits the first option in policy configuration that is JWT origin. As you can see, on the MuleSoft side we expect the authorization header (httpBearerAuthenitcationHeader).

JWT token

As you remember, the JWT token consists of three parts: header, payload, and signature. The configuration above implies how these three components look like. Let’s see what to expect in each of them.


As you can see, down below, the header contains information about the signature. This part is the same for all request calls.

  "typ": "JWT",
  "alg": "RS256",
  "kid": "MuleSoftJWT"


In the payload part, you can see that the Salesforce sends client_id in the sub. The audience is set to api.patrykbandurski.com and expiration property is in place. iat and exp properties are Unix timestamps – to convert it in two directions you can use page such as Epoch Converter.

  "sub": "fdc5b21bfb8f4af89900b11db3b9eb5e",
  "aud": "api.patrykbandurski.com",
  "iat": 1596277201,
  "exp": 1597277201


Signature contains encrypted the header and the payload. It is encrypted using the private key MuleSoftJWT.


Often teams work closely to reach the goal which is a successful project. It may be as trivial as setting JWT Validation between Salesforce and MuleSoft. We do not need to know how to configure Salesforce or other 3rd party systems, but it definitely may be helpful if you have some ground understanding. This definitely made my conversation with Salesforce development team members more straightforward. There is another advantage of that. After MuleSoft has been acquired by the Salesforce company, more and more often we have scenarios including integration with the Salesforce system.

JWT Validation policy and salesforce named credentials

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top