JWT for REST APIs

Stateless Authentication

💡 JWT, EK CONCERT WRISTBAND hai — EK BAAR, ENTRY PAR, VERIFY hone ke BAAD, WRISTBAND (TOKEN) MIL jaata hai. HAR REQUEST mein, YE WRISTBAND, SAATH le jaate ho — SERVER ko, BAAR-BAAR, TUMHARI IDENTITY, DATABASE mein, CHECK karne ki, ZAROORAT NAHI.

REST APIs, STATELESS HONI CHAHIYE (REST CONSTRAINT) — SERVER, CLIENT ki, KOI "SESSION STATE", STORE NAHI karta. JWT (JSON Web Token), ISI PRINCIPLE ko, ENABLE karta hai — HAR REQUEST, APNE SAATH, SAARI ZAROORI INFORMATION (USER ID, ROLES), TOKEN mein, CARRY karti hai.

LOGIN ENDPOINT, CREDENTIALS VERIFY karके, EK JWT, GENERATE karta hai — CLIENT, ISE, STORE karta hai (jaise LOCAL STORAGE), aur, HAR SUBSEQUENT REQUEST mein, Authorization: Bearer <token> HEADER mein, BHEJTA hai. SERVER, TOKEN ki SIGNATURE VERIFY karके, TRUST karta hai.

@RestController
@RequestMapping("/api/auth")
public class AuthController {
    @PostMapping("/login")
    public ResponseEntity<TokenResponse> login(@RequestBody LoginRequest request) {
        Authentication auth = authManager.authenticate(
            new UsernamePasswordAuthenticationToken(request.username(), request.password()));
        String token = jwtService.generateToken(auth);
        return ResponseEntity.ok(new TokenResponse(token));
    }
}

// Client, HAR request mein:
// GET /api/orders
// Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

// Server-side, JWT filter, token VERIFY karta hai, HAR request par

🎫

JWT, EK CONCERT WRISTBAND hai — EK BAAR, ENTRY PAR, VERIFY hone ke BAAD, WRISTBAND (TOKEN) MIL jaata hai. HAR REQUEST mein, YE WRISTBAND, SAATH le jaate ho — SERVER ko, BAAR-BAAR, TUMHARI IDENTITY, DATABASE mein, CHECK karne ki, ZAROORAT NAHI.

1 / 2

⚡ झट से Recap

JWT = stateless authentication, REST APIs ke "statelessness" principle ke SAATH ALIGNED
Authorization: Bearer <token> header, HAR REQUEST mein, bheja jaata hai
Refresh tokens, SHORT-LIVED access tokens ke SAATH, security/UX, balance karte hain

इस page में (2 subtopics)

localStorage, EASY hai, LEKIN, XSS ATTACKS ke, SAAMNE, VULNERABLE hai (JavaScript, SIDHE, ISE, READ kar sakta hai). HttpOnly, COOKIES, XSS SE, SAFE hain (JavaScript, ACCESS NAHI kar sakta), LEKIN, CSRF, PROTECTION, ALAG SE, ZAROORI ho jaati hai.

💡Tip: PRODUCTION, APPLICATIONS mein, HttpOnly, SECURE, COOKIES, GENERALLY, MORE, SECURE, MAANI, JAATI hain, localStorage SE — TRADE-OFF, CSRF PROTECTION, ADD karne ka hai.

HAR, BAAR, JAB, EK, REFRESH TOKEN, USE hota hai (NAYA, ACCESS TOKEN, PANE ke liye), EK, NAYA, REFRESH TOKEN bhi, ISSUE kiya jaata hai, aur, PURANA, INVALIDATE ho jaata hai — AGAR, EK, STOLEN, REFRESH TOKEN, USE ho, ORIGINAL, USER ka, AGLA, ATTEMPT, FAIL HOGA, aur, SUSPICIOUS, ACTIVITY, DETECT ki ja sakti hai.

Refresh token rotation = HAR use PAR, NAYA token, PURANA invalidate
Stolen token detection = agar, DONO parties (attacker + real user), SAME, OLD token, USE karne ki, koshish karein

← पिछला🔗 Pagination Links (HATEOAS)अगला →🔑 API Keys & Rate Limiting

Code10x

JWT for REST APIs

Storing JWTs on the Client — localStorage vs Cookies

Refresh Token Rotation