{"componentChunkName":"component---src-templates-blog-list-template-js","path":"/engineering/39","result":{"data":{"allMarkdownRemark":{"edges":[{"node":{"excerpt":"This blog is part 1 of a series on gRPC. Part 1 will go over some important concepts, part 2 will be a walkthrough of a client-server…","fields":{"slug":"/engineering/getting-started-with-grpc-part-1-concepts/"},"html":"

This blog is part 1 of a series on gRPC. Part 1 will go over some important concepts, part 2 will be a walkthrough of a client-server implementation in Go, and part 3 will be about LoginRadius' experience migrating to gRPC!

\n

gRPC

\n

gRPC, simply put, is just another way to send data across networks. It can be used to communicate between services in a microservice architecture, where a single service can interact with multiple others. Similarly, in client-server models, there can be multiple clients communicating with a common backend server.

\n

\n

The gRPC framework was initially developed at Google and is now open-source. It is a modern implementation of the RPC (Remote Procedure Call) protocol, which has been around since the 80s. You will often see gRPC being compared to other technologies like SOAP, REST, and GraphQL.

\n

Some features:

\n\n

How is it used to send data?

\n

gRPC is based on the idea of calling a remote procedure just like a local one. A procedure is like a function or a method. So, ideally developers can treat remote and local calls similarly. A great thing about gRPC is that developers do not need to know the details of the remote interaction.

\n

Here is a diagram from the official grpc docs showing the flow:

\n

\n

Each client service will include a stub, which is like an interface containing the available remote procedures. These stubs are auto-generated files.

\n

But what does proto refer to? And what are stubs? How can we generate them?

\n

To answer these questions, we need to look at another technology called protocol buffers.

\n

Protocol Buffers

\n

Protocol buffers (protobufs), are a way to format data for storage and transport. gRPC uses protobufs to format data sent over the wire. It is comparable to other data serialization formats such as JSON, XML, and YAML.

\n

Some features:

\n\n

How is it used with gRPC?

\n

Step 1: Create proto definitions - methods, requests, responses.

\n\n
service AccountService {\n  rpc Find(FindRequest) returns (FindResponse);\n  rpc Update(UpdateRequest) returns (UpdateResponse);\n  rpc Delete(DeleteRequest) returns (DeleteResponse);\n}
\n\n
message FindRequest {\n  string Uid = 1;\n}\n\nmessage FindResponse {\n  string Uid = 1;\n  string Name = 2;\n  int32 Age = 3;\n  bool isVerified = 4;\n}
\n\n

Step 2: Compile proto file for auto-generated stubs in desired language.

\n\n
protoc account.proto --go_out=plugins=grpc:.
\n\n

Step 3: Use stubs in server and clients.

\n

The Big Picture

\n

\n

Why gRPC?

\n

One compelling reason to use gRPC is that it provides high performance

\n\n

How does it differ from REST?

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
gRPCREST
APIContract-based i.e. stubsResource-based and relies on HTTP verbs i.e. GET/PUT/POST/DELETE
Network protocolHTTP/2HTTP/1.1 or HTTP/2
Data serialization formatProtocol buffersJSON
StreamingBuilt-in support for client, server, and bi-directional streamingREST on HTTP/1.1 does not allow streaming
\n

Other Considerations

\n

Here, we briefly go over a few other things to consider with gRPC. These will be covered in more detail in another blog.

\n

Management of proto files
\nIf you plan to have multiple proto files and client services, you need some way to manage them for distribution and version control. One solution is to keep all proto files in a central git repository, and maintain versions using git tags.

\n

Using proto2 vs. proto3
\nProtocol buffers have two syntax versions: proto2 and proto3.

\n\n

Load-Balancing
\nSomething to note about load-balancing gRPC is that HTTP/2 requires L7 (Application Layer) load-balancers. Recall that in HTTP/2, TCP connections are long-lived and requests are multiplexed. This makes L4 (Connection Layer) load-balancers ineffective. This differs from HTTP/1.1 where TCP connections get cycled and can benefit from L4 load-balancers. 

\n

That's it for now! To learn more, check out the official gRPC and protobuf docs.

\n","frontmatter":{"date":"October 30, 2019","updated_date":null,"description":null,"title":"Getting Started with gRPC - Part 1 Concepts","tags":["Engineering","gRPC"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1,"src":"/static/23fcca8d49d96b5e61cc171769c93b38/a55b6/grpc.webp","srcSet":"/static/23fcca8d49d96b5e61cc171769c93b38/61e93/grpc.webp 200w,\n/static/23fcca8d49d96b5e61cc171769c93b38/a55b6/grpc.webp 246w","sizes":"(max-width: 246px) 100vw, 246px"}}},"author":{"id":"Andy Yeung","github":null,"avatar":null}}}},{"node":{"excerpt":"Introduction Cross-Site Request Forgery (CSRF) is a common web application attack where a victims’ authenticated session becomes compromised…","fields":{"slug":"/engineering/introduction-to-cross-site-request-forgery-csrf/"},"html":"

Introduction

\n

Cross-Site Request Forgery (CSRF) is a common web application attack where a victims’ authenticated session becomes compromised. This attack essentially tricks a victim into performing unintended tasks on a website they are authenticated in. There are variations to this attack, and a popular one we will discuss is utilizing authentication token to imitate api requests.

\n

Context

\n

In order to understand CSRF, it is important to know how cookies and authentication tokens are used for persisting user sessions. Cookies are information stored in the browser, and often used for managing state between HTTP requests. A key feature of cookies is that they are automatically passed as a header in HTTP requests. Authentication tokens are typically stored as cookies, and are a way to keep track of a users’ authenticated session. These tokens are set as cookies after a user successfully authenticates themselves by log in.

\n

How it works

\n

CSRF takes advantage of the storage of auth tokens in the browser, and constructs http requests to a target server on behalf of the user. Imitating http requests from the legitimate site requires research and preparation from the attacker beforehand, such as finding vulnerable websites and api’s suitable for the attack.

\n

\n

Here is a high-level example of an CSRF attack. Note that some details are excluded for simplicity, but the key aspects are included.

\n
    \n
  1. \n

    John is authenticated on banking.io

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

    On another tab, John clicks on an advertisement for free money, which leads to a malicious site.

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

    Malicious site makes a POST request to banking.io/setpassword, which is an api for setting a users password to anything.

    \n\n
    4. \n
  4. Victim is unable to authenticate with banking.io anymore, because the password was set to something else.
    5. \n
\n

Mitigation

\n

A common and effective way of mitigating CSRF is called the double submit cookie. Essentially the client will have two paired and encrypted tokens: one hidden in the page HTML and the other stored as a cookie.

\n

\n

When a request is made by the client, both tokens are sent to the server, and the server will then ensure the tokens are valid pairs before processing the request as normal.

\n

\n

Now the attacker will be unable to perform CSRF since they will not have access to the token hidden in the pages HTML, and the target server requires a valid token pair before processing the request.

\n

There are also many other mitigation techniques, such as using the Same-Site cookie attribute, and requiring user interaction such as CAPTCHA for requests. Learn more on the OWASP wiki).

\n","frontmatter":{"date":"October 30, 2019","updated_date":null,"description":null,"title":"Introduction to Cross-Site Request Forgery (CSRF)","tags":["CSRF"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.3333333333333333,"src":"/static/45655fcaf75e8e3352165b60c7cac47b/1f5c5/crosspath.webp","srcSet":"/static/45655fcaf75e8e3352165b60c7cac47b/61e93/crosspath.webp 200w,\n/static/45655fcaf75e8e3352165b60c7cac47b/1f5c5/crosspath.webp 400w","sizes":"(max-width: 400px) 100vw, 400px"}}},"author":{"id":"Andy Yeung","github":null,"avatar":null}}}},{"node":{"excerpt":"What is Web Accessibility? Web Accessibility (often stylized “a11y”), is the practice of ensuring that your websites and web applications…","fields":{"slug":"/engineering/introduction-to-web-accessibility-with-semantic-html5/"},"html":"

What is Web Accessibility?

\n

Web Accessibility (often stylized “a11y”), is the practice of ensuring that your websites and web applications are accessible by people with disabilities of many kinds.

\n

Some examples of common disabilities which we need to consider are: Blindness and visual impairment, deafness and hearing difficulties, motor skill impairment, and many more.

\n

The common categories of disabilities include:

\n\n

This list was taken from the W3C Web Accessibility Initiative (WAI). A link to their resources can be found at the bottom.

\n

What is Semantic HTML? What is its correlation with Web Accessibility?

\n

HTML semantics refers to conveying meaning through the use of HTML elements. An example of semantic HTML would be using <header>, <main>, <footer>, and other content-specific tags when applicable. Unsemantic HTML would be using <div> or <span> tags for every use-case.

\n

Images and “alt” attributes

\n

Users who are visually impaired may encounter trouble when the content of a website relies on an image. Luckily, there are precautions that we - as developers - can take to ensure that their user experience does not suffer because they are unable to see images.

\n

The easiest way to do this is to add an alt attribute to all of your <img> tags. This way, screen readers will be able to describe the image to the user. Here are a few suggestions and best practices for writing alt text:

\n\n

Form Labels and ARIA Labelling

\n

Users with screen readers will need some way to differentiate between multiple inputs on a single form. Without labels, the user will have a difficult time figuring out what each input is for.

\n

The easiest way to implement form labelling is with the HTML <label> tag. The <label> element uses an attribute called for in order to form a relationship with the ID of the <input> tag.

\n

Another way to give context to a screen reader is with the ARIA aria-labelledby attribute. This attribute can be placed on (but not limited to) <input> tags, and then reference the id of the label. You can use <label for=””> in conjunction with <input aria-labelledby=””> in order to provide extra support and maximize compatibility.

\n

Buttons and Tabindices

\n

Buttons should use <button> tags (or <input type=”submit”> if applicable), rather than <a>, <span>, <div>, or anything else that doesn’t have semantic meaning for clickable buttons. Often people choose to use these tags, because they want to clear all styling and not have default <button> styling. This is ill-advised because <button> tags come with a ton of functionality built-in, an important part being its tabindex. A user who isn’t able to use a mouse, and must navigate the site with their keyboard, will press the tab key to jump through interactive elements. Standard <div> tags are not tabbable by default, and assigning a tabindex to it manually can break the flow of the natural tabindices of the page.

\n

Other Semantic HTML tags

\n

Other than images and forms, there are still many ways to provide the best accessibility possible. Semantic HTML tags are useful because they describe the content and the relationship with your overall page. Using appropriate, accurate tags such as <article>, <aside>, <section> will give screen readers an idea of what the role is for those sections.

\n

Other elements such as <h1> and other heading tags should be carefully planned before sprinkled throughout your webpage. The <h1> through <h6> tags should form direct relationships with each other in order to differentiate their meaning. Headings with lower importance (relative to the previous heading) can be used to start new subsections within its current section. Your different page sections can even use aria-labelledby to point to its corresponding heading in order to label your sections accurately.

\n

The full W3C specification on HTML semantics can be found at: W3C Recommendation.

\n

More information about the varying disabilities and barriers can be found at: Diverse Abilities and Barriers

\n","frontmatter":{"date":"July 24, 2019","updated_date":null,"description":null,"title":"Introduction to Web Accessibility with Semantic HTML5","tags":["HTML5","HTML","Web Accessibility","Semantic HTML5"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1,"src":"/static/70f4300c1f86c6d8e337f40979e66dea/58556/handicapped.webp","srcSet":"/static/70f4300c1f86c6d8e337f40979e66dea/61e93/handicapped.webp 200w,\n/static/70f4300c1f86c6d8e337f40979e66dea/1f5c5/handicapped.webp 400w,\n/static/70f4300c1f86c6d8e337f40979e66dea/58556/handicapped.webp 800w,\n/static/70f4300c1f86c6d8e337f40979e66dea/cc834/handicapped.webp 1024w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Greg Sakai","github":null,"avatar":null}}}},{"node":{"excerpt":"A basic example of a JavaScript event Events, in JavaScript, are occurrences that can trigger certain functionality, and can result in…","fields":{"slug":"/engineering/javascript-events-bubbling-capturing-and-propagation/"},"html":"

A basic example of a JavaScript event

\n

Events, in JavaScript, are occurrences that can trigger certain functionality, and can result in certain behaviour. A common example of an event, is a “click”, or a “hover”. You can set listeners to watch for these events that will trigger your desired functionality.

\n

What is “propagation”?

\n

Propagation refers to how events travel through the Document Object Model (DOM) tree. The DOM tree is the structure which contains parent/child/sibling elements in relation to each other. You can think of propagation as electricity running through a wire, until it reaches its destination. The event needs to pass through every node on the DOM until it reaches the end, or if it is forcibly stopped.

\n

Event Bubbling and Capturing

\n

Bubbling and Capturing are the two phases of propagation. In their simplest definitions, bubbling travels from the target to the root, and capturing travels from the root to the target. However, that doesn’t make much sense without first defining what a target and a root is.

\n

The target is the DOM node on which you click, or trigger with any other event.

\n

For example, a button with a click event would be the event target.

\n

The root is the highest-level parent of the target. This is usually the document, which is a parent of the , which is a (possibly distant) parent of your target element.

\n

Capturing is not used nearly as commonly as bubbling, so our examples will revolve around the bubbling phase. As an option though, EventTarget.addEventListener() has an optional third parameter - which takes its argument as a boolean - which controls the phase of the propagation. The parameter is called useCapture, and passing true will cause the listener to be on the capturing phase. The default is false, which will apply it to the bubbling phase.

\n

Once you trigger the event, it will propagate up to the root, and it will trigger every single event handler which is associated with the same type. For example, if your button has a click event, during the bubbling phase, it will bubble up to the root, and trigger every click event along the way.

\n

This kind of behaviour might not sound desirable - and it often isn’t - but there’s an easy workaround...

\n

Event.stopPropagation()

\n

These two methods are used for solving the previously mentioned problem regarding event propagation. Calling Event.stopPropagation() will prevent further propagation through the DOM tree, and only run the event handler from which it was called.

\n
<!--Try it-->
\n
function first() {\n  console.log(1);\n}\nfunction second() {\n  console.log(2);\n}\nvar button = document.getElementById("button");\nvar container = document.getElementById("container");\nbutton.addEventListener("click", first);\ncontainer.addEventListener("click", second);
\n

In this example, clicking the button will cause the console to print 1, 2. If we wanted to modify this so that only the button’s click event is triggered, we could use Event.stopPropagation() to immediately stop the event from bubbling to its parent.

\n
function first(event) {\n  event.stopPropagation();\n  console.log(1);\n}
\n

This modification will allow the console to print 1, but it will end the event chain right away, preventing it from reaching 2.

\n

How does this differ from Event.stopImmediatePropagation()? When would you use either?

\n
<!--Try it-->
\n
function first(event) {\n  console.log(1);\n}\nfunction second() {\n  console.log(2);\n}\nfunction third() {\n  console.log(3);\n}\nvar button = document.getElementById("button");\nvar container = document.getElementById("container");\nbutton.addEventListener("click", first);\nbutton.addEventListener("click", second);\ncontainer.addEventListener("click", third);
\n

Let’s suppose we wanted to add a third function, which prints 3 to the console. In this scenario, we will also move the second function to also be on the button. We will apply third to the container now.

\n

Long story short: we have two event handlers on the button, and clicking <div#container> will now print 3.

\n

What will happen now? This will behave the same as before, and it will propagate through the DOM tree, and print 1, 2, 3, in that order.

\n

How does this tie in to Event.stopPropagation() and Event.stopImmediatePropagation()?

\n

Adding Event.stopPropagation() to the first function, like so, will print 1, 2 to the console.

\n
function first(event) {\n  event.stopPropagation();\n  console.log(1);\n}
\n

This is because Event.stopPropagation() will immediately prevent all click events on the parent from being triggered, but it does not stop any other event handlers from being called.

\n

As you can see in our example, our button has two click handlers, and it did stop the propagation to its parents. If you wanted to stop all event handlers after the first, that’s where Event.stopImmediatePropagation() comes in.

\n
function first(event) {\n  event.stopImmediatePropagation();\n  console.log(1);\n}
\n

Now, the first function really will stop the parent click handlers, and all other click handlers. The console will now print just 1, whereas if we simply used Event.stopPropagation(), it would print 1, 2, and not including either would print 1, 2, 3 .

\n","frontmatter":{"date":"July 22, 2019","updated_date":null,"description":null,"title":"JavaScript Events: Bubbling, Capturing, and Propagation","tags":["JavaScript","JavaScript Events"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.3333333333333333,"src":"/static/53a3895e9c38870937a9136813ac9e10/0ce14/bubbles.webp","srcSet":"/static/53a3895e9c38870937a9136813ac9e10/61e93/bubbles.webp 200w,\n/static/53a3895e9c38870937a9136813ac9e10/1f5c5/bubbles.webp 400w,\n/static/53a3895e9c38870937a9136813ac9e10/0ce14/bubbles.webp 772w","sizes":"(max-width: 772px) 100vw, 772px"}}},"author":{"id":"Greg Sakai","github":null,"avatar":null}}}},{"node":{"excerpt":"It is hard to write 100% holes-free code, no matter how hard you try. Sometimes it is not even your own fault (language implementation…","fields":{"slug":"/engineering/3-simple-ways-to-secure-your-websites-applications/"},"html":"

It is hard to write 100% holes-free code, no matter how hard you try. Sometimes it is not even your own fault (language implementation, server setups, etc.) and those factors are likely out of your control. That being said, as developers, we should strive to write our code as safe and secure as possible. Here are my suggestions to keep yourself from being woken up in the middle of the night:

\n

1. DO NOT trust any user-input, PERIOD. Not even if it is yours truly. This is the most common attack vector for your web applications, whether it is just a contact form or an API end-point. For example, if a form is implemented to store data in a database, someone can try brute-forcing with classic SQL-injection techniques. Others can certainly try calling your API and see if there are any spotty error-handling issues. Sanitize all inputs as much as you can, and handle all errors behind the scenes properly and gracefully without exposing the actual details to the public.

\n

2. UPDATE, UPGRADE and REPEAT. Chances are, a lot of your code is dependent on third-party libraries (open or closed source, does not matter). It is your job to make sure you are using the latest version for them all. When hackers find out you are using outdated or vulnerable code, you are done. I have seen this happening way too many times than I can count over the years when websites got hacked and outdated plugins or libraries was the main culprit.

\n

You might be saying, \"Hey, upgrading that library will break my code!!\". Well, what is your job again? Deal with it.

\n

3. Web Application Firewall (WAF) Consider getting one if your server admin lets you, it can potentially save yourself a lot of embarrassments. Just keep in mind though it should not be your only security strategy, as WAFs will not stop all kinds of attacks. It is still your sole responsibility to write good code and repeat step 1 and 2.

\n

Happyyyyy coding!

\n","frontmatter":{"date":"June 24, 2019","updated_date":null,"description":null,"title":"3 Simple Ways to Secure Your Websites/Applications","tags":["Engineering"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/5a3022253d6646c0ce3939c478b4481e/ad85c/hacker.webp","srcSet":"/static/5a3022253d6646c0ce3939c478b4481e/61e93/hacker.webp 200w,\n/static/5a3022253d6646c0ce3939c478b4481e/1f5c5/hacker.webp 400w,\n/static/5a3022253d6646c0ce3939c478b4481e/ad85c/hacker.webp 600w","sizes":"(max-width: 600px) 100vw, 600px"}}},"author":{"id":"Karl Wittig","github":null,"avatar":null}}}},{"node":{"excerpt":"Do you remember the Amazon outage that affected several high-profile customers back in 2011? On April 21st, widely-used sites such as Reddit…","fields":{"slug":"/engineering/failover-systems-and-loginradius-99-99-uptime/"},"html":"

Do you remember the Amazon outage that affected several high-profile customers back in 2011? On April 21st, widely-used sites such as Reddit and Quora were brought down, and many others experienced latency or were knocked offline, too. Early that morning, as part of normal scaling activities, Amazon staff performed a network change. However, the change was done incorrectly and, after the staff attempted to correct it through a rollback, the inner mechanisms of the service made it unavailable to serve read and write requests. The ‘inner mechanisms’ responsible for the service unavailability are out of the scope of this article, but they are described in the service disruption summary that Amazon published. What interests us here is the strategies that companies can use to mitigate the negative effects on their products when a service they rely on fails. These strategies make up what is known as a failover system.

\n

A failover system is a set of mechanisms that perform failover. In computer networking, failover is the process of switching to a redundant or standby server or network upon the abnormal termination of a previously-active server or network. The benefit of a failover system is obvious: with one in place, you can ensure your product or service will be available even when adverse events take place. Uptime—time during which a service is operational—is crucial to the success of your business. If your services are unavailable, you are likely to lose customers and any revenue they would have generated. In an article entitled ‘Lessons Netflix Learned from the AWS Outage,’ Netflix talks about the manual process they used to deal with the Amazon outage and acknowledges the importance of automating this process in the future so they can keep scaling their service. That is, the company acknowledges the importance of having an automated failover system in place instead of relying on a team of top engineers manually making changes every time there is an issue.

\n

How is an automated failover system set up? Let us consider the simplest scenario: setting a failover system for one server. By definition of a failover system, in addition to the main server, we need to have another redundant standby server that we can switch to whenever the main one fails. Since the redundant server must provide the same functionality as the first, it must be identical to it. Additionally, we need a tool that ensures client requests are routed to the redundant server in case of failure of the main one. We can achieve this by using a DNS failover tool. DNS is the internet protocol used to translate human-readable hostnames into IP addresses, and a DNS failover tool makes sure the “dictionary” (DNS tables) used for this translation are updated in the event of an outage. DNS failover tools know when to update the tables by periodically checking on the main server’s status. With these three tools—and some configuration—you can set up a simple, automated failover system. Of course, there are other considerations you must take when setting the failover system, such as ensuring the redundant standby server is hosted in a geographic area different from the main server’s location and using different companies to host your services. That way, your services will be less likely to go down simultaneously.

\n

At LoginRadius, we have set up automated failover systems in all layers of our architecture, which is why we can ensure 99.99% uptime on a monthly basis. With our services, you can be assured your customers will always be able to engage with your business, ensuring you will never lose these customers and any revenue they will generate.

\n","frontmatter":{"date":"June 24, 2019","updated_date":null,"description":null,"title":"Failover Systems and LoginRadius' 99.99% Uptime","tags":["Engineering","AWS"],"pinned":null,"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.0050251256281406,"src":"/static/aa689bef0926b16dc0f50c38ca2e3f1c/18421/tech.webp","srcSet":"/static/aa689bef0926b16dc0f50c38ca2e3f1c/61e93/tech.webp 200w,\n/static/aa689bef0926b16dc0f50c38ca2e3f1c/1f5c5/tech.webp 400w,\n/static/aa689bef0926b16dc0f50c38ca2e3f1c/18421/tech.webp 719w","sizes":"(max-width: 719px) 100vw, 719px"}}},"author":{"id":"Ruben Gonzalez","github":"rubenprograms","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":228,"currentPage":39,"type":"//engineering//","numPages":53,"pinned":"5c425581-f474-5ae9-abe7-cf5342db2aaa"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}