{"componentChunkName":"component---src-templates-blog-list-template-js","path":"/engineering/40","result":{"data":{"allMarkdownRemark":{"edges":[{"node":{"excerpt":"Bots are tools that are created to automate tedious processes and reduce work. For example, chatbots automate replies to users for customer…","fields":{"slug":"/engineering/a-bot-protection-overview/"},"html":"

Bots are tools that are created to automate tedious processes and reduce work. For example, chatbots automate replies to users for customer support, and search bots are used to populate search results on a Google search. However, there are many bots that are crafted for the malicious self-interest of a party. Examples of these hostile bots include DDOS (Direct Denial of Service) botnets and spam bots. This post will provide some information on how to implement bot protection to protect your systems from these nasty bot attacks.

\n

CAPTCHA:

\n

One of the most popular methods of bot protection that is used today is CAPTCHA, which is provided through companies such as ReCAPTCHA, NuCaptcha and Solve Media. CAPTCHA, which stands for “Completely Automated Public Turing Test to tell Computers and Humans Apart”, is an anti-bot measure which consists of a challenge which a user must complete to verify if the user is human. Examples of challenges include translating images of distorted text, or recognition of objects in an image which match a given word. CAPTCHAs are useful in blocking automated form submissions by bots and are constantly being updated to be more friendly to human users. Some of the latest CAPTCHA implementations only require the user to click on a checkbox to pass their validation check.

\n

An example of a ReCAPTCHA with distorted text

\n

\n

To implement CAPTCHA using Google’s ReCAPTCHA solution, you can access Google reCAPTCHA bot protection and login with your Google account. Following that you will be redirected to an interface where you can register your site. Different types of CAPTCHAs can be set up for different events on your domain and can be built to match your use case.

\n

An example of a ReCAPTCHA with a checkbox validation

\n

\n

CAPTCHAs have a variety of uses, and can be used to prevent automated form completions and even prevent access to your domain. Setting up a CAPTCHA detection solution for different scenarios will typically provide a strong bot defense for your system.

\n

Spam Honeypots:

\n

Spam honeypots are traps that ensnare bots by placing hidden input fields within a form that reject registration upon being filled in. Bots that use detect form fields through HTML may be programmed to fill in all the input fields in a form including the honeypot. Meanwhile, since the fields are hidden, human users should not be able to see the honeypot and should not be filling in the field.

\n

The implementation of a honey pot can be as simple as implementing an extra form field onto your page that should not be filled in. Hide the element using CSS and set up logic to prevent users that fill in the field from successfully completing the form. A simple implementation can be done with this code:

\n
<input id="first-name-input" type="text" name="firstname" value="Fill me in"> <input style="display: none;" id="honeypot-input" type="text" name="honeypot"> <button type="button" onclick="submitForm()" value="button">Submit</button> <button type="button" onclick="fill()" value="button">Fill Honeypot</button> <script>    let submitForm = function() {         let honeypot = document.getElementById("honeypot-input").value;         if(!honeypot) { \n   // Handle input submit            \n        console.log(“Pass”);         } \n   else { \n   // Handle honeypot error            \n    console.log(“Fail”);  }  } \n     let fill = function() {  document.getElementById("honeypot-input").value = "Example";     } \n</script>
\n

With the implementation of the above code, if a bot is setup to fill in all input fields on your web page, then the hidden honeypot input will be filled in and the bot will be detected. On the other hand, if a normal user attempts to complete the form on the page, the honeypot would be invisible and the registration will be successful.

\n

Honeypots are a solution to weed out basic bots, but they can be easily circumvented depending on how the honeypot is implemented. Regardless, adding a honeypot still provides an additional layer of defense against bot inputs and will help deter some bot traffic on your site.

\n

Lockout Time:

\n

Often times, when bots are created to automate a task, they would be programmed to complete these tasks as quickly as possible to maximize efficiency. As a countermeasure, time lockouts can be set up to prevent bots from repeatedly spamming requests. By setting up a time lockout between requests to your domain, bots which attempt to quickly submit data on your domain will be detected. Meanwhile, human users that are registering onto the site will be working at a slower pace and will not notice the time lockout at all.

\n

Setting a timer on form completion does not prevent any bots from affecting your domain, but can significantly slow down their efficiency. Combined with ReCAPTCHA or other anti-bot measures, it can be very useful in reducing the impact of bots.

\n

Blacklisting IPs:

\n

If an entity accessing your website is from an unexpected location, for example, a Russian IP accessing your domain for an American service, using IP blacklists may be useful to prevent possible bot attacks. IP blacklisting can usually be set up through your hosting services and allows you to customize where users may access your domain.

\n

There are some issues with blacklisting, though. Choosing which targets to blacklist could be a tedious task. Even with a bot set up to detect users with suspicious activity and block them, there could be a chance of a false positive, which may result in users of your domain being blacklisted.

\n

Proof Of Work:

\n

If you want to save your site from spams and denial-of-service attacks you can incorporate a layer of Proof Of Work algorithm in your site. Whenever any client will try to connect to your server they need to commit some of their resources to the Proof Of Work algorithm first and then the server should be connected.

\n

With this approach, any legitimate user would experience just a negligible computational cost, but a spammer/attacker trying to establish a large number of connections would bear the computational cost and time delay, it deters the abuser to do so. There are many POW algorithms which you can use eg:- Client Puzzle Protocol, Productive Puzzle Protocol, Guided Tour Puzzle Protocol

\n

Other Forms of Malicious Bots:

\n

Other malicious bots that can impact user experience negatively include, but are not limited to, bots designed for DDOS attacks, spam bots that harvest user data, bots that create links to phishing websites which generate viruses, and malicious bot worms that infect computers.

\n

Countermeasures for these bots vary depending on what is being prevented. Honeypot data fields can act as a detection method against bots harvesting data, and with proper preventative training, phishing and scam bots can be handled. Third party services may also be used to protect from different forms of bots. For example, to mitigate impacts of DDOS attacks, a user may implement a solution offered by CloudFlare. Another example is the use of an ad blocker to prevent malware from being drive-by downloaded by intrusive ads.

\n

Conclusion:

\n

Unless your domain is a highly popular website, or is being targeted by technical security violation experts, there is a good chance that utilizing a simple Google ReCaptcha prompt for form completion is enough to handle any malicious bots that attempt to access your website. For domains with significantly more traffic, paid solutions like Cloudflare might also be useful in dealing with malicious bots.

\n

Keep in mind that although some bots are created for bad purposes, a large number of bots exist to automate beneficial tasks and make it easier for humans. Even though there are a significant amount of bots that are not helpful, it is important to embrace how useful benevolent bots actually are.

\n","frontmatter":{"date":"May 31, 2019","updated_date":null,"description":null,"title":"A Bot Protection Overview","tags":["Engineering","Captcha","Spam","Secure","IP"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.2578616352201257,"src":"/static/1e9de1f0f49317e7c7f90de2abc6e308/58556/Productshot.webp","srcSet":"/static/1e9de1f0f49317e7c7f90de2abc6e308/61e93/Productshot.webp 200w,\n/static/1e9de1f0f49317e7c7f90de2abc6e308/1f5c5/Productshot.webp 400w,\n/static/1e9de1f0f49317e7c7f90de2abc6e308/58556/Productshot.webp 800w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Chris Yee","github":null,"avatar":null}}}},{"node":{"excerpt":"OAuth2 is an authorization delegation protocol that allows one party’s accessing of an end user’s resources stored with another party…","fields":{"slug":"/engineering/what-is-the-difference-between-oauth1-and-oauth2/"},"html":"

OAuth2 is an authorization delegation protocol that allows one party’s accessing of an end user’s resources stored with another party without sharing any credentials. OAuth2 is often compared with SAML and OpenID Connect as their purposes and uses overlap, however these comparisons often refer to OAuth2 as OAuth. This has resulted in some confusion regarding OAuth2 and OAuth1.

\n

OAuth1 was published in 2010, and OAuth2 is a complete rewrite of OAuth1 released in 2012. The following section will go over the most significant needs that led to this rewrite, along with the change associated to address them.

\n

Support for non-browser based applications

\n

One of the commonly agreed-upon disadvantages of OAuth1 was the lack of support it offers to non-browser based application clients. OAuth2 has different authorization work flows to address authorization initiated by native application clients. This was one of the main advantages OAuth2 has over OAuth1. However, abuse of the flows in favour of convenience and ease can lead to insecure implementations of OAuth2. When using OAuth2 for mobile, desktop, or single page applications, it is recommended to refer to the IETF paper going over best OAuth2 practices for mobile apps: IETF.

\n

Ease of implementation

\n

OAuth1 was often criticized for the barrier it poses to writing a client as each exchange between client, server, and resource server requires a validation of a shared secret. This secret is used to sign the arguments for the authorization request by the client, subsequently the server signs the arguments with the client’s key to verify the legitimacy of the client. The arguments need to be passed in the exact order and is often finicky to write. Moreover, dealing with cryptographic signing of the requests in addition to this can be a pain.

\n

OAuth2 has delegated this part of the security to transfer over HTTPS. This means while OAuth1 is protocol-independent, OAuth2 requests must be sent over SSL. Since TLS already provides transport-level message privacy and integrity, some question the merit of arguably redundant client-side signing and argument sorting. Others have brought up concerns with completely delegating security to HTTPS, and mention reasons such as yet-undiscovered zero-day TLS vulnerabilities potentially compromising entire systems.

\n

Clear separation of roles

\n

The conceptualization of OAuth2 defines a resource server in addition to an authorization server. This means there is a clear separation of roles between the server that handles the authorization request, and the server that makes access-control decisions based on the response to the authorization request. This separation of concerns allows support for more flexible use cases.

\n

So, OAuth1 or OAuth2?

\n

All of the above points seem to suggest OAuth2 as a superior alternative to OAuth1, and that OAuth1 is obsolete. This is not the case. It is very rare to see a greenfield authorization system using OAuth1, and the only major player still using OAuth1 is Twitter -- they call their version OAuth1.0a. However, as far as security and usability is concerned, OAuth1 is still viable and perhaps even more secure than OAuth2 since it offers additional security on top of TLS-based precautions, and creates barriers in potentially compromising flows. An existing system that uses OAuth1 probably does not need to upgrade to OAuth2. New systems that rely on server-to-server authorization could probably leverage OAuth1 for the additional security as well. On the other hand, use cases that could benefit from a separation of concerns, non-browser support, and ease of client development should go for OAuth2.

\n

OAuth2 has received its own share of criticisms. For example, in 2012 Eran Hammer, one of the original authors of OAuth2, withdrew his name from the specification and wrote an article calling out its many flaws. However, even in this article he agreed with the usefulness of OAuth2, and that “at the hand of a developer with deep understanding of web security will likely result in a secure implementation”.

\n

OAuth2 is not necessarily more secure than OAuth1, and using OAuth2 does not inherently lead to better security. Many considerations must go into each specific implementation. For starters, the appropriate grant flow must be chosen with care pertaining to the use case; the redirect_uri must be validated sufficiently; and measures must be taken to prevent access tokens from ending up in the browser history. For additional security considerations, see this IETF work in progress draft on OAuth Security Best Current Practice.

\n","frontmatter":{"date":"May 31, 2019","updated_date":null,"description":"Learn about the differences between OAuth 1.0 and OAuth 2.0 and how OAuth 2.0 is superior to OAuth 1.0","title":"OAuth 1.0 VS OAuth 2.0","tags":["Oauth","Engineering"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/510a2fd56b48862ff6adf67d59bf19dd/58556/pexels-photo-373543.webp","srcSet":"/static/510a2fd56b48862ff6adf67d59bf19dd/61e93/pexels-photo-373543.webp 200w,\n/static/510a2fd56b48862ff6adf67d59bf19dd/1f5c5/pexels-photo-373543.webp 400w,\n/static/510a2fd56b48862ff6adf67d59bf19dd/58556/pexels-photo-373543.webp 800w,\n/static/510a2fd56b48862ff6adf67d59bf19dd/99238/pexels-photo-373543.webp 1200w,\n/static/510a2fd56b48862ff6adf67d59bf19dd/7c22d/pexels-photo-373543.webp 1600w,\n/static/510a2fd56b48862ff6adf67d59bf19dd/da3e9/pexels-photo-373543.webp 2250w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Ti Zhang","github":null,"avatar":null}}}},{"node":{"excerpt":"This blog post goes over how you can connect your SAAS/web application with the Azure AD world. Let’s take a look at how Azure AD works as…","fields":{"slug":"/engineering/azure-ad-as-an-identity-provider/"},"html":"

This blog post goes over how you can connect your SAAS/web application with the Azure AD world. Let’s take a look at how Azure AD works as an identity provider to provide your users with the ability to log in. e.g if anyone using Office 365, able to log on with their standard account or a federated one.

\n

Windows Azure provides a number of identity-based technologies to support such kind of requirements. As a means of illustrating this, we’ll show an example using Azure AD as an Identity Provider (IdP), connecting up to the LoginRadius SAAS application using the LoginRadius Admin Console.

\n\n

\n\n

\n\n

\n

Here are the meanings of the terms, we have used above:

\n

Sign-On Url: This is where you want to send users to when accessing the \"application\".

\n

Reply URL: It's the Reply URL which is the address to which Azure AD will send the SAML authentication response.

\n

On the Service Provider side, the metadata from the tenant, Azure Identity Provider needs to be parsed and added to the configuration file. This is done by downloading the Azure IdP metadata file directly, e.g.

\n

https://login.microsoftonline.com/<AzureTenantID>/federationmetadata/2007-06/federationmetadata.xml

\n

This is all you need to know to go about creating a new application on the Azure portal and use Azure Ad as an Identity provider for login. With these and a number of services, Azure offers a solid convergence point for brokering connections with your web applications and workspaces.

\n","frontmatter":{"date":"May 30, 2019","updated_date":null,"description":null,"title":"Azure AD as an Identity provider","tags":["Engineering","Authentication","AzureAD"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1,"src":"/static/cfb639b3060cd188a04597240fb1e37d/a3e81/TN0lxUr0.webp","srcSet":"/static/cfb639b3060cd188a04597240fb1e37d/61e93/TN0lxUr0.webp 200w,\n/static/cfb639b3060cd188a04597240fb1e37d/1f5c5/TN0lxUr0.webp 400w,\n/static/cfb639b3060cd188a04597240fb1e37d/a3e81/TN0lxUr0.webp 512w","sizes":"(max-width: 512px) 100vw, 512px"}}},"author":{"id":"Team LoginRadius","github":"LoginRadius","avatar":null}}}},{"node":{"excerpt":"What is JWT? What is OAuth2? JWT(Json Web Token) is a token format. It is digitally-signed, self-contained, and compact. It provides a…","fields":{"slug":"/engineering/using-jwt-with-oauth2-when-and-why/"},"html":"

What is JWT? What is OAuth2?

\n

JWT(Json Web Token) is a token format. It is digitally-signed, self-contained, and compact. It provides a convenient mechanism for transferring data. JWT is not inherently secure, but the use of JWT can ensure the authenticity of the message so long as the signature is verified and the integrity of the payload can be guaranteed. JWT is often used for stateless authentication in simple use cases involving non-complex systems.

\n

OAuth2 is an authorization protocol that builds upon the original OAuth protocol created in 2006, arising out of a need for authorization flows serving different kinds of applications from web and mobile apps to IoT. OAuth2 specifies the flows and standards under which authorization token exchanges should occur. OAuth2 does not encompass authentication, only authorization. For more information on OAuth2, please see IETF

\n

Using JWT with OAuth2

\n

JWT and OAuth2 are entirely different and serve different purposes, but they are compatible and can be used together. The OAuth2 protocol does not specify the format of the tokens, therefore JWTs can be incorporated into the usage of OAuth2.

\n

For example, the access_token returned from the OAuth2 Authorization Server could be a JWT carrying additional information in the payload. This could potentially increase performance by reducing round trips for the required information between the Resource Server and the Authorization Server. This is a good use case for incorporating JWT into OAuth2 implementations when transparent tokens are acceptable - there are scenarios requiring token opacity where this is not optimal.

\n

Another common way to use JWT in conjunction with OAuth2 is to issue two tokens: a reference token as access_token, and a JWT containing identity information in addition to that access token. In use cases where this implementation seems necessary, it is probably worth looking into OpenID Connect - an extension built upon OAuth2 and provides additional standardizations, including having an access_token and an id_token.

\n

A common misconception is that using JWT with OAuth2 increases the security of an application, this is not true. As mentioned earlier, JWT is not an inherently secure mechanism, and the security of OAuth2 is upheld through the definitions of the actors involved in the authorization process and the specific steps to be taken for this process in different use cases. Security concerns regarding OAuth2 are best addressed by choosing the appropriate OAuth2 grant flow for the application based on use case, not the token format.

\n

The advantages of using JWT in addition to OAuth2 is in increased performance and decreased process complexity when it comes to certain flows; however, this may increase development complexity. When deciding whether to use JWT on top of OAuth2, it is best to begin by considering whether the performance gain is meaningful to your application, and whether that is worth the additional work required for development.

\n","frontmatter":{"date":"March 11, 2019","updated_date":null,"description":"Learn how to use JWT with OAuth and when & why","title":"How to Use JWT with OAuth","tags":["JWT","Oauth","JSON Web Token"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/6bb161407bb0fc97a9525faaae5de564/58556/photo-1454165804606-c3d57bc86b40.webp","srcSet":"/static/6bb161407bb0fc97a9525faaae5de564/61e93/photo-1454165804606-c3d57bc86b40.webp 200w,\n/static/6bb161407bb0fc97a9525faaae5de564/1f5c5/photo-1454165804606-c3d57bc86b40.webp 400w,\n/static/6bb161407bb0fc97a9525faaae5de564/58556/photo-1454165804606-c3d57bc86b40.webp 800w,\n/static/6bb161407bb0fc97a9525faaae5de564/99238/photo-1454165804606-c3d57bc86b40.webp 1200w,\n/static/6bb161407bb0fc97a9525faaae5de564/5616c/photo-1454165804606-c3d57bc86b40.webp 1350w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Ti Zhang","github":null,"avatar":null}}}},{"node":{"excerpt":"What is an SSL Certificate? Let’s start with some working definitions of the HTTP and HTTPS protocols. HTTP is the Internet protocol over…","fields":{"slug":"/engineering/lets-encrypt-with-ssl-certificates/"},"html":"

What is an SSL Certificate?

\n

Let’s start with some working definitions of the HTTP and HTTPS protocols. HTTP is the Internet protocol over which data is sent between a browser and a server when they are communicating. HTTPS is the secure counterpart of HTTP , which encrypts data to ensure private communication.1 An SSL certificate is a data file that is installed on a web server to enable the use of the HTTPS protocol.2

\n

Why SSL Certificates?

\n

The communication privacy that HTTP provides is desirable for obvious reasons: for example, you would not want a website you are purchasing something from to not encrypt your credit card information before sending it to the server, for that would expose it to everyone who needs only a decent understanding of how the internet works to access it. Other benefits of SSL certificates include:

\n\n

Considerations

\n

There are some considerations to be aware of when implementing SSL certificates on your server. There is a cost involved due to he infrastructure that has been put into place by the SSL certificate provider to issue the certificate. Additionally, processing encrypted data takes more server resources. However, there is available hardware that can minimize this impact.3 Considering the additional security and end user trust SSL certificates can bring to your website, there is no doubt that its benefits far outweigh the costs and efforts of its implementation.

\n

A Final Note

\n

You might be aware that version 3.0 of the Secure Sockets Layer protocol was deprecated in 2015 by the IETF because of its vulnerabilities. Other protocols, such as TLS, are more secure and have to be used in replacement of SSL.5 This might lead you to think, how do I replace my SSL certificate with a TLS certificate so I ensure security in my website? The answer is you do not have to. Although the phrases ‘SSL certificate’ or ‘SSL/TLS certificates’ are used, the certificates are not bound to the protocol your server uses. Certificates can be used with either SSL or TLS; what determines what protocol you use is your server configuration.6

\n

References:

\n
    \n
  1. SSL Certificate Products
    2. \n
  2. What is an SSL Certificate?
    3. \n
  3. IETF
    4. \n
  4. SSL vs TLS - What's the Difference?
    5. \n
\n

Note: image labeled for reuse, taken from Google images.

\n","frontmatter":{"date":"January 14, 2019","updated_date":null,"description":null,"title":"Let's Encrypt with SSL Certificates","tags":["SSL","SSL Certificate","Security"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1,"src":"/static/90a313f3cd5904bc72263dd554515b3a/e9589/ssl.webp","srcSet":"/static/90a313f3cd5904bc72263dd554515b3a/61e93/ssl.webp 200w,\n/static/90a313f3cd5904bc72263dd554515b3a/1f5c5/ssl.webp 400w,\n/static/90a313f3cd5904bc72263dd554515b3a/e9589/ssl.webp 500w","sizes":"(max-width: 500px) 100vw, 500px"}}},"author":{"id":"Ruben Gonzalez","github":"rubenprograms","avatar":null}}}},{"node":{"excerpt":"Both encryption and hashing have significant uses in cryptology and other fields. One defining difference between them is that encryption is…","fields":{"slug":"/engineering/encryption-and-hashing/"},"html":"

Both encryption and hashing have significant uses in cryptology and other fields. One defining difference between them is that encryption is reversible, while hashing is irreversible. Because of this, encryption is often used for protecting the confidentiality of data. Only authorized people with the key should be able to access the data. On the other hand, hashing works well for verification; knowing the actual data is unnecessary, just whether or not the hashes are the same.

\n

Encryption example: sending confidential documents to a co-worker through email.

\n
    \n
  1. Encrypt confidential documents.
    2. \n
  2. Send encrypted documents & key to co-worker through different sources.
    3. \n
  3. Co-worker receives the documents & decrypts them using the key.
    4. \n
\n

Hashing example: verifying user credentials for login.

\n
    \n
  1. User registers and creates a password.
    2. \n
  2. Server hashes a password and stores it in a database.
    3. \n
  3. User logs in by submitting their password.
    4. \n
  4. Server hashes the submitted password, and compares it with the hashed password in the database.
    5. \n
  5. If hashes are the same, the user is authenticated.
    6. \n
\n

Encryption

\n

Encryption is defined as conversion of electronic data into unreadable format by using encryption algorithms. This process of encoding the original data is called encryption. The data dump after encoding is called ciphertext.

\n

The purpose of encryption is to protect stored data, by guaranteeing that the information cannot be understood by individuals other than the proposed recipient(s).

\n

Encryption transforms information under another format such that just particular individual(s) could decrypt the conversion.

\n

DES

\n

The Data Encryption Standard (DES) is a symmetric key algorithm that was widely used for many years. DES is a block cipher that uses a 64-bit block of plaintext and a 56-bit key in order to output a 64-bit block of ciphertext. The core of the algorithm is composed of a series of repetitive modules that transform the block of plaintext. Each module’s bit manipulation includes transposition, splitting, concatenation, and combination with the key. A security limitation is that the key can be brute forced, especially since in DES the key is a relatively short 56-bits (thus, 256possibilities). Because of the technological advances in computing, DES is now considered insecure.

\n

3DES

\n

Triple Data Encryption Standard (3DES/TDES) is a successor to DES, and runs the DES algorithm three times to each block of data. The standard keying option is to use 3 keys of 56-bits each, resulting in a final key of 3 x 56 = 168-bits. A security limitation is its vulnerability to meet-in-the-middle attacks, where essentially the attacker brute forces the encryption of the plaintext and decryption of the ciphertext at the same time. This allows the 168-bit key to be brute forced in 22 x 56iterations.

\n

AES

\n

The Advanced Encryption Standard (AES) is a symmetric key algorithm trusted worldwide including the U.S government with classified material. AES is a block cipher which uses 128-bit blocks of plaintext, and three key options: 128-bit, 192-bit, and 256-bit. On a high-level, AES shares many fundamental concepts with DES; in particular, transforming a block of plaintext through repetition and bit manipulation. This include substitution, transposition, and bitwise operations. Currently, the only security limitation is its theoretical risk to brute force.

\n

RSA

\n

The Rivest-Shamir-Adleman (RSA) is a asymmetric key algorithm based on the difficulty of prime factorization. The algorithm first generates a private and public key using 2 random, sufficiently large, and distinct prime numbers. Public keys can then be distributed to external parties. Plaintext encrypted using the public key and RSA formula can only be decrypted using the private key. Security limitations include weak key generation due to poor choices in prime numbers, and the possibility of breakthroughs such as quantum computers trivializing prime factorization.

\n

Blowfish

\n

Blowfish is a symmetric key algorithm freely available in the public domain. As a block cipher, Blowfish processes 64-bit blocks of plaintext, and a key ranging from 32 to 448-bits. It is known to be fast compared to existing alternatives, except when changing keys. The algorithm involves multiple cycles of splitting the key into 2 subarrays, substituting bits, and performing a series of bitwise operations with parts of the plaintext block. A security limitation is its relatively small block size of 64-bits makes it vulnerable to birthday attacks, which is based on probability theory.

\n

Twofish

\n

Twofish is a symmetric key algorithm freely available in the public domain. Twofish is a block cipher with 128-bit blocks of plaintext, and up to a 256-bit key. The designer of Blowfish also worked on Twofish. Similar to Blowfish, Twofish is a fast cipher, and shares some of the same concepts and structure in transforming a block of plaintext. Currently, the only security limitation is its theoretical risk to brute force.

\n

Skipjack

\n

Skipjack is a symmetric key algorithm with 64-bit blocks of plaintext and 80-bit key. It was designed by the NSA with the purpose of encrypting voice transmission, and later declassified for public knowledge. The algorithm is based off a technique of repeatedly splitting the plaintext block and performing bitwise operations with subkeys. Currently, the only security limitation is its theoretical risk to brute force, especially due to its relatively short key.

\n

Use Cases

\n

Symmetric key encryption

\n\n

Asymmetric key encryption

\n\n

Hashing

\n

Hashing is a process of taking a big block of data and reducing it to smaller blocks of data in a specific order by using hashing functions. Cryptographic hashes are irreversible.

\n\n

Some properties of hashed data:

\n\n

The output of a hashing algorithm is a hashed value, also known as a message digest. Analogous to a fingerprint.

\n

MD4

\n

The Message Digest 4 (MD4) algorithm takes an input text of arbitrary length, and outputs a 128-bit digest in the form of a 32-digit hexadecimal number. The algorithm works by first padding the text to a certain length, and then appending to it a 64-bit binary representation of the text. Next, the text is processed in blocks of 512-bits, with each block undergoing three rounds of bit manipulation. MD4 is insecure, as a collision attack was found. This is where two input texts produce the same output digest (a hash collision), thus allowing for issues such as forging digital signatures.

\n

MD5

\n

The Message Digest 5 (MD5) algorithm is similar to MD4, except each block is processed in four more complex rounds. MD5 is also considered insecure, as a collision attack was found. However, MD5 is still often used in the industry for cases which do not require collision resistance, such as password hashing. Better solutions exists, but tradition and lack of modern security expertise drives the popularity of MD5.

\n

SHA-1

\n

The Secure Hash Algorithm 1 (SHA-1) takes an input text of arbitrary length, and outputs a 160-bit digest, typically in the form of a 40-digit hexadecimal number. The algorithm performs padding, and 80 rounds of text manipulation such as bitwise shifting and XOR operations. SHA-1 is considered insecure, as a collision attack was found.

\n

SHA-2

\n

The Secure Hash Algorithm 2 (SHA-2) is a family of successors to SHA-1. This includes SHA-224, SHA-256, SHA-384, and SHA-512. Digest sizes range from 224 to 512-bits, increasing its difficulty to brute force. The algorithm consists of padding, and 64 or 80 rounds of bit manipulation. A security limitation is its vulnerability to length extension attacks. When the algorithm is finished, this attack takes advantage of the internal state of the machine in order to keep processing new text. As a result, it is possible to construct a new digest which is an extension of the original digest.

\n

HMAC-SHA1

\n

Hash-based Message Authentication Code SHA-1 (HMAC-SHA1) uses the SHA-1 hashing algorithm and a key in order to generate a HMAC. Due to the usage of a key, there is less chance of a hash collision, but the key is vulnerable to discovery through brute force. Additionally, HMAC is vulnerable to length extension attacks.

\n

HMAC-SHA256

\n

Hash-based Message Authentication Code SHA-256 (HMAC-SHA256) uses the SHA-256 hashing algorithm and a key in order to generate a HMAC. Security concerns include the key being brute forced, and length extension attacks.

\n

PBKDF2

\n

Password-Based Key Derivation Function 2 (PBKDF2) is a hashing algorithm designed to be used for passwords. By design, hashing using PBKDF2 is slow, making it much more difficult to brute force a password. This is because the algorithm takes in a random salt, as well as the desired number of times to hash the password. Other inputs include the desired length of the output, and the hashing function used. Typically, the recommended number of iterations range in the tens of thousands, but depends on the hashing function and capabilities of the application. However, brute force still remains a threat, especially with weakly chosen salts and a small number of iterations.

\n

Argon 2

\n

Argon2 is a cryptographic hashing algorithm, most recommended for password hashing. It hashes a plain text input to a hash as per the parameters mentioned. It is governed by six parameters: password, salt, memory cost, time cost, parallelism factor, the hash length, along with one of the three algorithms included in it.

\n

Argon2 has 3 versions: Argon2d, Argon2i and Argon2id.

\n
    \n
  1. Argon2d is more resistant to GPU attacks as it accesses the memory array in a password dependent order reducing the possibility for TMTO attacks but leaves itself vulnerable to side-channel attacks.
    2. \n
  2. Argon2i, unlike '2d', accesses memory in a password independent order which increases resistance against side-channel attacks.
    3. \n
  3. Argon2id is a hybrid of '2i' and '2d'. It is always recommended one except when there are reasons to prefer one of the other two modes.
    4. \n
\n

It has experienced two attacks on Argon2i. The first attack is applicable only to the old version of Argon2i. The second attack has not been secured yet.

\n

Use Cases

\n

Authentication

\n\n

Message integrity

\n\n

Identification

\n\n

Encoding and Cryptography

\n

Encoding

\n

The process of transforming the data by using an algorithm (that is publicly available) into another format.

\n

The motivation behind encoding is to change information with the goal that it can be appropriately (and securely) fed to a different system. The main objective is not to keep data secret, but instead to guarantee that it is ready to be legitimately used.

\n

Symmetric key cryptography

\n

The process of using the same key for encrypting and decrypting the text is called symmetric key cryptography.

\n

Asymmetric key cryptography

\n

The process of using a public key for encryption and a private key for decryption is called asymmetric key cryptography.

\n

Stream cipher

\n

The process of encrypting or decrypting the text bit by bit using a symmetric key is called stream cipher. The stream cipher process is high speed and requires low hardware complexity.

\n

Block cipher

\n

The process of encrypting or decrypting the text block by block using a symmetric key is called block cipher. Block ciphers are the functions that take an input message and a key in order to create a new, encrypted ciphertext. Block cipher are used with Symmetric key encryption.

\n

Block ciphers are invertible and efficiently computable. E.g. DES, AES, BlowFish etc.

\n

Cryptographic Salt

\n

Salts are an additional piece of data used in hashing algorithms, typically for passwords. They help protect against brute force attacks, by adding complexity to the hashes. As a result, salts increase the time taken to brute force a single hash, and deter against optimizations such as dictionaries and precomputed tables.

\n","frontmatter":{"date":"December 24, 2018","updated_date":null,"description":null,"title":"Encryption and Hashing","tags":["Encryption","Hashing"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":3.278688524590164,"src":"/static/c6f801b062415da8d1e6bf77b081d5a2/0407f/encryption-and-hashing.webp","srcSet":"/static/c6f801b062415da8d1e6bf77b081d5a2/61e93/encryption-and-hashing.webp 200w,\n/static/c6f801b062415da8d1e6bf77b081d5a2/1f5c5/encryption-and-hashing.webp 400w,\n/static/c6f801b062415da8d1e6bf77b081d5a2/0407f/encryption-and-hashing.webp 615w","sizes":"(max-width: 615px) 100vw, 615px"}}},"author":{"id":"Andy Yeung","github":null,"avatar":null}}}}]},"markdownRemark":{"excerpt":"Introduction Ever wondered how apps like Spotify, Netflix, or Slack manage seamless login experiences across devices? Many of them use JWT…","fields":{"slug":"/engineering/how-to-integrate-jwt/"},"html":"

Introduction

\n

Ever wondered how apps like Spotify, Netflix, or Slack manage seamless login experiences across devices? Many of them use JWT, or JSON Web Tokens, a compact, stateless method for securely transmitting user identity and session data across services.

\n

With JWT token authentication, identity information is embedded in a signed token, allowing you to maintain user sessions without server-side storage. This approach is highly scalable and ideal for modern architectures like SPAs, mobile apps, and microservices.

\n

In this blog, we’ll walk you through what is JWT, why use it, and how to implement JWT authentication using LoginRadius.

\n

You’ll learn what JWT is, why it’s effective, and how it works in real-world applications. We'll cover both integration methods (IDX and Direct API), generating your signing key, managing sessions, storing the JWT token securely, and applying best practices throughout.

\n

Whether you're a developer, product manager, or IAM architect, this guide offers a complete foundation for implementing JWT token authentication into your application stack.

\n

What is JWT?

\n

JSON Web Token (JWT) is an open standard (RFC 7519) used to transmit information securely between parties as a JSON object. It’s compact, self-contained, and digitally signed, making it a reliable format for authentication and authorization across modern applications.

\n

A JWT consists of three parts:

\n
    \n
  1. Header – Contains metadata like the type of token and signing algorithm (e.g., HS256).
    2. \n
  2. Payload – Stores the actual data or “claims,” such as user ID, roles, and token expiry.
    3. \n
  3. Signature – A cryptographic hash that ensures the token hasn’t been tampered with.
    4. \n
\n

Example of a token structure:

\n

<base64Header>.<base64Payload>.<signature>

\n

Why Use JWT?

\n\n

How JWT Works?

\n

\"Flowchart

\n
    \n
  1. A user logs in with credentials.
    2. \n
  2. Your app (or identity provider like LoginRadius) issues a signed JWT.
    3. \n
  3. The client stores the token and sends it with each request (usually in the Authorization header).
    4. \n
  4. The server validates the token’s signature and claims.
    5. \n
  5. If valid, access is granted — without any session stored on the backend.
    6. \n
\n

JWT simplifies identity verification, especially when you're building apps that talk to APIs or need to scale without centralized session storage.

\n

JWT Authentication with LoginRadius: Overview

\n

LoginRadius provides robust support for JWT (JSON Web Token) authentication, which allows for flexible and secure access control across different digital platforms. Whether you're building a fully custom identity flow or using a pre-built interface, the platform supports various integration approaches depending on your architecture.

\n

If you're looking to understand how to implement JWT token authentication effectively, LoginRadius offers two primary implementation models that cater to different levels of customization and control:

\n

1. IDX Implementation – JWT through a Hosted Login Page

\n

The IDX-hosted login approach enables secure, standards-compliant, JWT-based authentication without requiring you to build a custom login interface. This is a strategic option for fast, compliant, and user-friendly deployments.

\n\n

Configuration Steps:

\n
    \n
  1. Enable JWT Login
    2. \n
  2. Go to authentication configuration settings and enable JWT Login in the Admin Console.
    3. \n
\n

\"Screenshot

\n
    \n
  1. Specify your signing algorithm and expiry policy, and define your JWT Secret Key.
    2. \n
  2. Input a secure JWT signing key.
    3. \n
  3. Specify token expiry duration (e.g., 15–60 minutes)
    4. \n
  4. Select the desired algorithm —HS256 for symmetric signing (same key signs and verifies)
    5. \n
  5. RS256 for asymmetric signing, where LoginRadius securely stores the private key used to sign the JWT.
    6. \n
  6. Your app or backend service uses the public key to validate the token signature.
    7. \n
  7. LoginRadius provides a JWKS (JSON Web Key Set) endpoint to dynamically fetch and rotate public keys, ensuring trust without key exposure.
    8. \n
  8. Update IDX Template for Callback
    9. \n
  9. Modify your IDX login page template to retrieve the JWT post-login. You can access the token via redirect URL parameters or secure JavaScript callbacks.
    10. \n
\n

Example Response:

\n

{

\n

\"access_token\": \"eyJhbGciOiJIUzI1NiIsInR...\",

\n

\"expires_in\": 1800

\n

}

\n

This integration approach works best for all teams that want effective identity workflows without the complexity of building proprietary login screens, something that is crucial for customer portals, onboarding of mobile applications, and even managing access for business partners.

\n

2. Direct API Implementation – Self Managed Login

\n

If you’re building a custom login UI or working in a headless environment, LoginRadius lets you generate and handle JWTs directly through its Authentication APIs. Here’s how you can programmatically perform token authentication using the classic method:

\n\n

Configuration Steps:

\n

Step 1: Authenticate via API:

\n\n

Include the user’s credentials (email + password) in the request body.

\n

Step 2: Get JWT in Response

\n\n

{

\n

\"access_token\": \"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...\",

\n

\"expires_in\": 3600

\n

}

\n

Step 3: JWT Decoding and Validation

\n\n

Step 4: Set Custom Claims (Optional)

\n

With LoginRadius, it is possible to customize the payload to include user roles and/or any additional metadata. You can set custom JWT claims on the Admin Console.

\n

With this method, you have complete customization over login flows while using LoginRadius to issue signed JWTs for user session management.

\n

NOTE- With either method, LoginRadius ensures that JWTs are securely signed, optionally short-lived, and compatible with standard token validation libraries, making integration seamless for everyone.

\n

To get started with JWT implementation, you can read our complete developer documentation.

\n

Hosted Login vs Direct API

\n

\"Illustration

\n

What is Session Management and How It Works with JWT

\n

Session management is how your app keeps track of a user after they log in so they don’t have to prove who they are with every request.

\n

In traditional apps, sessions are stored on the server using session IDs. Every time a request comes in, the server checks that session ID to verify the user.

\n

In modern apps, especially SPAs and APIs, JWTs are used to manage sessions without needing server-side storage; this is called stateless session management. The token itself carries the user’s identity, roles, and expiration details. As long as the token is valid, the user stays logged in.

\n

Good session management ensures:

\n\n

How LoginRadius Handles Session Management with JWT:

\n
    \n
  1. \n

    User Logs In

    \n\n
    2. \n
  2. \n

    Client Stores the Token

    \n\n
    3. \n
  3. \n

    Access Token Expiry

    \n\n
    4. \n
  4. \n

    Token Renewal

    \n\n
    5. \n
  5. Logout and Token Revocation Strategy
    6. \n
\n

When the user logs out, both the access token and refresh token should be cleared from client storage.

\n\n

Combining these strategies gives you greater control over token misuse and enables a robust, enterprise-grade logout flow.

\n

\"illustration

\n

How to Store JWT Tokens?

\n

When you implement JWT-based authentication, the client (browser or mobile app) needs a way to store the access token and, optionally, the refresh token after they are issued by the authentication server. This stored token is then attached to every subsequent request to prove the user's identity.

\n

Choosing where to store the JWT is a crucial security decision. The most common storage options are:

\n\n

Each option has trade-offs between security, accessibility, and persistence, and the right choice depends on your application's architecture and threat model.

\n

Recommended Storage Strategy

\n\n

Best Practices for Storing JWTs

\n
    \n
  1. Never store sensitive tokens (like refresh tokens) in localStorage or sessionStorage.
    2. \n
  2. Use Secure and HttpOnly flags with cookies to prevent JavaScript access and ensure transmission only over HTTPS.
    3. \n
  3. Set the SameSite=Strict or Lax attribute on cookies to protect against CSRF.
    4. \n
  4. Use short-lived access tokens and rotate refresh tokens regularly.
    5. \n
  5. Implement CSP (Content Security Policy) to reduce XSS risk.
    6. \n
  6. Avoid storing any tokens in frontend code (e.g., hardcoded in JS files).
    7. \n
\n

Conclusion

\n

JWT authentication with LoginRadius offers a modern, stateless approach to managing sessions across distributed systems. The IDX integration is ideal for rapid deployment, while the Direct API model is best for organizations needing deep customization and integration flexibility.

\n

With robust token signing, refresh capabilities, and centralized control, LoginRadius provides a future-ready foundation for secure, scalable identity architecture. Contact us to know more about JWT authentication and implementation guide.

\n

FAQs

\n

1. What is JWT authentication used for?

\n

A: JWT authentication securely verifies user identities, enabling stateless session management across web, mobile apps, and microservices without server-side session storage.

\n

2. How does LoginRadius simplify JWT integration?

\n

A: LoginRadius simplifies JWT integration by offering hosted IDX login pages and direct API-based authentication methods, enabling rapid deployment and deep customization.

\n

3. Is JWT authentication secure?

\n

A: Yes, JWT authentication is secure when implemented with best practices like short-lived tokens, secure storage methods, signature validation, and refresh token rotation.

\n

4. Can JWT tokens be revoked with LoginRadius?

\n

A: Yes, LoginRadius allows revocation of JWT refresh tokens explicitly, and supports strategies like short-lived tokens and key rotation to manage token lifecycles securely.

\n","frontmatter":{"date":"April 15, 2025","updated_date":null,"description":"Discover JWT (JSON Web Token) authentication, its advantages, and how to integrate it seamlessly using LoginRadius' hosted IDX and Direct API methods for secure, scalable identity management.","title":"JWT Authentication with LoginRadius: Quick Integration Guide","tags":["JWT","JSON Web Token","Authentication","Authorization"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":0.7782101167315175,"src":"/static/4cedb7829f98208cbc6d5a9aea4e983d/58556/how-to-integrate-jwt.webp","srcSet":"/static/4cedb7829f98208cbc6d5a9aea4e983d/61e93/how-to-integrate-jwt.webp 200w,\n/static/4cedb7829f98208cbc6d5a9aea4e983d/1f5c5/how-to-integrate-jwt.webp 400w,\n/static/4cedb7829f98208cbc6d5a9aea4e983d/58556/how-to-integrate-jwt.webp 800w,\n/static/4cedb7829f98208cbc6d5a9aea4e983d/1cc9f/how-to-integrate-jwt.webp 896w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Kundan Singh","github":null,"avatar":null}}}},"pageContext":{"limit":6,"skip":234,"currentPage":40,"type":"//engineering//","numPages":53,"pinned":"5c425581-f474-5ae9-abe7-cf5342db2aaa"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}