چرا JWT شما ممکن است به شما دروغ بگوید و چگونه آن را بیان کنید

آنچه Devs اغلب در مورد JWT اشتباه می کند ، چگونه مهاجمان از آن سوء استفاده می کنند ، و چگونه می توان بازی AUTH خود را واقعاً تضمین کرد

JWTS (JSON Web Tokens) وقتی برای اولین بار در مورد آنها می شنوید ، مانند یک معامله بسیار شیرین به نظر می رسد. احراز هویت بدون تابعیت! نشانه های کوچک! جلو آماده! مانند آن لحظه در یک RPG که در آن کسی شمشیر افسانه ای به شما می دهد … و بعداً می فهمید که این یک نفرین است.

این واقعیت است: JWT ها به طور گسترده ای اشتباه فهمیده می شوند، اغلب سوءاستفاده ، و به طرز شگفت آور شکننده در دست های اشتباه. شما احتمالاً آنها را در آن دیده اید Authorization: Bearer هدر ، آنها را رمزگشایی کرد jwt.io، و شاید حتی یکی از آنها را در LocalStorage فکر کند ، “بله ، من اکنون امن هستم.”

اما این پیچش است:
اگر شما با احتیاطی که شایسته آن نیست ، این نشانه کوچک براق ممکن است آسیب بیشتری نسبت به خوبی داشته باشد. خواه به طور تصادفی بپذیرد alg: none (بله ، این یک حمله واقعی است) یا با اعتماد به یک نشانه منقضی شده ، JWTS به راحتی می تواند به پاشنه آشیل برنامه شما تبدیل شود.

در این راهنما ، ما JWT ها (به معنای واقعی کلمه) را رمزگشایی می کنیم ، نحوه کار آنها را باز می کنیم ، اشتباهات رایج را در معرض دید خود قرار می دهیم و به شما کمک می کند تا مانند یک جادوگر واقعی ، آنها را به درستی انجام دهید. در پایان ، شما می دانید چگونه JWT های خود را مستقیماً صحبت کنید و خوب رفتار کنید بدون افتادن برای تله های کلاسیک که حتی برنامه های بزرگ نیز از دست می دهند.

برای تأیید دانش نویسنده خود آماده هستید؟ بیایید رول کنیم.

تصور کنید که آیا سیستم هویت برنامه شما یک دفتر گذرنامه بود که توسط یک سرعت گیری اداره می شد. این همان چیزی است که JWT (JSON Web Token) قصد دارد: روشی سریع و خودمختار برای اثبات “چه کسی شما هستید” بدون اینکه هر بار با پایگاه داده صحبت کنید.

در هسته آن ، JWT یک نشانه جمع و جور است که از سه قسمت رمزگذاری شده Base64 ساخته شده است که به همراه نقاطی مانند SO چسبانده شده است:

xxxxx.yyyyy.zzzzz

بیایید آن را تجزیه کنیم:

یک JWT ممکن است شبیه به جیب باشد ، اما فقط با Base64 قابل خواندن است. این یعنی هر کسی می تواند آن را رمزگشایی کند از جمله آن کاربر تصادفی که ذخیره سازی مرورگر شما را بازرسی می کند و نشانه های خود را در محل محلی مانند آب نبات عمومی پیدا می کند.

اسطوره: “JWTS ایمن است زیرا آنها رمزگذاری شده اند.”

نه رمزگذاری ≠ رمزگذاری. رمزگشایی JWT مانند حذف پرونده بدون رمز عبور لازم است. در فقط قسمت امن امضا استوت فقط اگر آن را به درستی تأیید کنیدبشر

در اینجا یک نگاه سریع در یک بار رمزگشایی شده وجود دارد:

{
"sub": "1234567890",
"name": "Neo",
"admin": true,
"exp": 1716224000
}

دوستانه به نظر می رسد ، درست است؟ حال تصور کنید که کسی فقط این را کپی می کند ، تغییرات "admin": false به "admin": true، آن را دوباره رمزگذاری کنید ، و سرور شما امضا را تأیید نمی کند. اوه

چگونه احراز هویت JWT در واقع کار می کند

خوب ، بیایید چگونگی کار JWT ها در یک ورود به سیستم معمولی را تجزیه کنیم → تأیید کنید → از جریان استفاده کنید. زیرا اگر فقط نیمی از جریان را درک کنید ، ممکن است برنامه شما در نیمه راه هک شده باشد.

دور ورود: صدور JWT

تصور کنید کاربر شما فقط با ایمیل و رمز ورود وارد شده است. بعد چه اتفاقی می افتد؟

1. سرور شما اعتبار آنها را بررسی می کند.
2. اگر معتبر باشد ، علائم JWT حاوی شناسه کاربری آنها و شاید یک نقش باشد.
3. آن JWT را به جبهه می فرستد.

در اینجا یک مثال اصلی node.js استفاده شده است jsonwebtoken:

const jwt = require('jsonwebtoken');
const token = jwt.sign(
{ userId: 42, role: 'admin' },
process.env.JWT_SECRET,
{ expiresIn: '1h' }
);
res.json({ token });

این است شما اکنون نشانه ای دارید که هویت را برای ساعت بعد اثبات می کند. در هر درخواست دیگر به پایگاه داده ضربه نمی زنید. فقط نشانه را تأیید کنید و حرکت کنید.

دور API: تأیید JWT

هنگامی که کاربر درخواست های آینده را ارائه می دهد ، مشتری آنها JWT را در یک Authorization هدر مانند این:

Authorization: Bearer 

پس زمینه شما اکنون باید نشانه را تأیید کند:

try {
const decoded = jwt.verify(token, process.env.JWT_SECRET);
req.user = decoded;
next();
} catch (err) {
res.status(401).json({ message: 'Invalid or expired token' });
}

این دو چیز مهم:

• تأیید می کند که توکن با (از طریق امضا) دستکاری نشده است
• بررسی می کند که آیا منقضی شده است (بر اساس exp ادعا)

و دقیقاً مانند آن ، مسیر شما بدون ذخیره جلسه محافظت می شود. بسیار نرم و صاف

جایی که موارد JWT را ذخیره می کنید

شما دو گزینه اصلی دارید:

• محل کار محلی: آسان ، اما در برابر XSS آسیب پذیر است

• کوکی های HTTP فقط: ایمن تر ، اما پیچیدگی و خطرات CSRF را اضافه می کند

هر کدام دارای تجارت هستند. TL ؛ دکتر اگر در حال ساختن یک برنامه جدی هستید ، از کوکی های ایمن فقط HTTP + محافظت CSRF استفاده کنید. در غیر این صورت ، LocalStorage برای پروژه های سرگرمی یا ابزارهای داخلی خوب است.

برای نکته: به JWT اعتماد نکنید فقط به این دلیل که وجود دارد. به آن اعتماد کن فقط پس از تأیید صحت ، اعتبار سنجی ادعا و بررسی های عقل.

JWT ها وقتی برای اولین بار استفاده از آنها را شروع می کنید ، می توانند احساس شکست ناپذیر کنند. آنها بی تاب هستند ، آنها امضا شده اند ، آنها خوشحال هستند. اما دقیقاً مانند اولین بار که یک رئیس را بدون خواندن مکانیک مخزن می کنید ، استفاده از JWTS بدون دانستن مشکلات ، دستور العمل فاجعه است.

در اینجا رایج ترین JWT FacePalms Devs درست در آن قدم می زنند:

1. توکن های طولانی مدت = درد طولانی مدت

تنظیم expiresIn: "30d" مثل این است که درب جلو خود را باز کنید و به تعطیلات بروید.

چرا بد است:
اگر یک JWT از طریق XSS نشت می کند ، Sniffing Network (سلام ، HTTP) یا ورود به سیستم مهاجم اکنون 30 روز زمان جویید را دارد. هیچ چک پس زمینه نمی تواند آنها را متوقف کند مگر اینکه شما یک سیستم ابطال توکن ایجاد کرده باشید.

رفع:
دسترسی به نشانه های کوتاه مدت را نگه دارید (15min به 1h) و از نشانه های تازه سازی برای تجدید ایمن آنها استفاده کنید.

2. کشنده alg: none حمله

این افسانه ای برخی از کتابخانه ها برای پذیرش JWT ها در جایی که هدر ادعا می کند:

{ "alg": "none" }

که از تأیید امضای کاملاً پرش می کند. جدی

چگونه کار می کند:
یک کاربر مخرب یک JWT معتبر را رمزگشایی می کند ، بار را برای بالا بردن نقش خود تغییر می دهد (به عنوان مثال ، user به admin) ، مجموعه alg: none، و نشانه را دوباره رمزگذاری می کند. اگر سرور شما در حال تأیید امضا نیست … فقط به آنها اجازه می دهد.

رفع:

• همیشه نشانه را با یک کتابخانه مناسب تأیید کنید.
• هرگز به alg ادعای خود را از خود نشان دهید.
• الگوریتم های مجاز قفل (RS256با HS256) در پس زمینه شما صریح.

3. اعتماد به بار مانند انجیل

JWT شما ممکن است بگوید:

{ "userId": 1, "role": "admin" }

اما اگر تأیید نکنید امضاء، این می تواند یک دروغ باشد.

اشتباه:
با استفاده از jwt.decode() به جای jwt.verify() بدان معنی است که هر کسی فقط می تواند بار را تغییر دهد و اگر مراقب نباشید هنوز پذیرفته شوید.

رفع:
همیشه قبل از استفاده از هرگونه داده از نشانه ، امضا را تأیید کنید. رمزگشایی = نگاه کردن. تأیید = اعتماد.

4. عدم ابطال نشانه ها در ورود به سیستم یا تغییر رمز عبور

JWT ها بدون تابعیت هستند ، به این معنی که یک بار صادر شده است ، آنها نمی توانند “کشته” شوند ، مگر اینکه آنها را به صورت بیرونی ردیابی کنید. بنابراین اگر کاربر از سیستم خارج شود ، این نشانه هنوز تا زمان انقضا کار می کند. همان با تغییرات رمز عبور یا حذف حساب.

رفع:
حفظ دنییلیست با استفاده از jti ادعا (شناسه JWT). در ورود به سیستم یا تغییر رمز عبور ، ذخیره کنید jti در لیست سیاه با انقضا. در هر درخواست ، آن را بررسی کنید.

اگر یک درس را از این راهنما بگیرید ، باید این باشد: هرگز به JWT اعتماد نکنید تا زمانی که امضای ، ادعاها و زمینه ها را مانند NPC مشکوک در یک بازی کارآگاه تأیید نکنید.

بسیاری از توسعه دهندگان اشتباه در رمزگشایی JWT ها و فرض کردن محتوای آنها درست هستند. اما این مانند اعتقاد به یک یادداشت بدون امضا است که می گوید: “من الان مدیرعامل هستم. لطفاً به من اجازه دهید.”

بیایید به چگونگی تأیید JWTS مانند زندگی برنامه شما بستگی داشته باشیم – زیرا احتمالاً این کار را می کند.

امضا را تأیید کنید (نه فقط رمزگشایی)

فقط decode این برای اشکال زدایی است. verify حرکت در تولید است.

const jwt = require('jsonwebtoken');
try {
const decoded = jwt.verify(token, process.env.JWT_SECRET, {
algorithms: ['HS256'], // explicitly specify allowed algorithms
});
req.user = decoded;
} catch (err) {
return res.status(401).json({ message: 'Invalid token' });
}

• verify() بررسی می کند امضاء با استفاده از راز (HS256) یا کلید عمومی (RS256).

• همچنین ادعاهای داخلی مانند را تأیید می کند exp (انقضا) و nbf (نه قبل)
• اگر شکست بخورد؟ توکن را مانند یک فایل ذخیره خراب بریزید.

ادعاهای مهم را تأیید کنید

در چک های امضا متوقف نشوید. تأیید کردن سازمان بهداشت جهانیبا کیوت چرابشر

ادعاهای مشترکی که باید اعتبار دهید:

منطق اعتبار سنجی مثال:

if (decoded.aud !== 'my-app-client') {
throw new Error('Invalid audience');
}
if (decoded.iss !== 'auth.myapp.com') {
throw new Error('Invalid issuer');
}

برای اعتماد به نفس کلیدی عمومی/خصوصی از Rs256 استفاده کنید

اگر در حال کار با میکروسرویس یا شخص ثالث AUTH (مانند AUTH0) هستید ، Rs256 دوست شما است.

• Rs256 از کلیدهای نامتقارن استفاده می کند کلید خصوصی برای امضا کردن ، کلید برای تأیید
• شما می توانید کلید عمومی خود را با خیال راحت در معرض دید خود قرار دهید تا سایر خدمات بتوانند بدون به اشتراک گذاشتن اسرار ، نشانه ها را تأیید کنند.

اینگونه است که سیستم عامل هایی مانند Google یا Auth0 به طور ایمن نشانه ها را در چندین سیستم صادر می کنند.

Paranoia جایزه: اسرار را بچرخانید و استفاده کنید jti

• راز JWT خود را به طور مرتب بچرخانید (مانند تغییر قفل ها).
• استفاده کردن jti (jwt id) برای شناسایی منحصر به فرد هر نشانه ، بنابراین در صورت لزوم می توانید آنها را از طریق یک دنیلاست لغو کنید.

حرف آخر در مورد پارانویا

اگر کسی بگوید “JWT ها به طور پیش فرض ایمن هستند” ، باید آن را بشنوید ،

“من کلیدهایم را در ماشین گذاشتم ، اما اشکالی ندارد زیرا قفل شده است.”

اعتماد نکن تأیید کنید اعتبارسنجی دو بررسی

آه ، بله ، نمایش کلاسیک: JWT در مقابل جلسهبشر این مانند Linux در مقابل Windows ، Vim vs Vscode یا تم نور در مقابل حالت تاریک است (خوب شاید آنقدر جدی نباشد اما نزدیک باشد). هر دو استراتژی احراز هویت دارای جوانب مثبت و منفی هستند – و هیچ یک از آنها یک گلوله جادویی نیست.

بیایید آن را تجزیه کنیم ، dev-to-dev.

نویسنده مبتنی بر جلسه مطرح

با نویسنده مبتنی بر جلسه ، سرور شما شناسه جلسه را در حافظه یا در یک پایگاه داده ذخیره می کند (مانند redis). مشتری یک کوکی جلسه دریافت می کند و هر بار که درخواست می کند ، سرور آن شناسه جلسه را برای تأیید اعتبار کاربر بررسی می کند.

جوانب مثبت:

• آسان تر برای ابطال دسترسی فوراً (فقط جلسه را بکشید)
• عالی برای برنامه های وب سنتی
• در صورت از بین رفتن جلسه از استفاده مجدد از توکن در امان است

منفی ها:

• بدون جلسات چسبنده یا ذخیره سازی متمرکز در سرور خوب نیست
• اجرای در میکروسروس های بدون تابعیت یا اسپا سخت تر است

AUTH مبتنی بر JWT بدون تابعیت

JWT ها در سمت مشتری ذخیره می شوند و حاوی هویت و ادعاهای کاربر است درون خود نشانه. سرور فقط امضا را تأیید می کند و به ذخیره جلسه نیاز نیست.

جوانب مثبت:

• نیازی به ذخیره وضعیت جلسه نیست (عالی برای مقیاس گذاری و خدمات ریزگردها)
• به راحتی قابل حمل در سراسر خدمات است
• برای API ها ، اسپا ها ، برنامه های تلفن همراه خوب است

منفی ها:

• ابطال توکن بدون منطق اضافی سخت است (لیست های سیاه ، jti، و غیره)
• تا زمانی که منقضی شوند می توان از آنها سوءاستفاده کرد
• برای برنامه های کوچک می تواند بیش از حد باشد

tl ؛ dr: بر اساس مورد استفاده خود انتخاب کنید

بنابراین … آیا باید از JWT استفاده کنید؟

اگر در حال ساخت هستید:

• یک برنامه تلفن همراه یا آبگرم؟ JWT می تواند ایده آل باشد.
• یک پس زمینه چند سرویس؟ JWT (با Rs256) عملاً ضروری است.
• یک برنامه وب ساده یا ابزار داخلی؟ به جلسات بچسبید.

قانون شست: از JWT استفاده نکنید مگر اینکه مجبور شوید. این یک ابزار قدرتمند است ، اما پیچیدگی را به ویژه هنگامی که ابطال یا امنیت بسیار مهم است ، می افزاید.

خوب ، شما آموخته اید که JWTS چیست ، چگونه کار می کنند و چگونه شکست می خورند. اما اکنون وقت آن است که برویم از “بازی در اطراف” گرفته تا “تولید آماده”. در اینجا لیست چک NO-BS شما وجود دارد تا مطمئن شوید که تنظیم JWT شما به طور تصادفی امنیت برنامه شما را کنترل نمی کند.

1. دسترسی به نشانه های کوتاه مدت را حفظ کنید

دسترسی سبک و محدود به Tokens خود را حفظ کنید. به آنها فکر کنید مانند کدهای تقلب یک بار کاربردی که نباید برای همیشه دوام داشته باشند.

jwt.sign(payload, secret, { expiresIn: '15m' });

چرا؟ زیرا اگر کسی نشانه را سرقت کند ، دسترسی آنها به زمان محدود است. نشانه های طولانی مدت = پشیمانی طولانی مدت.

2. از نشانه های تازه سازی عاقلانه استفاده کنید

نشانه دسترسی منقضی شده است؟ وحشت نکنید. فقط صادر کردن نشانه با طول عمر طولانی تر و آن را ذخیره کنید با خیال (ترجیحاً به عنوان یک کوکی فقط HTTP).

نه:

• نشانه های تازه سازی را در محل محلی ذخیره کنید
• آنها را در معرض JavaScript قرار دهید

در اینجا یک جریان امن وجود دارد:

• ورود به سیستم کاربر → دسترسی به + توکن تازه کردن
• Token Access منقضی می شود → Frontend توکن تازه ای را ارسال می کند
• سرور توکن تازه سازی را تأیید می کند → یک نشانه دسترسی جدید را صادر می کند

پاداش: شناسه های توکن تازه کردن را ردیابی کنید (jti) در یک فروشگاه امن ، بنابراین می توانید آنها را در هنگام ورود به سیستم یا سازش لغو کنید.

3. همیشه از https استفاده کنید

هرگز و منظور ما هرگز JWT ها را از طریق HTTP ساده انتقال دهید. شما همچنین ممکن است توییت های AUTH خود را توییت کنید.

HTTPS برای حمل و نقل ایمن قابل مذاکره نیست. این 2FA بزرگراه اینترنت است.

4. نشانه ها را در فضای محلی ذخیره نکنید مگر اینکه XSS را دوست داشته باشید

LocalStorage مانند قرار دادن کلید خانه خود در زیر تشک خوش آمدید با عنوان “خوش آمدید” است. اگر یک مهاجم XSS (برنامه نویسی متقابل) را بیرون بکشد ، نشانه های شما نان تست می شوند.

گزینه بهتر: استفاده کنید کوکی های Samesite ایمن ، فقط HTTP ،بشر از طریق JavaScript قابل دسترسی نیست و بیشتر مقاوم به XSS است.

5. اسرار را به طور مرتب بچرخانید

اگر JWT Secret شما نشت می کند و آن را نمی چرخانید ، مهاجمان می توانند برای همیشه نشانه های خود را نعناع کنند. اسرار را بچرخانید و یک مکانیزم بازگشت برای نشانه های موجود بسازید.

Pro Move: استفاده کنید kid (شناسه کلید) در هدر JWT تا سرور شما بتواند از کدام کلید برای امضای توکن استفاده کند و بر همین اساس بچرخد.

6. نشانه های لیست سیاه در ورود به سیستم یا تنظیم مجدد رمز عبور

JWT ها در ورود به سیستم نمی میرند شما آنها را به صورت دستی می کشید.

استفاده:

• jti (jwt id) در نشانه

• یک دنیلاست در redis یا db شما
• Expiry Auto-Expiry در ورودی های دنییلیست برای لاغر نگه داشتن آن

هنگامی که کاربر رمز ورود خود را از سیستم خارج یا تنظیم مجدد می کند ، Token را پرتاب کنید jti به لیست سیاه

7. همه چیز را تأیید کنید

همانطور که قبلاً پوشش داده شد ، اعتبارسنجی کنید:

• امضاء

• expبا iatبا nbf مطالبات

• issبا aud زمینه ها اگر با شخص ثالث AUTH سر و کار دارید

• نوع توکن اگر از چندین مورد استفاده می کنید (Access vs Refresh)

پاداش: از API های خود با محدود کردن نرخ + چک های IP محافظت کنید

فقط به این دلیل که شخصی JWT معتبر دارد به این معنی نیست که باید به آنها اجازه دهید سرور شما 1000x در دقیقه را چکش کند. در صورت لزوم از محدود کردن نرخ ، فیلتر IP و تشخیص ربات استفاده کنید.

این فقط “خوب بودن” نیست. این شیوه ها باسن خود را ذخیره کنید وقتی اوضاع اشتباه می شود و آنها اراده در یک مقطع اشتباه کنید

گاهی اوقات بهترین راه برای تأمین سیستم خود … فکر کردن مانند کسی است که سعی در شکستن آن دارد. بنابراین بیایید به جعبه ابزار یک هکر که تازه JWT شما را در طبیعت مشاهده کرده است ، نگاهی بیندازیم. اسپویلر: این آسانتر از آن است که فکر می کنید.

یک JWT را در دید ساده رمزگشایی کنید

هر کسی می تواند JWT را با استفاده از رمزگشایی کند atob() در مرورگر یا به طور کامل با:

مثال:

echo "eyJhbGciOi..." | cut -d "." -f2 | base64 -d

و رونق اکنون آنها بار شما را دریافت کرده اند:

{
"sub": "007",
"role": "admin",
"exp": 1730240000
}

هیچ راز لازم نیست. این زیبایی (و نفرین) Base64 است که رمزگذاری می شود ، نه رمزگذاری.

هکر فکر کرد:

“هوم … اگر من این بار را تغییر دهم ،” نقش “را به” مدیر “تغییر دهم ، تنظیم کنید alg به none، و آن را برگردانید؟ “

این جایی است که رمزگشایی نشده می تواند هسته ای باشد. اگر سرور شما کورکورانه به یک نشانه اعتماد دارد زیرا نگاه داشتن مشروع ، شما تمام شده اید.

آزمون آسیب پذیری های الگوریتم

یک ترفند هکر رایج اصلاح هدر توکن است:

{
"alg": "none"
}

برخی از کتابخانه های JWT قدیمی تر یا غلط تنظیم شده ، در صورت وجود این هدر ، از چک امضای در کل استفاده می کنند.

کتابخانه های مدرن این را برطرف می کنند، اما شما هنوز هم باید صریح الگوریتم های پذیرفته شده را مشخص کنید (HS256با RS256) هنگام تأیید

بررسی کنید که آیا راز گنگ است

اگر برنامه شما از یک راز ضعیف مانند استفاده می کند 123456 یا jwt_secretمهاجمان می توانند با استفاده از ابزارهایی مانند JWT Cracker ، آن را بی رحمانه کنند.

استفاده کردن اسرار قوی یا حتی بهتر ، با جفت های کلید خصوصی/عمومی به Rs256 تغییر دهید.

ابزارهای هکر در طبیعت:

نکته DEV: بعد از هر نشانه ای که تولید می کنید ، از خود بپرسید “اگر من یک هکر بودم ، می توانم با این کار دست و پنجه نرم کنم و هنوز هم وارد شوم؟”

JWT ها می توانند فوق العاده قدرتمند باشند اما جادویی نیستند. آنها لکه های متن کوچک گنگ هستند که فقط وقتی قابل اعتماد می شوند شما با شک و تردید آنها با آنها رفتار می کنیدبشر

اگر این موضوع را تا کنون خوانده اید ، در اینجا چیزی است که اکنون می دانید و هرگز نباید فراموش کنید:

غذای اصلی

• jwts رمزگذاری نکنید داده های شما فقط آن را رمزگذاری کرده و امضا می کنند.
• همیشه تأیید کردن JWTS با کتابخانه های مناسب و تنظیمات دقیق.
• توکن های طولانی مدت مانند زباله های رادیواکتیو را که همیشه انقضا می کند ، درمان کنید.
• از ذخیره نشانه ها در localStorage در صورت امکان از کوکی های ایمن و فقط HTTP استفاده کنید.
• استفاده کردن نشانه های تازه با احتیاط ، و لیست سیاه آنها در ورود به سیستم یا تنظیم مجدد رمز عبور.
• تأیید همه چیز expبا issبا audبا algبا jti، و بیشتر
• اسرار خود را بچرخانید و سیستم های خود را مانند یک پارانوئید با دسترسی به کافئین کنترل کنید.

مشاوره نهایی

JWT ها ذاتاً شکسته نیستند اجرای بد استبشر این مانند این است که به کسی یک چراغ برق بدهید و فراموش کنید که به آنها بگویید که می تواند پای خود را از بین ببرد.

اگر در حال ساختن یک برنامه مدرن با API ، میکروسرویس یا مشتری های تلفن همراه هستید که می توانند درخشش داشته باشند. اما اگر به بی تابعیت احتیاج ندارید یا پیچیدگی را نمی خواهید ، آن را مجبور نکنید. جلسات هنوز سیلی می زنند.

منابع و ابزارهای مفید

به یاد داشته باشید: لایه auth شما فقط به اندازه درک شما از آن قوی است.
اجازه ندهید یک رشته 3 قسمتی ضعیف ترین قسمت پشته امنیتی شما باشد.