Dual Tokens Beat Homegrown Crypto Auth for Most Web Apps
Dual Token vs. Front-End Crypto Public/Private Key Auth: Which Is Better?
One-sentence conclusion
For most web applications, Access Token + Refresh Token dual-token is the more common and more practical session management approach.
Front-end public/private key authentication is not a replacement for dual tokens. It solves "how the client proves it holds a certain key," while dual tokens solve "how access credentials are used, renewed, and invalidated." The two can be combined, but it's not simply true that a public/private key approach is necessarily more secure.
If you need public/private keys, prioritize mature standards like WebAuthn/Passkey rather than designing your own front-end encryption protocol.
What is dual token?
Dual token generally refers to:
- Access Token: used to access business APIs, short validity.
- Refresh Token: used to obtain a new access token after the access token expires, longer validity.
Typical flow:
user login
↓
server issues Access Token + Refresh Token
↓
front-end uses Access Token to request API
↓
Access Token expires
↓
front-end uses Refresh Token to request refresh endpoint
↓
server verifies and issues new token
The key value of dual token is separating the "frequently used access credential" from the "long-term credential used for renewal."
Common storage
Browser apps need to handle token storage carefully:
- Placing Refresh Token in an HttpOnly, Secure, SameSite Cookie reduces the risk of it being read directly by JavaScript.
- Access Token can have a short lifespan and be kept out of as much surface as possible.
- When using cookies, consider CSRF protection; when using Bearer tokens, guard against XSS token theft.
Specific storage depends on front-end architecture, cross-origin config, CSRF protection, and back-end auth design; there's no single solution for all projects.
What is front-end public/private key auth swapping tokens?
This scheme typically means the client generates or holds a key pair:
- Public key: submitted to the server for storage, or bound to the user identity at registration.
- Private key: held by the client, used to sign a random challenge from the server.
- Server: uses the public key to verify the signature; after verification, issues a token.
Simplified flow:
client initiates authentication
↓
server returns random challenge
↓
client signs challenge with private key
↓
server verifies signature with matching public key
↓
token issued after verification
The core of this approach is not "public key encryption, private key decryption to log in," but typically signing with the private key and verifying with the public key. The auth process must design random challenges, validity, one-time use, and user-to-public-key binding to avoid replay attacks.
Dual token vs. public/private key auth comparison
| Comparison | Dual token | Front-end public/private key auth |
|---|---|---|
| Main problem solved | API access, renewal, session state management | Prove the client holds the corresponding private key |
| Requires server state? | Depending on implementation; Refresh Token usually needs revocable management | Usually needs to store public key, device/credential binding |
| Front-end complexity | Low to medium | Medium to high |
| Back-end complexity | Low to medium | Medium to high |
| Risk after credential theft | Depends on token lifecycle, storage, and revocation | Risk can be lower if private key is hard to export, but malicious code calling the key remains a concern |
| Use cases | Most websites, admin panels, mobile app APIs | Device binding, passwordless login, high-security auth, scenarios where the client holds a key |
| Can it replace the other? | Not applicable | Usually cannot fully replace token lifecycle management |
Note: public/private key auth usually only solves "how to perform authentication." After authentication, the server may still issue Access Tokens, Refresh Tokens, or other session credentials. So public/private key auth and dual tokens can be combined.
Which is more secure?
Security cannot be judged just by "using encryption algorithms" or "using public/private keys." Key storage, attack surface, and the entire auth flow matter.
Main risks of dual token
Dual token schemes need to guard against:
- XSS attacks: malicious scripts may read front-end accessible tokens or impersonate the current page's user permissions.
- Refresh Token leakage: a long-lived refresh credential, once stolen, may be used to continuously trade for new tokens.
- Replay and abuse: old Refresh Tokens without rotation, revocation, and anomaly detection increase risk.
- CSRF attacks: if credentials are auto-carried via cookies, CSRF protection is needed.
Common mitigations include: short-lived Access Tokens, Refresh Token rotation, server-side revocation, anomalous login detection, strict cookie configuration, and solid XSS protection.
Front-end private keys are not inherently secure
Many teams wrongly assume that "a private key in the browser is more secure than a token." That is not always true.
Even if you generate a non-exportable private key via the Web Crypto API, malicious scripts may still call the signing capability while the page is running. Non-exportability reduces the risk of the key being copied, but does not guarantee it cannot be misused.
Also, if a private key is written as a string in front-end code, config files, or static assets, it is effectively public information. Browser code eventually ships to users; a private key embedded in the front end cannot be treated as a server secret.
If you need client-side keys, consider:
- Using mature standards such as WebAuthn/Passkey;
- Letting the private key be protected by platform secure hardware or system credential managers;
- Using server-side random challenges to prevent signature replay;
- Designing key revocation, device unbinding, and recovery flows after loss;
- Avoiding inventing your own cryptographic protocols.
How to choose?
Scenarios for dual token
If you're developing systems like these, start with dual token:
- Ordinary web sites;
- SaaS products;
- Enterprise admin panels;
- Front-end/back-end separated business systems;
- Apps that need API clients to carry access credentials.
Dual token has a mature ecosystem, teams understand it easily, and it integrates well with JWT, OAuth 2.0, OIDC. The key is designing token lifecycle and storage correctly, not pursuing complicated encryption.
Scenarios for public/private key auth
Consider public/private key auth, or WebAuthn/Passkey directly, when:
- You want passwordless login;
- You need trusted device binding;
- You have high identity authentication security requirements;
- The client has reliable key protection capabilities;
- You need to prove via signing that the client holds a key.
But note: after adopting public/private key auth, you still need to solve session management, token renewal, user logout, device loss, and credential revocation.
They can be combined
A common combination:
WebAuthn/public key completes user authentication
↓
server verifies identity
↓
server issues short-lived Access Token and Refresh Token
↓
client uses dual-token mechanism for API access and renewal
Here, public/private keys strengthen login auth, and dual tokens manage the post-login API session. Responsibilities are clear; you don't have to choose one.
Recommended approach
For most web projects, follow these design principles:
- Use mature authentication standards; avoid designing your own signing and token-swap protocols.
- Use short-lived Access Tokens to limit the exploitable window after leakage.
- Rotate and revoke Refresh Tokens and detect anomalous reuse.
- Don't put server private keys or long-term secrets into front-end code.
- Choose secure credential storage based on architecture and protect against both XSS and CSRF.
- Prioritize WebAuthn/Passkey for high-security login needs; don't assume using Crypto makes a scheme secure.
- Separate authentication from session management: successful auth doesn't mean token lifecycle issues are solved.
FAQ
1. Can a private key generated on the front end be safely stored in the browser?
Not necessarily. Web Crypto API can support non-exportable keys, but malicious scripts can still call the key to sign while the page runs. You also need XSS protection, device security capabilities, and full key lifecycle management.
2. After public/private key auth, do you still need a Refresh Token?
Not necessarily, but you usually still need some session renewal mechanism. Public/private key auth proves identity or credential possession; Refresh Token provides renewal; they solve different problems.
3. Is JWT dual token?
No. JWT is a token format; dual token is a token management approach. Access and Refresh Tokens can be JWTs or server-generated random opaque strings.
4. Is it more secure to AES-encrypt the password on the front end before sending?
Not necessarily. Client-side encryption doesn't replace HTTPS, and it doesn't solve malicious scripts, key management, or replay issues. Password transmission should use HTTPS and mature auth protocols and server-side password storage.
Summary
Dual token is better for daily API access and session renewal; public/private key auth is better for proving client key possession, or for device binding, passwordless login, and other authentication capabilities.
Therefore, most projects don't need to choose absolutely between the two. The more reasonable approach: first adopt a mature token session management scheme; if you have higher auth security needs, combine with WebAuthn/Passkey or standardized public/private key auth.
Most importantly, front-end code cannot keep server secrets, and Crypto cannot automatically guarantee system security. Final security depends on key management, token lifecycle, browser attack surface, and the full authentication flow design.