JWT setup
We set up JWT (JSON Web Tokens) authentication: correct signing, short access tokens + refresh, secure storage, rotation and revocation. So tokens work for API/SPA correctly and securely. Honestly upfront: JWT is a convenient tool for stateless authentication, but NOT 'more secure by default' than sessions: it has its own pitfalls (revocation, storage, lifetime), and wrong implementation creates vulnerabilities.
JWT setup — overview
JWT setup is a project: we implement correct token handling — a secure signing algorithm (and protection against algorithm substitution), short-lived access tokens + refresh tokens with rotation, secure client-side storage, server-side verification, expiry and revocation handling, claims and audience. Honestly about the nature, this is key: JWT is good for stateless authentication (API, microservices, SPA), but it is NOT 'more secure than sessions by default' — JWT has serious pitfalls: (1) REVOCATION is hard — an issued token is valid until expiry, you cannot instantly 'kill' it without extra mechanisms (blacklists/short TTL+refresh); (2) client-side STORAGE is dangerous: in localStorage vulnerable to XSS, in a cookie CSRF must be accounted for — a trade-off; (3) wrong implementation (weak secret, alg=none, missing verification) = critical vulnerabilities. So JWT vs sessions is a choice with trade-offs, not 'JWT is always better'; for classic web applications server sessions are often simpler and more secure — we honestly advise what is more appropriate. Honestly about the essence: we implement JWT correctly, but by itself it does not make the system secure — correct implementation and combination with other measures do. Honestly about access: access to the code/backend is needed. An important boundary: this is JWT setup, not choosing the whole authentication architecture (we discuss) and not 2FA/OAuth (746/748 — adjacent). Picture this: instead of 'home-made tokens with holes' — correct JWT with rotation and well-thought revocation, or an honest recommendation of sessions if they suit you better. The base price starts from 15,000 ₽ per project; it depends on the architecture.
Problems we solve
- Home-made/wrong token handling with holes in it.
- Tokens live forever and cannot be revoked.
- Insecure token storage (XSS/CSRF risks).
- Stateless authentication is needed for API/SPA.
What's included in the JWT setup service
- Correct signing and protection against algorithm substitution
- Short access tokens + refresh with rotation
- Secure client-side storage (accounting for XSS/CSRF)
- Server-side verification, claims, audience, expiry
- A revocation mechanism (blacklists/short TTL)
- An honest assessment: JWT or server sessions for your case
- Scenario testing
- Handover and review with you
What you get
- Correct and secure JWT handling
- Managed token lifetime and rotation
- Well-thought revocation and storage
- The right JWT vs sessions choice (without the 'JWT is better' dogma)
How the work goes: steps
- We clarify the architecture (API/SPA/classic); assess JWT vs sessions
- We implement correct tokens, refresh, revocation, storage
- We test security and scenarios, review with you
Why PDV Expert
- Fixed price and timeline — no surprises on the invoice.
- Report and recommendations in plain language — clear without a technical background.
- In touch at every step and answering questions about the result.
FAQ
Is JWT more secure than sessions?
Not by default. JWT is convenient for stateless (API/SPA) but has pitfalls: hard revocation (a token lives until expiry), storage risks (XSS in localStorage / CSRF in a cookie), vulnerabilities with wrong implementation. For classic web apps sessions are often simpler and more secure — we advise honestly.
Can you instantly revoke an issued JWT?
By itself — no: the token is valid until expiry. So extra mechanisms are needed: short TTL + refresh, blacklists/token versions. We implement this, but 'instant out-of-the-box revocation' is absent in JWT — that is its trait.
Where to store tokens on the client?
A trade-off: localStorage is vulnerable to XSS, a cookie requires CSRF protection (Secure/HttpOnly/SameSite). There is no ideal option; we choose a secure one for your architecture and close the corresponding risks.
About the provider
The «JWT setup» service is provided by PDV Expert — a team specialising in «Site quality». We work under contract and deliver a written report with recommendations.