TrendVidStream ತನ್ನ ಸಂಪೂರ್ಣ ಅಥೆಂಟಿಕೇಶನ್ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ರೋಟೇಟಿಂಗ್-ರಿಫ್ರೆಶ್-ಟೋಕನ್ ವ್ಯವಸ್ಥೆಗೆ ಬದಲಾಯಿಸಿದೆ, ಇದು ಕಳುವಾದ ಟೋಕನ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡಿದ ತಕ್ಷಣವೇ ಪತ್ತೆಹಚ್ಚುತ್ತದೆ. ಈ ಬದಲಾವಣೆಯು, ಹಿಂದೆ ದಾಳಿಕೋರರಿಗೆ ಮುಕ್ತವಾಗಿ ಸಂಚರಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತಿದ್ದ 30-ದಿನಗಳ JWT ಅನ್ನು, ತಕ್ಷಣವೇ ಲಾಕ್-ಔಟ್ ಅನ್ನು ಪ್ರಚೋದಿಸುವ ಅಲ್ಪಾವಧಿಯ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಆಗಿ ಪರಿವರ್ತಿಸಿದೆ.
ಒಂದು ಬ್ರೀಚ್ ಈ ಬದಲಾವಣೆಗೆ ಕಾರಣವಾಯಿತು: ಪಾಲುದಾರ SDK ಒಂದು 30-ದಿನಗಳ JWT ಅನ್ನು ಪ್ಲೇನ್ ಟೆಕ್ಸ್ಟ್ನಲ್ಲಿ ಕ್ಯಾಶ್ ಮಾಡಿತ್ತು, ದಾಳಿಕೋರನು ಅದನ್ನು ಹೊರತೆಗೆದು ಮತ್ತೊಂದು ದೇಶದಿಂದ ರೀಪ್ಲೇ ಮಾಡಿದನು, ಮತ್ತು ಆಗ ಲಭ್ಯವಿದ್ದ ಏಕೈಕ ಪರಿಹಾರವೆಂದರೆ ಸೈನಿಂಗ್ ಕೀಯನ್ನು ರೋಟೇಟ್ ಮಾಡುವುದು—ಈ ಪ್ರಕ್ರಿಯೆಯು ಪ್ರತಿಯೊಬ್ಬ ಬಳಕೆದಾರರನ್ನು ಲಾಗ್ ಔಟ್ ಮಾಡಿತು. ಈ ಘಟನೆಯು ಕಂಪನಿಯ ಟೋಕನ್ ಸುರಕ್ಷತೆಯನ್ನು ಮರುರೂಪಿಸಿತು ಮತ್ತು ಈಗ ವಿಡಿಯೋ-ಸ್ಟ್ರೀಮಿಂಗ್ ಸೇವೆಗೆ ಶಕ್ತಿಯನ್ನು ನೀಡುತ್ತಿದೆ.
ಹಳೆಯ ಮಾದರಿ ಏಕೆ ವಿಫಲವಾಯಿತು
JWTಗಳು (JSON Web Tokens) ಸ್ವಯಂ-ಅಲಂಕೃತ (self-contained), ಸೈನ್ ಮಾಡಿದ ಬ್ಲೋಬ್ಗಳಾಗಿದ್ದು, ಇವು ಸರ್ವರ್ಗೆ ಡೇಟಾಬೇಸ್ ಲುಕ್ಅಪ್ ಇಲ್ಲದೆಯೇ ವಿನಂತಿಯನ್ನು ಪರಿಶೀಲಿಸಲು ಅನುಮತಿಸುತ್ತವೆ. ಈ ಅನುಕೂಲವು ಒಂದು ಬೆಲೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ: ಒಂದು ಟೋಕನ್ ವಾರಗಟ್ಟಲೆ ಚಾಲ್ತಿಯಲ್ಲಿವಿದ್ದರೆ, ಅದನ್ನು ಕಳುವಿಸಿಕೊಳ್ಳುವುದು ದಾಳಿಕೋರರಿಗೆ ವಾರಗಟ್ಟಲೆ ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತದೆ. ಈ ಬ್ರೀಚ್ನಲ್ಲಿ, ಕಳುವಾದ ಟೋಕನ್ ಅದರ 30-ದಿನಗಳ ಅವಧಿ ಮುಗಿಯುವವರೆಗೆ ಮಾನ್ಯವಾಗಿತ್ತು, ಏಕೆಂದರೆ ಅದನ್ನು ಮೊದಲೇ ಅಮಾನ್ಯಗೊಳಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿರಲಿಲ್ಲ.
ಎಲ್ಲಾ ಟೋಕನ್ಗಳನ್ನು ಅಮಾನ್ಯಗೊಳಿಸಲು ಸೈನಿಂಗ್ ಕೀಯನ್ನು ರೋಟೇಟ್ ಮಾಡುವುದು ಒಂದೇ ಜಾಗತಿಕ ಮಾರ್ಗವಾಗಿದೆ, ಆದರೆ ಇದು ಪ್ರತಿಯೊಬ್ಬ ಬಳಕೆದಾರರನ್ನು ಮತ್ತೆ ಲಾಗ್ ಇನ್ ಮಾಡಲು ಒತ್ತಾಯಿಸುತ್ತದೆ, ಇದರಿಂದ ಸೇವೆಗೆ ಅಡ್ಡಿಯಾಗುತ್ತದೆ ಮತ್ತು ನಂಬಿಕೆ ಕುಸಿಯುತ್ತದೆ. ದೋಷವು JWT ಯಲ್ಲಿರಲಿಲ್ಲ, ಬದಲಾಗಿ ಒಂದೇ ದೀರ್ಘಕಾಲದ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವುದರಲ್ಲಿತ್ತು.
ಹೊಸ ವಿನ್ಯಾಸದ ಸಂಕ್ಷಿಪ್ತ ಮಾಹಿತಿ
TrendVidStream ಈಗ ಎರಡು ರೀತಿಯ ಟೋಕನ್ಗಳನ್ನು ನೀಡುತ್ತದೆ:
- Access tokens – 15 ನಿಮಿಷಗಳ ಕಾಲ ಮಾನ್ಯವಾಗಿರುತ್ತವೆ; ಇವು ಪ್ರತಿ API ಕಾಲ್ಗೆ ಅಗತ್ಯವಿರುವ ಅನುಮತಿಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ.
- Refresh tokens – ಒಂದೇ ಬಾರಿಯ ಬಳಕೆಗೆ ಇರುವ ಟೋಕನ್ಗಳು, ಇವು ಅಲ್ಪಾವಧಿಯ ಅಕ್ಸೆಸ್ ಟೋಕನ್ ಅನ್ನು ಹೊಸ ಜೋಡಿಯೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತವೆ.
ಕ್ಲೈಂಟ್ ಒಂದು ರಿಫ್ರೆಶ್ ಟೋಕನ್ ಅನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಿದಾಗ, ಸರ್ವರ್:
- ಟೋಕನ್ನ ಸಹಿ (signature) ಮತ್ತು ಕ್ಲೈಮ್ಗಳನ್ನು (claims) ಪರಿಶೀಲಿಸುತ್ತದೆ.
- ಟೋಕನ್ ಅನ್ನು ಈಗಾಗಲೇ ಬಳಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ.
- ಪರಿಶೀಲನೆ ಪಾಸಾದರೆ, ಹೊಸ ರಿಫ್ರೆಶ್ ಟೋಕನ್ ಮತ್ತು ಹೊಸ 15-ನಿಮಿಷಗಳ ಅಕ್ಸೆಸ್ ಟೋಕನ್ ಅನ್ನು ನೀಡುತ್ತದೆ.
- ಹಳೆಯ ರಿಫ್ರೆಶ್ ಟೋಕನ್ ಅನ್ನು 'ಬಳಸಲಾಗಿದೆ' ಎಂದು ಗುರುತಿಸುತ್ತದೆ.
ಒಂದು ವೇಳೆ ಹಂತ 2 ವಿಫಲವಾದರೆ—ಅಂದರೆ ಅದೇ ಟೋಕನ್ ಎರಡನೇ ಬಾರಿಗೆ ಕಂಡುಬಂದರೆ—ಸರ್ವರ್ ಅದನ್ನು ಕಳ್ಳತನದ ಸಂಕೇತವೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ ಮತ್ತು ಆ ಲಾಗಿನ್ ಸೆಷನ್ಗೆ ಲಿಂಕ್ ಆಗಿರುವ ಎಲ್ಲಾ ಟೋಕನ್ಗಳ "ಫ್ಯಾಮಿಲಿ"ಯನ್ನು ರದ್ದುಗೊಳಿಸುತ್ತದೆ (revoke). ಬಲಿಪಶು ಮತ್ತು ದಾಳಿಕೋರ ಇಬ್ಬರೂ ಮತ್ತೆ ಲಾಗ್ ಇನ್ ಮಾಡಲು ಒತ್ತಾಯಿಸಲ್ಪಡುತ್ತಾರೆ, ಇದರಿಂದ ಬ್ರೀಚ್ ಅನ್ನು ತಕ್ಷಣವೇ ತಡೆಯಬಹುದು.
ಟೋಕನ್ ಫ್ಯಾಮಿಲಿಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು
ಪ್ರತಿಯೊಂದು ಟೋಕನ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ದಾಖಲೆಯಾಗಿ ಪರಿಗಣಿಸುವ ಬದಲು, ಬಳಕೆದಾರನು ಲಾಗ್ ಇನ್ ಮಾಡಿದಾಗ ಪ್ರಾರಂಭವಾಗುವ ಫ್ಯಾಮಿಲಿಗಳಾಗಿ ವ್ಯವಸ್ಥೆಯು ಅವುಗಳನ್ನು ಗುಂಪು ಮಾಡುತ್ತದೆ. ಪ್ರತಿ ರೊಟೇಶನ್ ಆ ಫ್ಯಾಮಿಲಿಯ ಹೊಸ ಸದಸ್ಯರನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಬಳಸಲಾಗುವ SQLite ಸ್ಕೀಮವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ:
- family_id – ಇಡೀ ಸೆಷನ್ಗಾಗಿ ಒಂದು ಸ್ಥಿರ ಐಡೆಂಟಿಫೈಯರ್.
- token_id – ಪ್ರತಿ ರಿಫ್ರೆಶ್ ಟೋಕನ್ಗಾಗಿ ಒಂದು ವಿಶಿಷ್ಟ ಐಡೆಂಟಿಫೈಯರ್.
- generation – ಡಿಬಗ್ ಮಾಡಲು ಉಪಯುಕ್ತವಾದ ಕೌಂಟರ್.
- used_at – ಟೋಕನ್ ಅನ್ನು ಯಾವಾಗ ಬಳಸಲಾಯಿತೋ ಅದರ ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್.
- revoked – ಇದನ್ನು ಸೆಟ್ ಮಾಡಿದಾಗ ಇಡೀ ಫ್ಯಾಮಿಲಿಯನ್ನು ಅಮಾನ್ಯಗೊಳಿಸುವ ಫ್ಲಾಗ್.
ಮರುಬಳಕೆಯ ಘಟನೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಿದಾಗ, ಆ family_id ಗಾಗಿ revoked ಫ್ಲಾಗ್ ಅನ್ನು ಸೆಟ್ ಮಾಡಲಾಗುತ್ತದೆ, ಇದು ಸಂಚಲಿತಗೊಂಡ (compromised) ಸೆಷನ್ಗೆ ಸೇರಿದ ಪ್ರತಿಯೊಂದು ಟೋಕನ್ ಅನ್ನು ತಕ್ಷಣವೇ ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ. ಇದು ಮೌನವಾಗಿ ನಡೆಯುವ ಹೈಜಾಕ್ ಅನ್ನು ಲಾಗ್ಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಹೆಚ್ಚಿನ ಸಿಗ್ನಲ್ ಹೊಂದಿರುವ ಅಲರ್ಟ್ ಆಗಿ ಬದಲಾಯಿಸುತ್ತದೆ.
ವ್ಯವಸ್ಥೆಯನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರಿಸುವ ಮೂರು ಅನುಷ್ಠಾನ ನಿಯಮಗಳು
ಮೊದಲು ಸಹಿಯನ್ನು (signature) ಪರಿಶೀಲಿಸಿ ಸರ್ವರ್ ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸುವ ಮೊದಲು "ಬಳಸಲಾಗಿದೆಯೇ?" ಎಂದು ಪರಿಶೀಲಿಸಿದರೆ, ದಾಳಿಕೋರನು ಟೋಕನ್ ಐಡಿಗಳನ್ನು ಊಹಿಸಿ ಸಾಮೂಹಿಕ ರದ್ದತಿಗಳನ್ನು (mass revocations) ಪ್ರಚೋದಿಸಬಹುದು. ಮೊದಲು ಅಧಿಕೃತತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅನಗತ್ಯ 'ಡಿನೈಯಲ್-ಆಫ್-ಸರ್ವಿಸ್' (denial-of-service) ದಾಳಿಗಳನ್ನು ತಡೆಯುತ್ತದೆ.
ಗ್ರೆಸ್ ವಿಂಡೋವನ್ನು (grace window) ಅನುಮತಿಸಿ ಟೋಕನ್ ಅವಧಿ ಮುಗಿದಾಗ ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಹೆಚ್ಚಾಗಿ ಸತತವಾಗಿ ಎರಡು ರಿಫ್ರೆಶ್ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತವೆ. ಸರ್ವರ್ ತುಂಬಾ ಕಟ್ಟುನಿಟ್ಟಾಗಿದ್ದರೆ, ಎರಡನೇ ವಿನಂತಿಯನ್ನು ಮರುಬಳಕೆಯೆಂದು ಗುರುತಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಇದು ಕಾನೂನುಬದ್ಧ ಬಳಕೆದಾರರನ್ನು ಲಾಗ್ ಔಟ್ ಮಾಡುತ್ತದೆ. ಕೆಲವು ಸೆಕೆಂಡ್ಗಳ ಬಫರ್ ಇರುವುದರಿಂದ "ಬಳಸಿದ" ಟೋಕನ್ ಕೂಡ ಹೊಸ ಜೋಡಿಯನ್ನು ನೀಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಇದು ರೇಸ್ ಕಂಡೀಶನ್ಗಳನ್ನು (race conditions) ಸರಳಗೊಳಿಸುತ್ತದೆ.
ಇಡೀ ಪ್ರಕ್ರಿಯೆಯನ್ನು ರೋ ಲಾಕಿಂಗ್ನೊಂದಿಗೆ (row locking) ಟ್ರಾನ್ಸಾಕ್ಷನ್ನಲ್ಲಿ ಸುತ್ತುವರಿಯಿರಿ ಅಟಾಮಿಟಿ (atomicity) ಇಲ್ಲದಿದ್ದರೆ, ಏಕಕಾಲಿಕವಾಗಿ ಬರುವ ಎರಡು ವಿನಂತಿಗಳು ತಾವೇ ಮೊದಲಿಗೆ ಟೋಕನ್ ಬಳಸುತ್ತಿದ್ದೇವೆ ಎಂದು ಭಾವಿಸಬಹುದು, ಇದರಿಂದ ಡ್ಯುಪ್ಲಿಕೇಟ್ ರಿಫ್ರೆಶ್ ಟೋಕನ್ಗಳು ಬಿಡುಗಡೆಯಾಗಿ ಒಂದೇ ಬಾರಿಯ ಬಳಕೆಯ ಗ್ಯಾರಂಟಿಯನ್ನು ಮುರಿಯಬಹುದು. ಟೋಕನ್ ರೋ ಅನ್ನು ಲಾಕ್ ಮಾಡುವ ಡೇಟಾಬೇಸ್ ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಕೇವಲ ಒಂದು ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಸಾರಾಂಶ: ರಿಫ್ರೆಶ್ ಟೋಕನ್ಗಳನ್ನು ಒಂದೇ ಬಾರಿಯ ಬಳಕೆಗೆ ಸೀಮಿತಗೊಳಿಸುವ ಮೂಲಕ ಮತ್ತು ಮರುಬಳಕೆಯನ್ನು ಗಮನಿಸುವ ಮೂಲಕ, ಒಂದು ವ್ಯವಸ್ಥೆಯು ಕಳುವಾದ ಪ್ರತಿಯೊಂದು ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಅನ್ನು ಎಚ್ಚರಿಕೆಯ ಗಂಟೆಯನ್ನಾಗಿ (alarm) ಬದಲಾಯಿಸಬಹುದು, ಇದರಿಂದ ಪ್ಲಾಟ್ಫಾರ್ಮ್ನಾದ್ಯಂತ ಲಾಗ್ ಔಟ್ ಮಾಡದೆ ಬಳಕೆದಾರರನ್ನು ರಕ್ಷಿಸಬಹುದು.