TrendVidStream ने त्यांचे संपूर्ण authentication stack 'rotating-refresh-token' प्रणालीमध्ये हलवले आहे, जी चोरीचा token वापरला जाताच त्याला त्वरित ओळखते. या बदलामुळे ३० दिवसांचा JWT, जो एकेकाळी हल्लेखोराला मुक्तपणे फिरण्याची संधी देत असे, आता अल्पायुषी credential मध्ये बदलला आहे, जो चोरीला गेल्यास त्वरित 'lock-out' ट्रिगर करतो.
एका सिंगल ब्रीचमुळे (breach) हा बदल करणे भाग पडले: एका पार्टनर SDK ने ३० दिवसांचा JWT plain text मध्ये कॅश (cache) केला होता, एका हल्लेखोराने तो काढला आणि दुसऱ्या देशातून त्याचा वापर केला, आणि त्यावर एकमेव उपाय म्हणजे 'signing key' बदलणे (rotate करणे) हा होता—ज्यामुळे सर्व युजर्सना लॉग आउट व्हावे लागले. या घटनेने कंपनीच्या token security मध्ये मोठे बदल घडवून आणले आणि आता हीच प्रणाली व्हिडिओ-स्ट्रीमिंग सेवेसाठी वापरली जाते.
जुने मॉडेल का अपयशी ठरले
JWTs (JSON Web Tokens) हे self-contained, signed blobs असतात जे डेटाबेस लूकअपशिवाय सर्व्हरला विनंती (request) सत्यापित करण्यास परवानगी देतात. ही सोय एक किंमत मोजायला लावते: जर एखादा token अनेक आठवडे वैध असेल, तर तो चोरीला गेल्यास हल्लेखोराला अनेक आठवडे प्रवेश मिळतो. त्या ब्रीचमध्ये, चोरीचा token त्याच्या ३० दिवसांच्या मुदतीपर्यंत वैध होता कारण तो लवकर रद्द (invalidate) करण्याचा कोणताही मार्ग नव्हता.
सर्व tokens रद्द करण्याचा एकमेव जागतिक मार्ग म्हणजे signing key बदलणे, परंतु यामुळे प्रत्येक युजरला पुन्हा लॉग इन करावे लागते, ज्यामुळे सेवा विस्कळीत होते आणि विश्वास कमी होतो. दोष JWT मध्ये नव्हता, तर एकाच, दीर्घकाळ टिकणाऱ्या credential वर अवलंबून राहण्यात होता.
नवीन डिझाइन थोडक्यात
TrendVidStream आता दोन प्रकारचे tokens जारी करते:
- Access tokens – १५ मिनिटांसाठी वैध; ते प्रत्येक API call साठी आवश्यक परवानग्या (permissions) वाहून नेतात.
- Refresh tokens – एकदाच वापरता येणारे (single-use) tokens, जे अल्पायुषी access token च्या बदल्यात नवीन जोडी (pair) मिळवून देतात.
जेव्हा क्लायंट refresh token सादर करतो, तेव्हा सर्व्हर:
- token ची signature आणि claims सत्यापित करतो.
- तो token आधी वापरला गेला आहे का, हे तपासतो.
- जर तपासणी यशस्वी झाली, तर एक अगदी नवीन refresh token आणि नवीन १५ मिनिटांचा access token जारी करतो.
- जुन्या refresh token ला 'वापरलेला' (used) म्हणून मार्क करतो.
जर पायरी २ अयशस्वी झाली—म्हणजेच तोच token दुसऱ्यांदा दिसला—तर सर्व्हर त्याला चोरीचा संकेत मानतो आणि त्या लॉगिन सेशनशी संबंधित सर्व tokens ची “family” रद्द (revoke) करतो. यामुळे पीडित आणि हल्लेखर दोघांनाही पुन्हा लॉग इन करावे लागते, ज्यामुळे ब्रीचचा कालावधी कमी होतो.
Token families ट्रॅक करणे
प्रत्येक token ला एक स्वतंत्र रेकॉर्ड मानण्याऐवजी, ही प्रणाली त्यांना 'families' मध्ये गटबद्ध करते, ज्याची सुरुवात युजर लॉग इन केल्यावर होते. प्रत्येक rotation मुळे त्या फॅमिलीचा एक नवीन सदस्य तयार होतो. प्रोडक्शनमध्ये वापरले जाणारे SQLite schema खालील गोष्टी साठवते:
- family_id – संपूर्ण सेशनसाठी एक स्थिर आयडेंटिफायर (identifier).
- token_id – प्रत्येक refresh token साठी एक युनिक आयडेंटिफायर.
- generation – डिबगिंगसाठी उपयुक्त असलेला काउंटर.
- used_at – token कधी रिडीम (redeem) केला त्याचा timestamp.
- revoked – एक flag, जो सेट केल्यावर संपूर्ण फॅमिली अक्षम (disable) केली जाते.
जेव्हा पुन्हा वापरल्याचा (reuse) प्रकार आढळतो, तेव्हा त्या family_id साठी revoked flag सेट केला जातो, ज्यामुळे बाधित सेशनचे प्रत्येक token त्वरित अवैध ठरते. यामुळे शांतपणे घडणारी हायजॅकिंगची घटना लॉग्समध्ये दिसणाऱ्या एका 'high-signal alert' मध्ये रूपांतरित होते.
सिस्टम विश्वसनीय ठेवण्यासाठी अंमलबजावणीचे तीन नियम
प्रथम signature सत्यापित करा जर सर्व्हरने signature सत्यापित करण्यापूर्वी “used-before?” हे तपासले, तर हल्लेखोर token IDs चा अंदाज घेऊन मोठ्या प्रमाणावर revocations ट्रिगर करू शकतात. प्रथम सत्यता (authenticity) तपासल्यामुळे अनावश्यक denial-of-service हल्ले टाळता येतात.
Grace window ला परवानगी द्या जेव्हा token संपतो, तेव्हा मोबाईल ॲप्स अनेकदा लागोपाठ दोन refresh requests पाठवतात. जर सर्व्हर खूप कडक असेल, तर दुसऱ्या विनंतीला 'reuse' म्हणून चिन्हांकित केले जाईल, ज्यामुळे वैध युजर लॉग आउट होईल. काही सेकंदांचा बफर (buffer) "वापरलेल्या" token ला नवीन जोडी परत मिळवून देण्यास मदत करतो, ज्यामुळे race conditions सुलभ होतात.
संपूर्ण प्रक्रियेला row locking सह transaction मध्ये गुंडाळा Atomicity शिवाय, दोन एकाच वेळी येणाऱ्या विनंत्यांना (concurrent requests) असे वाटू शकते की ते token वापरणारे पहिले आहेत, ज्यामुळे ड्युप्लिकेट refresh tokens जारी होऊ शकतात आणि single-use ची खात्री मोडली जाऊ शकते. token row लॉक करणारे डेटाबेस transaction हे सुनिश्चित करते की केवळ एकच विनंती यशस्वी होईल.
Takeaway: refresh tokens ला single-use बनवून आणि त्यांच्या पुनर्वापरावर लक्ष ठेवून, एखादी प्रणाली प्रत्येक चोरीला गेलेल्या credential चे रूपांतर एका अलार्ममध्ये करू शकते, ज्यामुळे प्लॅटफॉर्म-व्यापी लॉगआउट न करता युजर्सचे संरक्षण होते.