DEV Community: Ehan Siddique

JWT Refresh Tokens: How They Make Login Systems Safer and More Practical

Ehan Siddique — Wed, 23 Sep 2026 04:20:34 +0000

When building a modern web application, authentication is one of the first things we need to think about.

A simple login system sounds easy:

User enters email and password → server checks them → user is logged in.

But what happens after the login?

How does the website remember that the user is authenticated? How long should the login remain valid? What happens if an authentication token gets stolen?

This is where JWT access tokens and refresh tokens become useful.

What is a JWT?

JWT stands for JSON Web Token.

It is a compact token that can be used to represent authenticated information between a client and a server.

After a successful login, the server can generate an access token:

User → Login
↓
Server verifies credentials
↓
Server generates JWT
↓
Client receives token

The client can then send the access token with requests to protected APIs.

For example:

Authorization: Bearer

The server verifies the token and decides whether the request is authenticated.

So what's the problem with a normal JWT?

The main problem is token lifetime.

Imagine giving a user an access token that remains valid for 30 days.

That's convenient, but it creates a security problem.

If someone steals that token, they may be able to use it until it expires.

On the other hand, if we make the access token expire after 5 or 10 minutes, security improves, but users would constantly have to log in again.

That's not a great user experience.

This is where the refresh token comes in.

What is a Refresh Token?

A refresh token is a longer-lived credential that can be used to obtain a new access token without asking the user to log in again.

Instead of having one token do everything, we separate the responsibilities:

Access Token

Short-lived
Used for API requests
Expires quickly

Refresh Token

Longer-lived
Used to obtain new access tokens
Should be protected carefully
Usually isn't sent with every API request

The basic idea looks like this:

            LOGIN
              │
              ▼
      ┌─────────────────┐
      │ Server verifies │
      │   credentials   │
      └────────┬────────┘
               │
        ┌──────┴──────┐
        ▼             ▼
  Access Token   Refresh Token
   Short-lived    Long-lived
        │             │
        ▼             │
   API Requests       │
                      │
                Access token
                   expires
                      │
                      ▼
              Refresh request
                      │
                      ▼
              New access token

The user doesn't need to enter their password again.

Why Not Just Use a Long-Lived JWT?

This is one of the biggest reasons refresh tokens exist.

Suppose your access token is valid for 30 days.

If it gets stolen, the attacker may have a usable credential for a long period.

Instead, you could make the access token short-lived:

Access Token → 10–15 minutes
Refresh Token → days/weeks

Now, even if an access token is compromised, its useful lifetime is much shorter.

The refresh token is more sensitive, so it needs stronger protection and should be handled carefully.

How the Login Flow Works

Let's imagine a user logs into an application.

Step 1 — User submits credentials
POST /api/login
{
"email": "user@example.com",
"password": "password"
}

The server verifies the credentials.

Step 2 — Server generates tokens

If authentication succeeds:

Access Token
+
Refresh Token

The access token is used for normal API requests.

The refresh token is kept in a safer storage mechanism, commonly an HttpOnly, Secure cookie for browser applications.

Step 3 — User accesses protected resources

The client sends the access token:

GET /api/profile

Authorization: Bearer

The server verifies it.

If valid:

200 OK
Step 4 — Access token expires

Eventually:

Access Token → EXPIRED

Instead of showing the login page immediately, the application can use the refresh token.

Step 5 — Refresh the session

The client sends a request such as:

POST /api/refresh

The server validates the refresh token.

If everything is valid, it issues a new access token.

Old Access Token → Expired

Refresh Token
↓
Server validates
↓
New Access Token

The user can continue using the website without logging in again.

Why This Matters for Website Owners

For website owners and developers, refresh tokens aren't just about making authentication more complicated.

They can provide a better balance between security and user experience.

Shorter exposure for access tokens

Access tokens can have short lifetimes.

This reduces the period during which a stolen access token remains usable.

Better user experience

Users don't have to repeatedly enter their passwords.

They can remain signed in while the application silently obtains new access tokens.

Better session control

A properly designed refresh-token system can allow the server to revoke sessions.

For example:

User clicks "Log out from all devices"

↓

Server invalidates refresh tokens

↓

Existing sessions can no longer
refresh themselves

This is much more useful than simply waiting for a long-lived token to expire.

Device/session management

A website can maintain separate sessions for different devices.

For example:

Chrome - Malaysia
iPhone - Malaysia
Laptop - Bangladesh

Each session can have its own refresh token.

If one device is lost, its session can be revoked without necessarily logging the user out everywhere.

Access Token vs Refresh Token
Feature Access Token Refresh Token
Main purpose Access APIs Obtain new access tokens
Lifetime Short Longer
Sent with API requests Usually yes Usually no
Security sensitivity High Very high
Can be revoked server-side Depends on design Commonly
Should be exposed to JavaScript Minimize exposure Prefer HttpOnly cookie

The exact implementation depends on the application's architecture and threat model.

Important Security Practices

JWT itself doesn't automatically make an authentication system secure.

The implementation matters.

Use HTTPS

Never send authentication credentials or tokens over an unencrypted HTTP connection.

Use HTTPS/TLS in production.

Keep access tokens short-lived

Don't make an access token valid for an unnecessarily long period.

A short lifetime limits the damage from token theft.

Protect refresh tokens

For browser-based applications, an HttpOnly + Secure cookie is commonly used.

HttpOnly helps prevent JavaScript from directly reading the cookie.

Secure ensures the cookie is sent only over HTTPS.

Depending on the application, SameSite settings should also be configured appropriately.

Consider refresh-token rotation

Instead of reusing the exact same refresh token forever, the server can issue a new refresh token whenever one is successfully used.

The previous token can then be invalidated.

This is known as refresh-token rotation.

It can help detect and limit certain replay attacks.

Never store passwords inside JWTs

A JWT should never contain the user's password.

Passwords should be stored using an appropriate password hashing algorithm such as Argon2id or bcrypt.

Validate tokens properly

The server should verify important JWT properties such as:

Signature
Expiration
Issuer
Audience
Algorithm

The exact checks depend on the authentication architecture.

What Happens When a User Logs Out?

A common mistake is thinking:

"Deleting the JWT from the browser means the session is completely gone."

Not necessarily.

If a refresh token remains valid on the server, it may still be possible to create another access token.

A stronger logout design can invalidate the user's refresh session.

For example:

Logout
↓
Delete/clear client session
↓
Revoke refresh token
↓
Future refresh attempts fail

This gives the server more control over active sessions.

JWT Is Not a Complete Authentication System

This is probably the most important point.

JWT is simply a token format.

Using JWT doesn't automatically mean an application has secure authentication.

A secure authentication system also needs to consider:

Password hashing
HTTPS
Token expiration
Secure cookie configuration
CSRF protection where applicable
XSS protection
Refresh-token rotation
Session revocation
Rate limiting
Account recovery
Multi-factor authentication
Proper server-side authorization

JWT is one part of the system, not the entire system.

A Simple Mental Model

I like to think about it this way:

Access token = temporary access pass

Refresh token = credential used to obtain another temporary pass

For example:

The user experiences one continuous session, while the application can keep the actual API credential short-lived.

Final Thoughts

When building a modern application, authentication is not just about making the login button work.

It's about deciding:

How long should a session last?

What happens if a token is stolen?

How can a user stay logged in without keeping a powerful credential valid forever?

Refresh tokens provide one way to solve this problem.

Used correctly, the combination of short-lived access tokens + carefully protected refresh tokens + proper session management can give developers a practical balance between security and user experience.

But the important part is not simply adding JWT.

The real security comes from designing the entire authentication flow carefully.

So what should it be – WordPress or custom code? 19 questions every business owner needs to answer - The truth.

Ehan Siddique — Thu, 20 Aug 2026 17:09:36 +0000

“WordPress or custom coded?”
*
It is amongst the most recurrent queries businessmen usually ask while launching a new web page.

Plus, everyone will most likely say something completely different.

Some will tell you:

“WordPress is BASIC and OLD.”

Others will say:

“No, it is not necessary to make custom development – you can use WordPress.”

The reality is, however, that:

There is no right or wrong answer.

This will entirely rely on your business, objectives, budget and the true scope of functionality that you need your website to have.

What once started out as a “cheap website” is now considered by many as the most powerful blogging platform available online.

WordPress is not so easy to comprehend as people perceive it.

Yes, it can (affordably) be used to create web sites rapidly. Doesn't imply it implies that WordPress sites are low quality though.

The best-developed WordPress website can be:

Fast
Secure
SEO-friendly
Mobile-friendly
Easy to manage
Highly customizable

WordPress can be a great option for businesses because of its properties, such as a company website, portfolio, blog, landing page or online shop.

Its great benefit is content management.

Update pages, publish blogs, add products, change images and manage content without having to rely on a developer for each and every little bit of change.

That is very spacious to lots of businesses.

But what about web sites that are programmed in a custom code?

With custom development, the web or app will have a great deal of control over the websites or apps operation.

You don't have to conform to a pre-existing CMS and plugin community - instead, its own system can be tailored to suit your business.

This comes in handy when creating something more elaborate like:

SaaS platforms
Marketplaces
Customer portals
Advanced dashboards
Booking platforms
Complex business systems
Real-time applications

Standard WordPress tools may not work efficiently to suit unique functionality or workflow that your website has; in such instances, custom development may prove a better option.

What About Which one is Better?

There is the response that not many engineers don't want to have:

It depends.

With a website that needs a menu, location, contact info and restaurant bookings and has a blog, an expensive fully bespoke website may not be a feasible option for the restaurant owner.

WordPress can provide you with all you require.

However, in the case of an application that lots of users will be using each of whom will be creating accounts and developing business logic, managing dashboards and transactions, and interacting with other accounts, custom development might be the more intelligent option.

The object is NOT to pick a new high tech solution.

The objective is to select the technology that will be able to effectively solve your company's problems.

The 3 Biggest Myths

The fact that WordPress does not have good reputation for its performance.“WordPress is always slow.”

Not true.

Just as a poorly-constructed custom site can be slow, so, too, can a poorly-constructed WordPress site.

Things like hosting, image optimization, code quality, database configuration, plugins and caching, and third-party scripts, are among the factors that impact performance.

The most important thing to understand, and doing so will help your decision, is that “WordPress” or “custom” are not the things that matter most, GOOD DEVELOPMENT does.

“The second myth is that ‘Custom code is always more secure'”.

Not automatically.

Even with custom applications, these can be vulnerable to security issues if not managed properly – including authentication, API, database, permissions and/or dependencies.

Proper updating, secure plugins, robust authentication, backups and monitoring are also required for WordPress.

Security is not simply a choice of technology, it is a part of development and maintenance.

Myth #3: “Custom code is always more professional.”

However, a custom-coded site does not necessarily mean that it is better and, therefore, worth the time or money.

Use of WordPress isn't a compromise if it's getting the job done in solving your business needs.

Indeed, it isn't necessarily the more complex option if it achieves what you're after which is more professional.

People often focus just on the up-front development charges and not what the long-term consequences are.

The first error done by business entities is their taking just the starting price.

For example:

WordPress: Lower up-front development expenses.

Complexity: Custom means that more money will be required for the initial development.

However, there's more to that.

If that's the case, you must factor in also:

Hosting
Maintenance
Security
Updates
Future features
Developer support
Scalability

A website that is continually needing repairs and is cheap isn't necessarily cheap.

You don't want to have a costly custom-built system with components that you never utilize either.

Consider lifetime costs, rather than just development costs.

What should your company opt for?

If you are in need of, WordPress might be better suited for you:

✅ A company website

✅ A portfolio

✅ A blog

✅ A landing page

A website that's based on providing a service.

Online shop – with small to medium size clientele – = ✅

✅ Easy content management

🏃 A fast start, in comparison to the other projects.

If you need things such as: then it may be better to opt for tailor-made development:

✅ A SaaS product

✅ A complex marketplace

✅ Advanced dashboards

✅ Unique business workflows

✅ Complex integrations

✅ Real-time functionality

✅ Positive use cases to showcase the fit with the operation or industry of your interest

✅ A system in need of a full system control with the architecture.

Occasionally you may be able to select more than one.

The Hybrid Approach

It's one of the elements that many businesses might not have considered.

You can also utilize WordPress for your marketing site and website and use a customized made application for complicated features.

For example:

yourbusiness.com → WordPress

app.yourbusiness.com → Custom application

This helps marketers quickly make changes to the website content and the development team to create website-specific functions.

At times, this is the most convenient alternative.

In this video, you'll learn the questions you need to ask before hiring a developer.This video is about the questions you should ask prior to hiring a developer.

Avoid beginning with questions:

“Let's figure out is it better to use WordPress or to pay attention to custom code?”

Decide upon the following question starters:

What are the requirements of my business?

Avoid paying for features that you don't need to use.

Who will handle maintenance of the Web site?

When frequent updates to content are a regular occurrence for your team, ease-of-management is key.

**3. What is the anticipated increase in the size of the business?

The technology you select is for the future, so your future needs should be taken into consideration.

What are maintenance fees going to be?

Inquire about updates, hosting, security and backups and ongoing support.

5: Does the site have potential to expand as my company expands?

You shouldn't be stuck with a website that will not do the job when your enterprise grows.

The Bottom Line

“WordPress isn't necessarily bad.”

This doesn't mean that custom code has to be better.

Especially, because the most costly web page does not always necessarily mean the best!

The top Web page will be the one that:

Helps to solve your business problem
Provides a nice customer experience
Performs reliably
Does not need extensive cleaning up.
Can be adapted to suit a business's needs and scale of operations as it grows
Fits your budget

Therefore, before selecting any technology know what your business needs are.

Do not create an internet site due to the fact that a developer claims the site is “better” doing his or her intervention.

Create a website for your business that it really requires.

Would you opt for WordPress, or is it completely developed? Or is it a mix of the two?

If you have any comments feel free to write me.