JWT stands for JSON Web Tokens. JWT(JSON Web Tokens) is an open standard (RFC 7519) way used for securely transmitting information or representing claims between any two parties, let’s say between a client/consumer and server/service. It is used to digitally sign the verified and trusted information.
Fundamentally being a tokenization format, the user thereby can pass credentials or other information in the form of tokens in a single format. In the process of tokenization, everything, even the content is wrapped as a token. Thus, it offers is a more secure way of transferring the information.
JWT is encoded not encrypted. What does that mean?
JWT is not completely secure as anybody in the network can view the message. For example, while transferring the packet (tokenized information) from client to the service, anybody within the network can see the message in the header.
Next we come to the uses of JSON Web Tokens.
Uses Of JSON Web Tokens
The uses of JWT are:
Authorization:
JWT is most commonly used for Authorization. Once logged in, user is allowed access to routes, services, and resources that are permitted with that token. This happens because each subsequent request will include the JWT.
Information Exchange:
JSON Web Tokens are a good way of securely transmitting information between parties. JWT authenticates the sender i.e., the source and verifies that the content hasn’t been tampered with
Add Your Heading Text Here
JWT consists of 3 parts that are distinguished/separated by dots.
Parameters of JWT Token
Following are the parameters for JWT token:
- Header
- Payload
- Signature
Header
Header itself consists of 2 parts:
o Token type, which in this case is JWT
o Signing algorithm used
For example, here
JSON is Base64Url encoded
Algorithm type is HS256
Payload
Payload contains the claims. Claims are basically statements about an entity(user) containing user details and relevant metadata.
Signature
Signature is combination or merger of header and payload encoded in Base64Url. Signature is used to verify that the message wasn’t changed along the way.
Above is an example of signature for HMAC SHA256 algorithm.
Before creating a JWT, we have to make a connected app mandatorily. The reason behind creating an App are:
- Consumer Key
- Consumer Secret
- Digital Certificate
Now, we will tell about the
Configuration Steps
There are two cases:
- If query string is null or empty, cookie will be set by OpenWater Default URL.
- If the query string is not null, then cookie stores the particular query string as returnUrl.
- After this step, the user is redirected to Community Login page (for e.g., Salesforce), where Username and Password are required to be entered.
- When the user clicks on the login button, Cookie Page is called.
- It is this Cookie page which will hit the Apex class. Name of the class is GenerateJWTToken.
- The Cookie page also calls a function(JWTToken)
Furthermore, there are 2 conditions:
- If the Cookie is null, the user is redirected to OpenWater Default URL
- If the Cookie is not null, the user is redirected to returnUrl with JWT token.
Next, we come to the Process demonstration:
Process Demonstration
- On the OpenWater community page, along with the community URL, a returnUrl parameter is appended, containing a query string.
2. The user is redirected to a community login page(Salesforce)
3. After the user enters the credentials and is done with the login process, user is redirected to query string stored in the returnUrl. Not only the query string is mentioned, but the user also gets the JWT token in the returnUrl finally.
Technology, behind the Curtains
After learning the process of creating a JWT Token in Salesforce, it becomes very crucial to understand the use of JWT tokens in real world. This is how the concept works:
The authentication credentials are verified against the database as the request is passed to server. Once the authentication is valid, JWT token is created.
The client is sent back the JWT token, after authentication. In case of a credential mismatch, an error message is sent. JWT token can be verified at Client side, just to be sure of it not being subjected to any tampering. Information can be extracted here as well, if needed.
Most importantly, JWT token needs to be saved at client side, in order to obtain optimum performance in case of subsequent requests. For subsequent server calls, the same token which has been saved/stored, can be used.
Mandatorily, service/server needs to verify Token every time for subsequent requests for authentication. However, there is no such obligation on the client’s part.
Finally, the client is sent back with the results or information client demands if authenticated. An error message is shown, as we know, in case of a mismatch.
Conclusion
In a nutshell, JSON Web Tokens are basically tokenisation formats used to represent claims or transmit information – securely between any two parties. However it is very important to understand that these tokens are not completely secure as anybody in the network can view the message. At the same time, it is beneficial in the way that the information is authentic and can be verified to be free of tampering of any sort through its course of transmission. Coming to the diversity, JSON parsers map directly to objects, making it common in most programming languages. JWT is widely used at Internet scale. This highlights the ease of client-side processing of the JSON Web token on multiple platforms, especially mobile.
