ದೃಢೀಕರಣ (Authentication) ಎಂದರೇನು? ಲಾಗಿನ್, ಸೆಷನ್ ಮತ್ತು OAuth ವಿವರಣೆ
ದೃಢೀಕರಣ ಎಂದರೆ ಆ್ಯಪ್ ಒಬ್ಬ ಬಳಕೆದಾರ ಯಾರು ಎಂದು ಖಚಿತಪಡಿಸುವ ವಿಧಾನ — ಸಾಮಾನ್ಯವಾಗಿ ಅವರಿಗೆ ತಿಳಿದಿರುವ ಯಾವುದನ್ನಾದರೂ (ಪಾಸ್‌ವರ್ಡ್) ಪರಿಶೀಲಿಸುವ ಮೂಲಕ, ಅವರ ಬಳಿ ಇರುವ ಯಾವುದನ್ನಾದರೂ (ಫೋನ್ ಅಥವಾ ಇಮೇಲ್‌ಗೆ ಕಳುಹಿಸಿದ ಕೋಡ್) ಪರಿಶೀಲಿಸುವ ಮೂಲಕ, ಅಥವಾ ಇನ್ನೊಂದು ನಂಬಲರ್ಹ ಸೇವೆಯಿಂದ ಗುರುತು ಪಡೆಯುವ ಮೂಲಕ ("Google ನೊಂದಿಗೆ ಸೈನ್ ಇನ್" ನಂತೆ). ಬಳಕೆದಾರರ ದೃಢೀಕರಣ ಆದ ನಂತರ, ಆ್ಯಪ್ ಅವರನ್ನು ಸೆಷನ್ ಅಥವಾ ಟೋಕನ್ ಮೂಲಕ ನೆನಪಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಪುಟದಲ್ಲೂ ಮತ್ತೆ ಲಾಗಿನ್ ಆಗಬೇಕಾಗಿಲ್ಲ. ಆ ಗುರುತಿಸಲ್ಪಟ್ಟ ಬಳಕೆದಾರರು ಏನು ಮಾಡಬಹುದು ಎಂದು ನಿರ್ಧರಿಸುವುದು ಪ್ರತ್ಯೇಕ ಹಂತ, ಇದನ್ನು ಅಧಿಕಾರ (authorization) ಎನ್ನುತ್ತಾರೆ.
AI ಜೊತೆ ನಿರ್ಮಿಸುವಾಗ ಇದು ಏಕೆ ಮುಖ್ಯ
ಲಾಗಿನ್ ಸೇರಿಸುವುದು AI ಬಿಲ್ಡರ್‌ಗೆ ಜನರು ಮಾಡುವ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ವಿನಂತಿಗಳಲ್ಲಿ ಒಂದು, ಮತ್ತು ಅದನ್ನು ಸೂಕ್ಷ್ಮವಾಗಿ ತಪ್ಪಾಗಿ ಮಾಡುವುದೂ ಸುಲಭ. ಲಾಗಿನ್ ಪುಟ ಸರಳವಾಗಿ ರಚಿಸಬಹುದು. ಕಠಿಣ ಭಾಗ ಅದರ ಸುತ್ತಲಿನ ಎಲ್ಲವೂ:
- ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆಯೇ?
- ಪ್ರತಿಯೊಂದು ಖಾಸಗಿ ಪುಟ ಮತ್ತು ಪ್ರತಿಯೊಂದು API ಎಂಡ್‌ಪಾಯಿಂಟ್ ಯಾರು ಕೇಳುತ್ತಿದ್ದಾರೆ ಎಂದು ನಿಜವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತದೆಯೇ?
- URL ನಲ್ಲಿ ಒಂದು ಸಂಖ್ಯೆ ಬದಲಿಸಿ, ಲಾಗಿನ್ ಆದ ಗ್ರಾಹಕ ಇನ್ನೊಬ್ಬ ಗ್ರಾಹಕರ ಡೇಟಾ ನೋಡಬಹುದೇ?
- ಯಾರಾದರೂ ಪಾಸ್‌ವರ್ಡ್ ಮರೆತರೆ ಏನಾಗುತ್ತದೆ?
ಈ ಎಲ್ಲವನ್ನೂ ವಿಫಲಗೊಳಿಸುತ್ತಾ ಒಂದು ಆ್ಯಪ್ ಸಂಪೂರ್ಣ ಸುರಕ್ಷಿತವಾಗಿ ಕಾಣಬಹುದು. ಚಲಿಸುವ ಭಾಗಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ ಸರಿಯಾದ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲು ಮತ್ತು ಸರಿಯಾದದ್ದನ್ನು ಪರೀಕ್ಷಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ದಿನನಿತ್ಯದ ಒಂದು ಉದಾಹರಣೆ
ಹೋಟೆಲ್‌ನಲ್ಲಿ ಚೆಕ್-ಇನ್ ಮಾಡುವುದನ್ನು ಯೋಚಿಸಿ.
ಮುಂಭಾಗದ ಮೇಜಿನಲ್ಲಿ ನೀವು ಗುರುತಿನ ಚೀಟಿ ತೋರಿಸುತ್ತೀರಿ. ಅದು ದೃಢೀಕರಣ: ನೀವು ಯಾರು ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದು. ನಂತರ ಸ್ವಾಗತಕಾರರು ನಿಮಗೆ ಕೀ ಕಾರ್ಡ್ ನೀಡುತ್ತಾರೆ. ಆ ಕಾರ್ಡ್ ನಿಮ್ಮ ಸೆಷನ್: ನಿಮ್ಮ ವಾಸ್ತವ್ಯದ ಉಳಿದ ಅವಧಿಯಲ್ಲಿ ನೀವು ಮತ್ತೆ ಗುರುತಿನ ಚೀಟಿ ತೋರಿಸಬೇಕಾಗಿಲ್ಲ; ಕಾರ್ಡ್ ತೋರಿಸಿದರೆ ಸಾಕು.
ಕಾರ್ಡ್ ನಿಮ್ಮ ಕೋಣೆ, ಜಿಮ್ ಮತ್ತು ನಿಮ್ಮ ಮಹಡಿಯ ಲಿಫ್ಟ್ ತೆರೆಯುತ್ತದೆ — ಆದರೆ ಇತರ ಅತಿಥಿಗಳ ಕೋಣೆಗಳು ಅಥವಾ ಸಿಬ್ಬಂದಿ ಕಚೇರಿ ಅಲ್ಲ. ಅದು ಅಧಿಕಾರ: ನಿಮ್ಮ ಗುರುತಿಗೆ ಯಾವುದಕ್ಕೆ ಪ್ರವೇಶ ಇದೆ. ಕಾರ್ಡ್ ಕಳೆದುಹೋದರೆ, ಹೋಟೆಲ್ ಅದನ್ನು ಮೇಜಿನ ಬಳಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು (ಸೆಷನ್ ರದ್ದು). ಚೆಕ್-ಔಟ್ ಮಾಡಿದಾಗ ಅದು ಕೆಲಸ ಮಾಡುವುದು ನಿಲ್ಲುತ್ತದೆ (ಲಾಗ್‌ಔಟ್ ಅಥವಾ ಅವಧಿ ಮುಗಿಯುವಿಕೆ).
"Google ನೊಂದಿಗೆ ಸೈನ್ ಇನ್" ಎಂದರೆ ಹೋಟೆಲ್ ನಿಮ್ಮ ಗುರುತಿನ ಚೀಟಿಯನ್ನು ತಾನೇ ಪರಿಶೀಲಿಸುವ ಬದಲು, "ಇವರು ಇಂಥವರು" ಎಂದು ಹೇಳುವ ನಂಬಿಕಸ್ಥ ಪಾಲುದಾರರ ಪತ್ರವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವಂತೆ.
ಮುಖ್ಯ ಲಾಗಿನ್ ವಿಧಾನಗಳು
| ವಿಧಾನ | ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ | ಅನುಕೂಲ | ಅನನುಕೂಲ |
|---|---|---|---|
| ಇಮೇಲ್ + ಪಾಸ್‌ವರ್ಡ್ | ಬಳಕೆದಾರ ಪಾಸ್‌ವರ್ಡ್ ಆರಿಸುತ್ತಾರೆ; ಆ್ಯಪ್ ಅದರ ಹ್ಯಾಶ್ ಉಳಿಸುತ್ತದೆ | ಪರಿಚಿತ, ಹೊರಗಿನ ಅವಲಂಬನೆ ಇಲ್ಲ | ಹ್ಯಾಶ್‌ಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಸಂಗ್ರಹಿಸಬೇಕು ಮತ್ತು ಮರುಹೊಂದಿಕೆ ನಿರ್ವಹಿಸಬೇಕು |
| ಮ್ಯಾಜಿಕ್ ಲಿಂಕ್ / ಒಂದು-ಬಾರಿ ಕೋಡ್ | ಆ್ಯಪ್ ಇಮೇಲ್ ಮೂಲಕ ಲಿಂಕ್ ಅಥವಾ ಕೋಡ್ ಕಳುಹಿಸುತ್ತದೆ, ಅದು ಬಳಕೆದಾರರನ್ನು ಲಾಗಿನ್ ಮಾಡುತ್ತದೆ | ಸೋರಿಕೆ ಆಗುವ ಅಥವಾ ಮರೆಯುವ ಪಾಸ್‌ವರ್ಡ್ ಇಲ್ಲ | ಇಮೇಲ್ ವಿತರಣೆಯ ಮೇಲೆ ಅವಲಂಬನೆ; ಲಾಗಿನ್ ನಿಧಾನ |
| ಸಾಮಾಜಿಕ ಲಾಗಿನ್ (OAuth / OpenID Connect) | ಬಳಕೆದಾರರು Google, Apple, GitHub ಇತ್ಯಾದಿಗಳೊಂದಿಗೆ ಸೈನ್ ಇನ್ ಮಾಡುತ್ತಾರೆ | ಬಳಕೆದಾರರಿಗೆ ವೇಗ; ನೀವು ಪಾಸ್‌ವರ್ಡ್ ಸಂಗ್ರಹಿಸಬೇಕಾಗಿಲ್ಲ | ಪ್ರತಿ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ಸೆಟಪ್; ಆ ಖಾತೆಗಳಿಲ್ಲದ ಬಳಕೆದಾರರು |
| ಹೋಸ್ಟ್ ಮಾಡಿದ ಆಥ್ ಪೂರೈಕೆದಾರ | Clerk, Auth0 ಅಥವಾ Supabase Auth ನಂತಹ ಸೇವೆ ಸೈನ್-ಅಪ್, ಲಾಗಿನ್ ಮತ್ತು ಮರುಹೊಂದಿಕೆ ನಿರ್ವಹಿಸುತ್ತದೆ | ನಿಮಗೆ ಕಡಿಮೆ ಭದ್ರತಾ ಕೆಲಸ | ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಮಾಸಿಕ ವೆಚ್ಚ; ಇನ್ನೊಂದು ಅವಲಂಬನೆ |
| ಬಹು-ಅಂಶ (MFA / 2FA) | ಮೊದಲ ಪರಿಶೀಲನೆಯ ನಂತರ ಎರಡನೇ ಪರಿಶೀಲನೆ, ಉದಾಹರಣೆಗೆ ದೃಢೀಕರಣ ಆ್ಯಪ್‌ನ ಕೋಡ್ | ಒಳನುಗ್ಗುವುದು ಹೆಚ್ಚು ಕಷ್ಟ | ಸ್ವಲ್ಪ ಹೆಚ್ಚುವರಿ ತೊಂದರೆ |
ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸಬೇಕು
ಸುರಕ್ಷಿತ ಆ್ಯಪ್ ನಿಮ್ಮ ನಿಜವಾದ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಎಂದಿಗೂ ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ. ಬದಲಿಗೆ ಅದು ಹ್ಯಾಶ್ ಸಂಗ್ರಹಿಸುತ್ತದೆ: ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ಸ್ಥಿರ ಸ್ಟ್ರಿಂಗ್ ಆಗಿ ಬದಲಿಸುವ ಏಕಮುಖ ಕಾರ್ಯದ ಫಲಿತಾಂಶ. ನೀವು ಲಾಗಿನ್ ಆದಾಗ, ಆ್ಯಪ್ ನೀವು ಟೈಪ್ ಮಾಡಿದ್ದನ್ನು ಹ್ಯಾಶ್ ಮಾಡಿ ಉಳಿಸಿದ ಹ್ಯಾಶ್ ಜೊತೆ ಹೋಲಿಸುತ್ತದೆ.
ಇದನ್ನು ಸುರಕ್ಷಿತವಾಗಿಸುವ ಎರಡು ವಿವರಗಳು:
- ಸಾಲ್ಟ್ — ಹ್ಯಾಶ್ ಮಾಡುವ ಮೊದಲು ಪ್ರತಿ ಪಾಸ್‌ವರ್ಡ್‌ಗೆ ಸೇರಿಸಲಾಗುವ ಯಾದೃಚ್ಛಿಕ ಮೌಲ್ಯ. ಇದರಿಂದ ಒಂದೇ ಪಾಸ್‌ವರ್ಡ್ ಇರುವ ಇಬ್ಬರಿಗೆ ವಿಭಿನ್ನ ಹ್ಯಾಶ್‌ಗಳು ಸಿಗುತ್ತವೆ, ಮತ್ತು ಮುಂಚಿತವಾಗಿ ಲೆಕ್ಕ ಹಾಕಿದ ಲುಕಪ್ ಟೇಬಲ್‌ಗಳು ನಿಷ್ಪ್ರಯೋಜಕವಾಗುತ್ತವೆ.
- ಪಾಸ್‌ವರ್ಡ್‌ಗಳಿಗಾಗಿ ನಿರ್ಮಿತ ನಿಧಾನ ಅಲ್ಗಾರಿದಮ್ — ಉದಾಹರಣೆಗೆ Argon2, bcrypt ಅಥವಾ scrypt. MD5 ಅಥವಾ SHA-256 ನಂತಹ ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಹ್ಯಾಶ್‌ಗಳು ಅವುಗಳಾಗಿಯೇ ತುಂಬಾ ವೇಗವಾಗಿವೆ; ದಾಳಿಕೋರರು ಶತಕೋಟಿ ಊಹೆಗಳನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು.
ಹ್ಯಾಶಿಂಗ್ ಎನ್ಕ್ರಿಪ್ಶನ್‌ನಂತೆ ಅಲ್ಲ. ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಡೇಟಾವನ್ನು ಕೀ ಬಳಸಿ ಡಿಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದು; ಪಾಸ್‌ವರ್ಡ್ ಹ್ಯಾಶ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಲಾಗದಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ.
ಸೆಷನ್ vs ಟೋಕನ್
ಲಾಗಿನ್ ನಂತರ, ಪ್ರತಿ ವಿನಂತಿಯಲ್ಲಿ ಆ್ಯಪ್ ನಿಮ್ಮನ್ನು ಗುರುತಿಸಬೇಕು. ಇದಕ್ಕೆ ಎರಡು ಸಾಮಾನ್ಯ ವಿಧಾನಗಳಿವೆ.
| ಸೆಷನ್ (ಕುಕೀ) | ಟೋಕನ್ (ಉದಾ. JWT) | |
|---|---|---|
| ಬ್ರೌಸರ್ ಹೊಂದಿರುವುದು | ಕುಕೀಯಲ್ಲಿ ಯಾದೃಚ್ಛಿಕ ಸೆಷನ್ ID | ಬಳಕೆದಾರರ ಮಾಹಿತಿ ಮತ್ತು ಅವಧಿ ಹೊಂದಿರುವ ಸಹಿ ಮಾಡಿದ ಟೋಕನ್ |
| ಲಾಗಿನ್ ಸ್ಥಿತಿ ಎಲ್ಲಿರುತ್ತದೆ | ಸರ್ವರ್‌ನಲ್ಲಿ, ಡೇಟಾಬೇಸ್ ಅಥವಾ ಸ್ಟೋರ್‌ನಲ್ಲಿ | ಟೋಕನ್ ಒಳಗೇ |
| ಎಲ್ಲೆಡೆಯಿಂದ ಯಾರನ್ನಾದರೂ ಲಾಗ್‌ಔಟ್ ಮಾಡುವುದು | ಸುಲಭ: ಸರ್ವರ್‌ನಲ್ಲಿ ಸೆಷನ್ ಅಳಿಸಿ | ಕಷ್ಟ: ನಿರ್ಬಂಧ ಪಟ್ಟಿ ಇಟ್ಟುಕೊಳ್ಳದಿದ್ದರೆ ಅವಧಿ ಮುಗಿಯುವವರೆಗೆ ಟೋಕನ್ ಮಾನ್ಯವಾಗಿರುತ್ತದೆ |
| ಸಾಮಾನ್ಯ ಬಳಕೆ | ಸಾಂಪ್ರದಾಯಿಕ ವೆಬ್ ಆ್ಯಪ್‌ಗಳು | API ಗಳು, ಮೊಬೈಲ್ ಆ್ಯಪ್‌ಗಳು, ಪರಸ್ಪರ ಮಾತನಾಡುವ ಸೇವೆಗಳು |
ಕುಕೀಗಳಿಗೆ ಮೂರು ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮುಖ್ಯ: HttpOnly (ಪುಟದ JavaScript ಕುಕೀ ಓದಲಾಗುವುದಿಲ್ಲ), Secure (HTTPS ಮೇಲೆ ಮಾತ್ರ ಕಳುಹಿಸಲಾಗುತ್ತದೆ) ಮತ್ತು SameSite (ಇತರ ಸೈಟ್‌ಗಳಿಂದ ವಿನಂತಿಗಳಲ್ಲಿ ಕಳುಹಿಸುವುದನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ). ಟೋಕನ್‌ಗಳನ್ನು ಬ್ರೌಸರ್‌ನ localStorage ನಲ್ಲಿ ಇಡುವುದು ಸಾಮಾನ್ಯ, ಆದರೆ ಪುಟದಲ್ಲಿ ಚಲಿಸುವ ಯಾವುದೇ ಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ಅವು ಒಡ್ಡಿಕೊಳ್ಳುತ್ತವೆ.
OAuth ಮತ್ತು "Google ನೊಂದಿಗೆ ಸೈನ್ ಇನ್"
OAuth 2.0 ನಿಯೋಜಿತ ಅಧಿಕಾರಕ್ಕಾಗಿ ಒಂದು ಮಾನದಂಡ: ಇದು ಆ್ಯಪ್‌ಗೆ ನಿಮ್ಮ Google ಪಾಸ್‌ವರ್ಡ್ ನೋಡದೆಯೇ ಇನ್ನೊಂದು ಸೇವೆಯಲ್ಲಿರುವ ನಿಮ್ಮ ಖಾತೆಗೆ ಸೀಮಿತ ಪ್ರವೇಶ ನೀಡುತ್ತದೆ — ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ Google Calendar ಓದಲು. ನೀವು Google ಗೆ ಕಳುಹಿಸಲ್ಪಡುತ್ತೀರಿ, ನಿರ್ದಿಷ್ಟ ಅನುಮತಿಗಳನ್ನು (scopes ಎನ್ನುತ್ತಾರೆ) ಅನುಮೋದಿಸುತ್ತೀರಿ, ಮತ್ತು Google ಆ ಅನುಮತಿಗಳಿಗೆ ಮಾತ್ರ ಸೀಮಿತವಾದ ಟೋಕನ್ ಆ್ಯಪ್‌ಗೆ ನೀಡುತ್ತದೆ.
OAuth ಸ್ವತಃ ಪ್ರವೇಶ ನೀಡಲು ವಿನ್ಯಾಸಗೊಂಡಿತ್ತು, ನೀವು ಯಾರು ಎಂದು ಹೇಳಲು ಅಲ್ಲ. OpenID Connect (OIDC) ಎನ್ನುವುದು OAuth 2.0 ಮೇಲಿನ ಪದರ, ಇದು ಗುರುತನ್ನು ಸೇರಿಸುತ್ತದೆ — "Google ನೊಂದಿಗೆ ಸೈನ್ ಇನ್" ಅಥವಾ "Apple ನೊಂದಿಗೆ ಸೈನ್ ಇನ್" ಬಳಸುವುದು ಇದನ್ನೇ. ಇದನ್ನು ಸೆಟಪ್ ಮಾಡಲು ನಿಮ್ಮ ಆ್ಯಪ್ ಅನ್ನು ಪೂರೈಕೆದಾರರಲ್ಲಿ ನೋಂದಾಯಿಸಿ ಕ್ಲೈಂಟ್ ID ಮತ್ತು ಕ್ಲೈಂಟ್ ಸೀಕ್ರೆಟ್ ಪಡೆಯುತ್ತೀರಿ; ಸೀಕ್ರೆಟ್ ನಿಮ್ಮ ಸರ್ವರ್‌ನಲ್ಲಿಯೇ ಉಳಿಯುತ್ತದೆ.
ಒಂದು ಕೆಲಸ ಮಾಡಿದ ಉದಾಹರಣೆ: ಗ್ರಾಹಕ ಪೋರ್ಟಲ್‌ಗೆ ಲಾಗಿನ್
ಒಂದು ಡಿಸೈನ್ ಏಜೆನ್ಸಿಯ ಗ್ರಾಹಕರು ತಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು ಮತ್ತು ಇನ್‌ವಾಯ್ಸ್‌ಗಳನ್ನು ನೋಡುವ ಪೋರ್ಟಲ್ ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸಿ.
- ದೃಢೀಕರಣ: ಗ್ರಾಹಕರು ಇಮೇಲ್ ಮತ್ತು ಮ್ಯಾಜಿಕ್ ಲಿಂಕ್ ಮೂಲಕ ಲಾಗಿನ್ ಆಗುತ್ತಾರೆ, ಆದ್ದರಿಂದ ನಿರ್ವಹಿಸಲು ಪಾಸ್‌ವರ್ಡ್‌ಗಳಿಲ್ಲ. ಏಜೆನ್ಸಿ ಸಿಬ್ಬಂದಿ Google Workspace ಖಾತೆಗಳೊಂದಿಗೆ ಲಾಗಿನ್ ಆಗುತ್ತಾರೆ.
- ಪಾತ್ರಗಳು: ಪ್ರತಿ ಬಳಕೆದಾರರಿಗೆ ಒಂದು ಪಾತ್ರ ಇದೆ —
clientಅಥವಾstaff. - ಅಧಿಕಾರ ನಿಯಮಗಳು:
| ಕ್ರಿಯೆ | ಗ್ರಾಹಕ | ಸಿಬ್ಬಂದಿ |
|---|---|---|
| ತಮ್ಮ ಕಂಪನಿಯ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ನೋಡುವುದು | ಹೌದು | ಹೌದು |
| ಇತರ ಕಂಪನಿಗಳ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ನೋಡುವುದು | ಇಲ್ಲ | ಹೌದು |
| ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಫೈಲ್ ಅಪ್‌ಲೋಡ್ ಮಾಡುವುದು | ತಮ್ಮದೇ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು ಮಾತ್ರ | ಹೌದು |
| ಇನ್‌ವಾಯ್ಸ್ ಪಾವತಿಸಿದೆ ಎಂದು ಗುರುತಿಸುವುದು | ಇಲ್ಲ | ಹೌದು |
- ಎಲ್ಲಿ ಜಾರಿಗೊಳ್ಳುತ್ತದೆ: ಸರ್ವರ್‌ನಲ್ಲಿ, ಪ್ರತಿ ವಿನಂತಿಗೂ. ಸರ್ವರ್ ಲಾಗಿನ್ ಆದ ಬಳಕೆದಾರರನ್ನು ಹುಡುಕಿ, ನಂತರ
project.company_idಬಳಕೆದಾರರ ಕಂಪನಿಗೆ ಹೊಂದಾಣಿಕೆಯಾಗುವ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ಮಾತ್ರ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. "ಪಾವತಿಸಲಾಗಿದೆ ಎಂದು ಗುರುತಿಸಿ" ಬಟನ್ ಮರೆಮಾಡುವುದು ಸಾಕಾಗುವುದಿಲ್ಲ — ಎಂಡ್‌ಪಾಯಿಂಟ್ ಸ್ವತಃ ನಿರಾಕರಿಸಬೇಕು.
ಸಾಮಾನ್ಯ ಪದಗಳ ವಿವರಣೆ
| ಪದ | ಅರ್ಥ |
|---|---|
| ದೃಢೀಕರಣ (AuthN) | ಯಾರು ಎಂದು ಖಚಿತಪಡಿಸುವುದು. |
| ಅಧಿಕಾರ (AuthZ) | ಅವರು ಏನು ಮಾಡಬಹುದು ಎಂದು ನಿರ್ಧರಿಸುವುದು. |
| ಸೆಷನ್ | ವಿನಂತಿಗಳ ನಡುವೆ ನೀವು ಲಾಗಿನ್ ಆಗಿದ್ದೀರಿ ಎಂದು ಆ್ಯಪ್ ನೆನಪಿಡುವುದು. |
| ಕುಕೀ | ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಬ್ರೌಸರ್ ಸೈಟ್‌ಗೆ ಮರಳಿ ಕಳುಹಿಸುವ ಸಣ್ಣ ಡೇಟಾ. |
| JWT | JSON Web Token: ಬಳಕೆದಾರ ID ಮತ್ತು ಅವಧಿಯಂತಹ ಕ್ಲೇಮ್‌ಗಳನ್ನು ಹೊತ್ತ ಸಹಿ ಮಾಡಿದ, ಸಣ್ಣ ಟೋಕನ್. |
| ಪಾತ್ರ / ಅನುಮತಿ | ಪ್ರವೇಶ ನಿರ್ಧರಿಸುವ admin ಅಥವಾ member ನಂತಹ ಲೇಬಲ್‌ಗಳು. |
| MFA / 2FA | ದೃಢೀಕರಣ ಆ್ಯಪ್‌ನ ಕೋಡ್‌ನಂತೆ ಎರಡನೇ ಪುರಾವೆ ಬೇಕಾಗುವುದು. |
| SSO | ಸಿಂಗಲ್ ಸೈನ್-ಆನ್: ಅನೇಕ ಆ್ಯಪ್‌ಗಳಿಗೆ ಒಂದೇ ಲಾಗಿನ್ (ಆಗಾಗ್ಗೆ ಕಂಪನಿ ಖಾತೆ). |
| 401 vs 403 | "ನೀವು ಯಾರು?" (ದೃಢೀಕರಿಸಲಾಗಿಲ್ಲ) vs "ನೀವು ಅದನ್ನು ಮಾಡುವಂತಿಲ್ಲ" (ಅಧಿಕೃತವಲ್ಲ). |
ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು ಮತ್ತು ತಪ್ಪು ಕಲ್ಪನೆಗಳು
- ಅನುಮತಿಗಳನ್ನು ಕೇವಲ ಪುಟದಲ್ಲಿ ಪರಿಶೀಲಿಸುವುದು. ಬ್ರೌಸರ್ ಬಟನ್ ಮರೆಮಾಡಿದರೂ API ಪರಿಶೀಲಿಸದಿದ್ದರೆ, ಯಾರಾದರೂ API ಅನ್ನು ನೇರವಾಗಿ ಕರೆಯಬಹುದು.
- URL ನಿಂದ ಬಂದ ID ಗಳನ್ನು ನಂಬುವುದು.
/invoices/1042ಇನ್‌ವಾಯ್ಸ್ 1042 ಲಾಗಿನ್ ಆದ ಬಳಕೆದಾರರಿಗೆ ಸೇರಿದ್ದೇ ಎಂದು ಪರಿಶೀಲಿಸಬೇಕು. - ನಿಮ್ಮದೇ ಕ್ರಿಪ್ಟೋ ರಚಿಸುವುದು. ಪ್ರಸಿದ್ಧ ಲೈಬ್ರರಿಗಳು ಅಥವಾ ಪೂರೈಕೆದಾರರನ್ನು ಬಳಸಿ; AI ಹ್ಯಾಶಿಂಗ್ ಯೋಜನೆಯನ್ನು ಆವಿಷ್ಕರಿಸಲು ಬಿಡಬೇಡಿ.
- ದುರ್ಬಲ ಪಾಸ್‌ವರ್ಡ್ ಮರುಹೊಂದಿಕೆ. ಮರುಹೊಂದಿಕೆ ಲಿಂಕ್‌ಗಳು ಒಂದು-ಬಾರಿ ಬಳಕೆಯವಾಗಿರಬೇಕು, ಬೇಗ ಅವಧಿ ಮುಗಿಯಬೇಕು, ಮತ್ತು ಇಮೇಲ್‌ಗೆ ಖಾತೆ ಇದೆಯೇ ಎಂದು ಬಹಿರಂಗಪಡಿಸಬಾರದು.
- ನಿಮ್ಮ ಲಾಗಿನ್ ಮತ್ತು ಬಿಲ್ಡರ್‌ನ ಲಾಗಿನ್ ಗೊಂದಲ. ನಿಮ್ಮ ಆ್ಯಪ್‌ನ ಬಳಕೆದಾರರು, ನೀವು ನಿರ್ಮಿಸಲು ಬಳಸುವ ಸಾಧನದಲ್ಲಿನ ನಿಮ್ಮ ಖಾತೆಯಿಂದ ಬೇರೆಯಾಗಿರುತ್ತಾರೆ.
- ಲಾಗಿನ್‌ಗೆ ದರ ಮಿತಿ ಇಲ್ಲದಿರುವುದು. ಅದು ಇಲ್ಲದಿದ್ದರೆ ದಾಳಿಕೋರರು ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಅಂತ್ಯವಿಲ್ಲದಂತೆ ಪ್ರಯತ್ನಿಸಬಹುದು.
ನಿಮ್ಮ AI ಬಿಲ್ಡರ್‌ಗೆ ಏನು ಕೇಳಬೇಕು
- "[ಪ್ರಸಿದ್ಧ ಲೈಬ್ರರಿ ಅಥವಾ ಪೂರೈಕೆದಾರರನ್ನು] ಬಳಸಿ ಸೈನ್-ಅಪ್ ಮತ್ತು ಲಾಗಿನ್ ಸೇರಿಸಿ. ಕಸ್ಟಮ್ ಪಾಸ್‌ವರ್ಡ್ ಹ್ಯಾಶಿಂಗ್ ಬರೆಯಬೇಡಿ."
- "ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು bcrypt ಅಥವಾ Argon2 ಬಳಸಿ ಹ್ಯಾಶ್ ಮಾಡಿ ಸಂಗ್ರಹಿಸಿ."
- "ಸೆಷನ್‌ಗಾಗಿ HttpOnly, Secure ಕುಕೀಗಳನ್ನು ಬಳಸಿ."
- "ಪಾತ್ರಗಳನ್ನು ಸೇರಿಸಿ: admin ಮತ್ತು member. ಪ್ರತಿ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮತ್ತು ಅದನ್ನು ಕರೆಯಬಹುದಾದ ಪಾತ್ರಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ."
- "ಬಳಕೆದಾರರು ತಮ್ಮದೇ ದಾಖಲೆಗಳನ್ನು ಮಾತ್ರ ಓದಬಹುದು ಮತ್ತು ಸಂಪಾದಿಸಬಹುದು ಎಂದು ಸರ್ವರ್‌ನಲ್ಲಿ ಜಾರಿಗೊಳಿಸಿ. ನಂತರ ನೀವು ಹೇಗೆ ಪರಿಶೀಲಿಸಿದಿರಿ ಎಂದು ತೋರಿಸಿ."
- "ಒಂದು ಗಂಟೆಯಲ್ಲಿ ಅವಧಿ ಮುಗಿಯುವ ಒಂದು-ಬಾರಿ ಲಿಂಕ್‌ಗಳೊಂದಿಗೆ ಪಾಸ್‌ವರ್ಡ್ ಮರುಹೊಂದಿಕೆ ಸೇರಿಸಿ."
- "ಲಾಗಿನ್ ಪ್ರಯತ್ನಗಳಿಗೆ ದರ ಮಿತಿ ಹಾಕಿ."
ನಂತರ ನೀವೇ ಪರೀಕ್ಷಿಸಿ: ಎರಡು ಖಾತೆಗಳನ್ನು ರಚಿಸಿ ಮತ್ತು ಒಬ್ಬರಾಗಿ ಲಾಗಿನ್ ಆಗಿದ್ದಾಗ ಇನ್ನೊಬ್ಬರ ಡೇಟಾವನ್ನು ತಲುಪಲು ಪ್ರಯತ್ನಿಸಿ. ಲಾಗಿನ್ ಸೇರಿಸುವ ಮಾರ್ಗದರ್ಶಿ ಮತ್ತು ಭದ್ರತಾ ಪರಿಶೀಲನಾಪಟ್ಟಿ ಇನ್ನಷ್ಟು ವಿವರಿಸುತ್ತವೆ.
Mythex ನಲ್ಲಿ ದೃಢೀಕರಣ
ನಿಮ್ಮ ಆ್ಯಪ್‌ನ ಬಳಕೆದಾರರಿಗಾಗಿ Mythex ಅಂತರ್ನಿರ್ಮಿತ ಆಥ್ ಉತ್ಪನ್ನ ಒದಗಿಸುವುದಿಲ್ಲ; ನೀವು ಒಂದು ವಿಧಾನ ಆರಿಸುತ್ತೀರಿ — ಪ್ರಾಜೆಕ್ಟ್‌ನ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಇಮೇಲ್ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್, ಅಥವಾ ಹೋಸ್ಟ್ ಮಾಡಿದ ಪೂರೈಕೆದಾರರ SDK — ಮತ್ತು ಏಜೆಂಟ್‌ಗೆ ಸೇರಿಸಲು ಕೇಳುತ್ತೀರಿ. ಪೂರೈಕೆದಾರರ ಕೀಗಳು ಪ್ರಾಜೆಕ್ಟ್ ರಹಸ್ಯಗಳಲ್ಲಿ ಹೋಗುತ್ತವೆ, ಚಾಟ್‌ನಲ್ಲಿ ಅಲ್ಲ. ಇದು Mythex ಗೆ ನೀವು ಸೈನ್ ಇನ್ ಆಗುವ ರೀತಿಯಿಂದ ಬೇರೆಯಾಗಿದೆ. ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಲಾಗಿನ್ ಸೇರಿಸುವುದು ದಸ್ತಾವೇಜು ಪಾಕವಿಧಾನದಲ್ಲಿ ನೀವು ಹೊಂದಿಸಿಕೊಳ್ಳಬಹುದಾದ ಆರಂಭಿಕ ಪ್ರಾಂಪ್ಟ್ ಇದೆ, ಮತ್ತು API ಎಂದರೇನು ಆ ಸರ್ವರ್-ಬದಿಯ ಪರಿಶೀಲನೆಗಳು ಎಲ್ಲಿ ಇರುತ್ತವೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ.
ಪ್ರಶ್ನೆಗಳು
ದೃಢೀಕರಣ ಮತ್ತು ಅಧಿಕಾರ (authorization) ನಡುವಿನ ವ್ಯತ್ಯಾಸವೇನು?
ದೃಢೀಕರಣ ನೀವು ಯಾರು ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ನಿಮ್ಮ ಪಾಸ್‌ವರ್ಡ್ ಸರಿಯಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ. ಅಧಿಕಾರ ನಿಮಗೆ ತಿಳಿದ ನಂತರ ನೀವು ಏನು ಮಾಡಲು ಅನುಮತಿ ಇದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ಅಡ್ಮಿನ್ ಪುಟ ನೋಡಬಹುದೇ ಅಥವಾ ಬೇರೆಯವರ ಬುಕಿಂಗ್ ಸಂಪಾದಿಸಬಹುದೇ. ಆ್ಯಪ್‌ಗಳಿಗೆ ಎರಡೂ ಬೇಕು.
OAuth ಎಂದರೇನು?
OAuth 2.0 ಒಂದು ಮಾನದಂಡ, ಇದರ ಮೂಲಕ ಆ್ಯಪ್ ನಿಮ್ಮ ಪಾಸ್‌ವರ್ಡ್ ನೋಡದೆ ಇನ್ನೊಂದು ಸೇವೆಯಲ್ಲಿರುವ ನಿಮ್ಮ ಖಾತೆಗೆ ಸೀಮಿತ ಪ್ರವೇಶ ಪಡೆಯಬಹುದು. 'Google ನೊಂದಿಗೆ ಸೈನ್ ಇನ್' OAuth 2.0 ಮೇಲೆ ನಿರ್ಮಿತವಾದ OpenID Connect ಬಳಸುತ್ತದೆ, ಇದರಿಂದ ಆ್ಯಪ್ ನೀವು ಯಾರು ಎಂದು Google ನಿಂದ ತಿಳಿಯುತ್ತದೆ.
ನನ್ನ ಆ್ಯಪ್ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಬೇಕೇ?
ಓದಬಹುದಾದ ರೂಪದಲ್ಲಿ ಎಂದಿಗೂ ಬೇಡ. ಇಮೇಲ್ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಲಾಗಿನ್ ಬಳಸಿದರೆ, ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಸಾಲ್ಟ್ ಸೇರಿಸಿ ಮಾಡಿದ ಹ್ಯಾಶ್ ರೂಪದಲ್ಲಿ, Argon2 ಅಥವಾ bcrypt ನಂತಹ ಪಾಸ್‌ವರ್ಡ್‌ಗಳಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಂಡ ನಿಧಾನ ಅಲ್ಗಾರಿದಮ್‌ನಿಂದ ಸಂಗ್ರಹಿಸಬೇಕು. ಅನೇಕ ಆ್ಯಪ್‌ಗಳು ಹೋಸ್ಟ್ ಮಾಡಿದ ಆಥ್ ಪೂರೈಕೆದಾರ, ಸಾಮಾಜಿಕ ಲಾಗಿನ್ ಅಥವಾ ಇಮೇಲ್ ಮ್ಯಾಜಿಕ್ ಲಿಂಕ್ ಬಳಸಿ ಈ ಸಮಸ್ಯೆಯನ್ನೇ ತಪ್ಪಿಸುತ್ತವೆ.
ಸೆಷನ್ ಅಥವಾ ಟೋಕನ್ — ನನ್ನ ಆ್ಯಪ್ ಯಾವುದನ್ನು ಬಳಸಬೇಕು?
ಎರಡೂ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಸೆಷನ್ ಲಾಗಿನ್ ಸ್ಥಿತಿಯನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಇಟ್ಟು, ಬ್ರೌಸರ್‌ಗೆ ಕುಕೀಯಲ್ಲಿ ಯಾದೃಚ್ಛಿಕ ID ನೀಡುತ್ತದೆ, ಇದನ್ನು ರದ್ದುಗೊಳಿಸುವುದು ಸುಲಭ. JWT ನಂತಹ ಟೋಕನ್ ಸಹಿ ಮಾಡಿದ ಮಾಹಿತಿಯನ್ನು ಸ್ವತಃ ಹೊತ್ತೊಯ್ಯುತ್ತದೆ, ಇದು API ಗಳು ಮತ್ತು ಮೊಬೈಲ್ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸೂಕ್ತ, ಆದರೆ ಅವಧಿ ಮುಗಿಯುವ ಮೊದಲು ರದ್ದುಗೊಳಿಸುವುದು ಕಷ್ಟ. ಸಾಮಾನ್ಯ ವೆಬ್ ಆ್ಯಪ್‌ಗೆ, ಕುಕೀ ಆಧಾರಿತ ಸೆಷನ್ ಉತ್ತಮ ಡೀಫಾಲ್ಟ್.