تمام وب سایت ها و اپلیکیشن ها نیاز جدی به احراز هویتی امن و ایمن و قابل اطمینان دارند. روش های مختلفی برای این موضوع وجود دارد برخی تنها در فضای وب مورد استفاده هستند و برخی بصورت Cross Platform هم قابل استفاده هستند.

احراز هویت مبتنی بر Session

درواقع Session موجودی است که به ازای اتصال هر مرورگر به سرور وب ایجاد میشود. هرکدام از سشن ها یک شناسه دارند و میتوانند در دل خود مقداری را ذخیره کنند. ما میتوانیم مشخصات کاربری که لاگین شده (که اصطلاحا به آن User Credentials میگوییم) را در سشن ذخیره کنیم. آنچه ذخیره میشود باید محافظت شده باشد وگرنه هرکس میتواند هویت کاربران را جعل کند.مثلا در سشن ذخیره شده User: reza,phone:099999999 و چون این اطلاعات در سمت مرورگر ذخیره شده برنامه نویس کنترل کاملی ندارد، هرکس میتوانید نام کاربری که در اینجا reza هست را به هر اسم دیگری تغییر دهد! پس در این شرایط اپلیکیشن وب باید تمام سشن های خود را بصورت رمزشده و غیرقابل حدس در مرورگر کاربر ذخیره کند تا امکان سرقت سشن یا Session Hijack از بین برود. تمامی فریمورک های وب امکان تعریف کلید برای رمز کردن سشن را دارند که در flask به آن Secret_key میگوییم.

اما آیا رمز کردن به تنهایی محتویات User Credential که در سشن ذخیره میشود را امن میکند؟ پاسخ این است خیر رمز کردن محتوا و ذخیره آن در سشن امن نمیشود گرچه مسیر را برای هکر سخت میکند!! مسیر برای هکر بشدت سخت شده اما چون در مرورگر کاربر ذخیره سازی انجام شده امکان شکستن رمز وجود دارد. با وجود پردازنده های قوی امروزی هکر میتواند ظرف چند روز تمرکز روی یک مقدار رمز شده، آنرا بشکند. احتمالا شما هم نمیتوانید مداوم کلید رمز یا همان Secret_key را مداوم عوض کنید هرچند که توصیه میشود در بازه های 40 روزه تغییر کند اما این موضوع نمیتواند مداوم انجام شود. پس رمز کردن هویت کاربر امری لازم است اما نمیتواند امنیت را برقرار کند چون صددرصد در مرورگر کاربر ذخیره شده و دسترسی به آن ممکن است.

راهکار HTTP Only

از راهکار HTTP Only میتوان برای راهکار تکمیلی در امن سازی سشن ها استفاده کرد. به این معنا که تنها Backend امکان دسترسی به سشن را داشته باشد، درواقع اجازه دسترسی از سمت کد های جاوااسکریپت بسته خواهد شد. این امر مطلوب است اما همیشه قابل پیاده سازی نیست. گاهی در اپلیکیشن های API Base و مبتنی بر AJAX الزام به دسترسی از مرورگر و جاوا اسکریپت به سشن وجود دارد.

احراز هویت مبتنی بر Token

احراز هویت مبتنی بر Token یکی از رایج‌ترین روش‌های شناسایی و کنترل دسترسی در معماری‌های مدرن نرم‌افزاری است که به‌ویژه در APIها، سیستم‌های توزیع‌شده، اپلیکیشن‌های تک‌صفحه‌ای و سرویس‌های موبایلی کاربرد گسترده‌ای دارد. در این روش، کاربر ابتدا اطلاعات هویتی خود مانند نام کاربری و گذرواژه را برای سرور ارسال می‌کند و پس از اعتبارسنجی موفق، سرور به‌جای نگهداری وضعیت نشست در حافظه خود، یک Token برای کاربر صادر می‌کند. این Token معمولاً شامل اطلاعاتی درباره هویت کاربر، سطح دسترسی، زمان صدور و زمان انقضا است و در هر درخواست بعدی از سوی کلاینت به سرور ارسال می‌شود. به این ترتیب، سرور می‌تواند بدون نیاز به Session سنتی و بدون ذخیره‌سازی متمرکز وضعیت هر کاربر، درخواست‌ها را اعتبارسنجی کند. این مدل به دلیل Stateless بودن، مقیاس‌پذیری بسیار بهتری در سیستم‌های ابری و سرویس‌گرا ایجاد می‌کند و وابستگی سرور به نگهداری وضعیت کاربران را به حداقل می‌رساند.

از منظر فنی، Token می‌تواند به اشکال مختلفی پیاده‌سازی شود، اما یکی از شناخته‌شده‌ترین قالب‌ها JSON Web Token یا JWT است. در ساختار JWT، اطلاعات در سه بخش Header، Payload و Signature قرار می‌گیرد. بخش Header نوع Token و الگوریتم امضا را مشخص می‌کند، بخش Payload شامل Claimهایی مانند شناسه کاربر، نقش‌ها و زمان انقضا است و بخش Signature برای جلوگیری از دستکاری داده‌ها به کار می‌رود. زمانی که کلاینت Token را در هدر Authorization و معمولاً با الگوی Bearer Token به سرور ارسال می‌کند، سرور امضای آن را بررسی کرده، تاریخ انقضا را می‌سنجد و در صورت معتبر بودن، اجازه دسترسی به منبع موردنظر را صادر می‌کند. با این حال، باید توجه داشت که Token به‌صورت ذاتی صرفاً یک ابزار حمل هویت و مجوز است و امنیت آن کاملاً به نحوه صدور، نگهداری، انتقال و اعتبارسنجی وابسته است. استفاده از HTTPS، تعریف زمان انقضای کوتاه، بهره‌گیری از Refresh Token، و جلوگیری از ذخیره ناامن Token در سمت کلاینت از مهم‌ترین ملاحظات فنی این معماری هستند.

احراز هویت مبتنی بر Token نسبت به مدل‌های سنتی مبتنی بر Session مزایای متعددی دارد، اما در کنار این مزایا چالش‌های خاص خود را نیز به همراه می‌آورد. مهم‌ترین مزیت آن استقلال هر درخواست از وضعیت سرور است که طراحی سیستم‌های مقیاس‌پذیر، توزیع‌شده و مبتنی بر میکروسرویس را ساده‌تر می‌کند. همچنین این روش برای ارتباط بین فرانت‌اند و بک‌اند در معماری‌های جداشده بسیار مناسب است، زیرا Token می‌تواند به‌سادگی میان کلاینت‌های مختلف مانند مرورگر، اپلیکیشن موبایل و سرویس‌های ثالث ردوبدل شود. در مقابل، یکی از چالش‌های اصلی این است که در صورت سرقت Token، مهاجم تا پایان اعتبار آن می‌تواند به منابع دسترسی داشته باشد؛ به همین دلیل سیاست‌های امنیتی مانند Blacklist کردن Tokenها، استفاده از Rotate برای Refresh Token و طراحی سازوکار Logout امن اهمیت بالایی دارند. در مجموع، احراز هویت مبتنی بر Token یک راهکار مدرن، منعطف و کارآمد برای مدیریت هویت و دسترسی است، به شرطی که با درک دقیق اصول امنیتی و پیاده‌سازی درست در لایه‌های مختلف سیستم مورد استفاده قرار گیرد.

توکن Bearer Token چیست؟

در احراز هویت مبتنی بر توکن، «Bearer» فقط یکی از الگوهای ارسال/استفاده از توکن است، نه خودِ مکانیزم احراز هویت. در مدل Bearer، هر کسی که توکن را در اختیار داشته باشد عملاً «دارنده‌ی مجاز» تلقی می‌شود؛ یعنی سرور معمولاً فقط اعتبار توکن را بررسی می‌کند و کاری ندارد چه کسی واقعاً آن را حمل کرده است. به همین دلیل در هدر Authorization: Bearer <token> اگر توکن لو برود، مهاجم تا زمان انقضا یا ابطال آن می‌تواند از آن استفاده کند. مزیت اصلی Bearer سادگی، استاندارد بودن، سازگاری بالا با OAuth 2.0، SPAها، موبایل و APIها است. اما همین سادگی، نقطه‌ضعف امنیتی آن هم هست، چون توکن به هویت یا کلید اختصاصی کلاینت «بایند» نشده است. به همین علت استفاده از HTTPS، زمان انقضای کوتاه، Refresh Token امن و ذخیره‌سازی صحیح در کلاینت برای Bearer حیاتی است.

چه جایگزین هایی برای Bearer وجود دارد؟

جایگزین‌های Bearer معمولاً با هدف کاهش ریسک سرقت توکن یا اثبات واقعی هویت درخواست‌کننده طراحی شده‌اند. یکی از مهم‌ترین جایگزین‌ها الگوی Proof-of-Possession یا PoP است. در این مدل، صرف داشتن توکن کافی نیست و کلاینت باید ثابت کند مالک یک کلید خصوصی یا یک راز مرتبط با توکن است. یکی از نمونه‌های مهم این خانواده، DPoP است که در آن کلاینت برای هر درخواست، یک JWT امضاشده تولید می‌کند و نشان می‌دهد علاوه بر توکن، کلید خصوصی متناظر را هم در اختیار دارد؛ بنابراین اگر فقط خودِ توکن سرقت شود، بدون کلید خصوصی قابل استفاده نخواهد بود. مدل دیگر Mutual TLS یا mTLS است که در آن توکن به گواهی کلاینت متصل می‌شود و سرور فقط زمانی آن را می‌پذیرد که درخواست از همان کلاینت دارای گواهی معتبر آمده باشد. در سطحی قدیمی‌تر و متفاوت، الگوهایی مانند API Key نیز وجود دارند که اگرچه از نظر فنی ساده‌اند، اما معمولاً برای شناسایی مصرف‌کننده سرویس استفاده می‌شوند و به‌تنهایی جایگزین کامل و امنی برای Bearer در سناریوهای حساس نیستند. همچنین در برخی سیستم‌ها از امضای درخواست مانند HMAC Authentication استفاده می‌شود که در آن به‌جای ارسال صرف یک توکن قابل‌استفاده‌مجدد، هر درخواست با یک کلید مشترک امضا می‌شود تا اصالت و تمامیت آن قابل بررسی باشد.

در عمل، انتخاب بین Bearer و جایگزین‌های آن به سطح امنیت، نوع کلاینت، زیرساخت و پیچیدگی قابل‌قبول بستگی دارد. اگر سیستم شما یک API عمومی یا اپلیکیشن معمولی وب و موبایل باشد، Bearer به دلیل سادگی پیاده‌سازی و پشتیبانی گسترده، همچنان رایج‌ترین انتخاب است. اما اگر با داده‌های حساس، محیط‌های سازمانی، زیرساخت بانکی، سرویس‌های بین‌سرویسی یا تهدیدهای پیشرفته‌تر مواجه باشید، استفاده از الگوهای قوی‌تر مانند DPoP، mTLS یا امضای مبتنی بر HMAC می‌تواند امنیت را به‌طور قابل‌توجهی افزایش دهد. تفاوت اصلی این رویکردها در این است که Bearer بر «داشتن توکن» تکیه دارد، در حالی که الگوهای جایگزین بر «اثبات مالکیت» یا «امضای معتبر درخواست» متکی هستند. بنابراین هرچه ارزش دارایی‌های دیجیتال بیشتر و ریسک حمله بالاتر باشد، حرکت از Bearer به سمت مدل‌های مبتنی بر اثبات مالکیت منطقی‌تر خواهد بود، هرچند این انتخاب معمولاً با هزینه بیشتر در پیاده‌سازی، مدیریت کلید و پیچیدگی عملیاتی همراه است.

توکن JWT چیست؟

JWT یا JSON Web Token یک استاندارد فشرده و قابل‌حمل برای انتقال امن اطلاعات بین دو طرف به‌صورت یک رشته متنی است که معمولاً در احراز هویت و مجوزدهی در APIها استفاده می‌شود. این توکن از سه بخش Header، Payload و Signature تشکیل می‌شود؛ بخش Header نوع توکن و الگوریتم امضا را مشخص می‌کند، Payload شامل داده‌هایی مانند شناسه کاربر، نقش و زمان انقضا است و Signature برای اطمینان از عدم دستکاری محتوا به کار می‌رود. JWT به‌دلیل Stateless بودن باعث می‌شود سرور بدون نگهداری Session بتواند هویت کاربر را در هر درخواست بررسی کند، اما در عین حال باید با دقت استفاده شود، چون اطلاعات داخل آن معمولاً فقط رمزگذاری نشده‌اند بلکه امضاشده‌اند و در صورت سرقت توکن، تا زمان انقضا امکان سوءاستفاده وجود دارد.