1. Does every app that wants to stay logged in longer than 15 minutes need a refresh token? Short answer: Yes, if you want short-lived access tokens (e.g., 15 minutes) and users to stay logged in longer, you need refresh tokens.

Why 15 minutes? JWTs are usually short-lived for security reasons:

If a JWT is stolen, it can be used until it expires.

A 12-hour token is risky: an attacker who steals it has a long window to act.

Why refresh tokens help:

Stored securely (e.g., HttpOnly cookie)

Used to request new access tokens after expiry

Can be revoked or rotated

Reduces risk if access tokens are short-lived

So is revocation the only reason? No. There are two core advantages to refresh tokens:

Revocation: Allows you to block compromised sessions.

Token Renewal Pattern: Allows access tokens to stay short-lived while keeping users logged in.

By keeping the refresh token in an HttpOnly cookie, and access token in memory, you reduce attack surface. That is a security advantage, not just an implementation detail.

So yes — you’re right — the reduced exposure of the access token is a key advantage of using refresh tokens, even if often under-emphasized.

2. Can refresh tokens be stateless by including identity claims? Is giving up revocation a security flaw? Yes, technically you can make refresh tokens stateless, just like JWTs:

Encode user ID, issued at, etc. inside the refresh token.

Verify and issue a new access token without hitting the DB.

But... this is a security tradeoff.

Pros: Fully stateless system: Fast, scalable, simple.

No DB dependency for token validation.

Cons: You can’t revoke refresh tokens (i.e., no session management).

If the refresh token is stolen, it’s valid until it expires.

You can’t detect token reuse (which can signal theft).

So yes, it is a security flaw, but whether it’s acceptable depends on your threat model. If you can tolerate the risk (e.g., internal tools, low-impact systems), it may be fine. But in public-facing or high-value systems, revocation is typically essential.

3. If I’m not revoking, is there a reason to use refresh tokens at all? If you never revoke, and don't plan to store refresh tokens, then:

You could just issue new access tokens each time a request comes in.

But that has some major caveats:

You need to validate the current access token to know it's legit before issuing a new one.

You’re encouraging long-lived sessions without real control over them.

Refresh tokens offer these benefits even without revocation:

A separate channel/token for renewing access (i.e., don’t need to expose credentials or long-lived access tokens).

A safe way to handle silent re-authentication (e.g., SPA rehydrating session on page load).

Reduced attack surface: access token can live only in memory, refresh token in cookie.

So even without revocation, refresh tokens help segregate responsibilities: access = use the app; refresh = renew session. That separation is inherently valuable.