Salesforce Integration using JWT

JSON Web Tokens (JWT), pronounced “jot”, are a standard since the information they carry is transmitted via JSON. JSON Web Tokens work across different programming languages: JWTs work in .NET, Python, Node.js, Java, PHP, Ruby, Go, JavaScript, and Haskell. So you can see that these can be used in many different scenarios.

JWTs are self-contained: They will carry all the information necessary within itself. This means that a JWT will be able to transmit basic information about itself, a payload (usually user information), and a signature. JWTs can be passed around easily: Since JWTs are self-contained, they are perfectly used inside an HTTP header when authenticating an API. You can also pass it through the URL.

Whenever we have to do integration with a third-party system from Salesforce, we have to pass some authentication proof along with request, unless the service is open and requires no authentication. JWT is one of the most recent and commonly used mechanism to get authenticated while calling an external API. Typically a JWT has following three components

Header

The header consists of two parts:
1-Declaring the type, which is JWT
2-The hashing algorithm to use (mainly SHA256 is used)
Here’s an example:

string header = ‘{“typ”: “JWT”, “alg”: “HS256”}’;

Then we will use EncodingUtil.base64Encode function to encode it in base64 format and the first part of our JWT, i.e. Header is ready

string JWTHeader = encodingUtil.base64Encode(blob.valueOf(header));
///JWTHeader////
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Payload

The payload will carry the bulk of our JWT, also called the JWT Claims. This is where we will put the information that we want to transmit and other information about our token.

There are multiple claims that we can provide. This includes registered claim names, public claim names, and private claim names.

REGISTERED CLAIMS
Claims that are not mandatory whose names are reserved for us. These include:
iss: The issuer of the token
sub: The subject of the token
aud: The audience of the token
exp: This will probably be the registered claim most often used. This will define the expiration in NumericDate value. The expiration MUST be after the current date/time.
nbf: Defines the time before which the JWT MUST NOT be accepted for processing
iat: The time the JWT was issued. Can be used to determine the age of the JWT
jti: Unique identifier for the JWT. Can be used to prevent the JWT from being replayed. This is helpful for a one time use token.

PUBLIC CLAIMS
These are the claims that we create ourselves like user name, information, and other important information.

PRIVATE CLAIMS
A producer and consumer may agree to use claim names that are private. These are subject to collision, so use them with caution.

Finally again we need to base64Encode our claimset, like this

string Payload = ‘{“ias”:”1234″, “exp”:”4322″}’;
string JWTPayload = encodingUtil.base64Encode(blob.valueOf(Payload));
///JWTPayload////
dssd4546JzY290Y2guaW8iLCFGFGHJMJgjfstdfdfaHJpcyBTZXZpbdd

Signature

The third and final part of our JSON Web Token is going to be the signature. This signature is made up of a hash of the following components:
The header
The payload
Secret/(or private key)
The Secret could be a passcode shared by the server to sign the JWT, and the server will use same passcode to verify the integrity of JWT. This is how we will get the third and final part of our JWT

String signatureInput = JWTHeader + ‘.’ + JWTPayload;
Blob JWTSignature = Crypto.generateMac(‘HmacSHA256’, Blob.valueOf(signatureInput), Blob.valueOf(secret));
string JWToken = signatureInput + ‘.’ + base64URLencode(JWTSignature);

So the final JWT will look something like this

“eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.dssd4546JzY290Y2guaW8iLCFG
FGHJMJgjfstdfdfaHJpcyBTZXZpbdd.12lwyCg_3Q5iWsuF7x_AMJgvkpAARYhL1hBtbJEuOUI”

Final JWT is made up of combining JWTHeader, JWTPayload and JWTSignatures with a “Dot” in between them.

Leave a Comment

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