Can Two Applications Share the Same JWT Secret Key?

First, let's understand what JWT and the secret key are. A JSON web token, also known as JWT, is a tool commonly used by developers for security purposes, i.e., to securely pass information between the user and server. I explain it in a simple way. When a user logs into a website, it creates a JSON web token and sends it back to the user's browser. This JWT acts as a digital card for the user. Whenever you visit any site, then this token will be shown to prove who you are.

This can only be verified when the application can trust it. To ensure that nobody can alter or forge the token, then they use something which is called a secret key. The secret key is like a unique password only known to the backend of the system. When the application creates a token, it locks it using this secret key. When the token returns, the application uses the same key to unlock and verify it. If the key gets matched, then the application will know that the token is safe and genuine.

One question may arise in the minds of developers who manage multiple platforms: can two different applications share the exact same JWT secret key?

The straightforward technical answer is yes. If we configure two applications, A and B, with an identical string of text as their secret key, then they both will be able to generate and verify each other's tokens. At the same time, it also has major architectural changes and security risks. In this article, I will discuss how sharing a secret key works.

Can Two Applications Use the Same Key?

If we talk from purely a technical standpoint, then yes, two applications can absolutely use the same JWT secret key. A secret key is basically a string of characters used by a cryptographic algorithm. Suppose you can copy and paste the same text string into the configuration files of both applications A and B, then the system will work.

When both applications share a single key, then they gain the ability to read and validate each other's tokens. Let's take an example: if a user logs into application A, then that server will generate a JWT signed with the shared secret. After that, if the user then takes the exact same token and sends it to Application B, then Application B can use its copy of the secret key to successfully verify the signature. Since keys matched, Application B will trust the token and grant the access, completely unaware that the token was actually created somewhere else.

In software structure, the purpose of a secret key is to establish identity and trust. When two different applications share the same key, then you blur the line between them i.e., Application B has no way to prove whether a token was generated by itself or by Application A. In short, they become cryptographically tied together.

Why Developers Share Secret Keys

Despite having security risks, developers choose to share the JWT secret key between applications in order to solve specific architectural challenges. One of the common reasons for doing this is to build a quick and simple Single Sign-On (SSO) system. By using the same secret key across two applications, developers can achieve their goal without building a centralized identity server.

Let's take an example, a company having a main shopping website and a separate customer support forum. If both applications can share the same key, then a user who gets a JWT when logging in to the shopping website can verify that exact same token in the support forum. This provides a seamless experience for the user, as the customer does not have to log in a second time.

Another reason why developers share keys is simply because of convenience and speed during the early stage of development. Having multiple different keys for various applications can be a big headache. By sharing a single key, all these services can communicate with each other using minimal code and instantly verify user data.

The Main Security Risks

• If a hacker can hack into one application, then all other applications sharing that key are instantly compromised.
• By pretending to be any user, a hacker can generate a token across all shared systems.
• A malicious actor with access to the shared key can create forged tokens that appear completely authentic to the connected application.
• If you need to block or invalidate a compromised key, then you end up logging out all the users and causing major disruption of traffic across all the applications at once.
• This can make brute-force attacks easier.

Issues with User Permissions

Sharing the JWT secret key while managing user permissions across different applications leads to major difficulties. In standard application systems, different apps have different roles, user groups, and safety requirements. Suppose a user is a regular customer on an online shop, but at the same time, an administrator on the company's internal forum. When applications share a secret key, the boundaries between different permission levels begin to blur.

Here, the issue is that a single token signed by the shared key is universally trusted by every application available on the system. If application A creates a token that says the user has restricted access, application B will accept that token as valid. In this scenario, if application B has a bug, then it might grant the user full access instead because both apps use the exact same key to verify signatures.

Better Alternatives to Sharing a Secret

1. The simplest solution is to give every application its own distinct secret key.
2. Instead of using a single shared secret key, use a public and private key pair. The private key is for server authentication, and the public key is used to verify individual applications.
3. Outsourcing the login process to a dedicated identity server like Auth0 or Keycloak.
4. Using a single key is necessary, so applications should be forced to check standard JWT tags like aud (audience) and iss (issuer).
5. If you have a multi-app setup, then you can place an API gateway as a single guard entry point for all web traffic.