احراز هویت اپلیکیشن؛ OTP، بیومتریک و امنیت نشست

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

Google Suggest برای این عبارت بیشتر نام اپ‌های مشخص را نمایش می‌دهد؛ این نشان می‌دهد کاربر فارسی‌زبان معمولاً هنگام نیاز فوری به ورود به یک برنامه جست‌وجو می‌کند، نه هنگام طراحی معماری. برای پوشش نیت آموزشی، این راهنما از عبارت‌های هم‌خانوادهٔ «ورود با رمز یک‌بارمصرف»، «OTP»، «Refresh Token»، «بیومتریک» و «امنیت نشست» استفاده می‌کند. مقاله جایگزین صفحه تجاری طراحی اپلیکیشن روبینش یا ارزیابی امنیتی تخصصی نیست؛ فقط چارچوب تصمیم فنی و محصولی را روشن می‌کند.

Native apps are public clients. Authorization servers SHOULD implement PKCE for all public clients, and clients MUST use PKCE when supported by the authorization server.

احراز هویت و سطح دسترسی چه تفاوتی دارند؟

احراز هویت یا Authentication به سؤال «شما چه کسی هستید؟» جواب می‌دهد. مجوزدهی یا Authorization می‌پرسد «شما چه کاری اجازه دارید انجام دهید؟». ورود موفق کارمند به اپ به او اجازه دیدن همه سفارش‌ها، تغییر حساب بانکی یا حذف داده را نمی‌دهد. نقش، مالکیت داده و سیاست هر عملیات باید در سرور بررسی شوند، نه فقط با پنهان‌کردن دکمه در رابط.

این تفاوت در محصول‌های چندنقشی حیاتی است. مشتری ممکن است سفارش خودش را ببیند، اپراتور فقط سفارش شعبه خود را مدیریت کند و مدیر گزارش گسترده‌تر داشته باشد. توکن ورود می‌تواند هویت را حمل کند، اما منطق «چه کسی چه چیزی را می‌بیند» باید از منبع داده و مجوز سرور بیاید. مدل نقش و داده حساس را در راهنمای اپلیکیشن سازمانی نیز بررسی کرده‌ایم.

برای ورود اپ، OTP بهتر است یا رمز عبور؟

رمز یک‌بارمصرف پیامکی برای محصول‌هایی مناسب است که شماره تلفن شناسه اصلی کاربر است و فرایند ورود باید کوتاه بماند. اما OTP بدون محدودیت تلاش، زمان انقضا، کنترل ارسال مجدد و حفاظت در برابر سوءاستفاده، امن نیست. شماره را مانند شناسه شخصی ببینید، پیامک را لاگ حساس بدانید و هر کد را فقط یک‌بار و برای مدت کوتاه معتبر نگه دارید. شماره پیامکی هرگز نباید در لاگ عمومی یا پیام خطای مرورگر ظاهر شود.

رمز عبور همچنان برای بعضی سیستم‌ها کاربرد دارد، به‌ویژه وقتی بازیابی حساب و ورود از چند دستگاه مهم است. رمز را هرگز به‌صورت متن خام ذخیره نکنید؛ در سرور از الگوریتم هش مناسب و سیاست محدودسازی تلاش استفاده کنید. «رمز پیچیده» بدون مدیر رمز یا بازیابی قابل‌فهم، کاربران را به استفاده مجدد و یادداشت ناامن می‌رساند. انتخاب بین OTP و رمز، تصمیم تجربه و ریسک است؛ نه انتخاب تزئینی صفحه ورود.

Access Token و Refresh Token چه نقشی دارند؟

Access Token یک اعتبار کوتاه‌عمر برای درخواست‌های API است؛ Refresh Token امکان دریافت توکن تازه را می‌دهد تا کاربر برای هر انقضا مجبور به ورود دوباره نشود. این دو را یکی نگیرید. اگر Access Token کوتاه‌عمر افشا شود، پنجره سوءاستفاده محدودتر است؛ اگر Refresh Token افشا شود، مهاجم ممکن است نشست را طولانی کند. بنابراین Refresh Token باید با دقت بیشتر نگهداری و در صورت نیاز چرخانده شود.

برای اپ‌های native که با ارائه‌دهنده هویت کار می‌کنند، جریان Authorization Code همراه PKCE انتخاب شناخته‌شده‌ای است. اپ کلاینت عمومی است و نباید secret بلندمدت را داخل باینری مخفی فرض کند؛ هر چیزی در اپ قابل استخراج است. Redirect URI، `state`، PKCE verifier و بررسی سمت سرور جزئیات اجرایی مهم‌اند و نباید با «ورود سریع» قربانی شوند. قرارداد API و نسخه‌بندی آن را در راهنمای API جدا نگه دارید.

توکن را در اپ موبایل کجا نگهداری کنیم؟

توکن را در فضای ذخیره‌سازی امن سیستم‌عامل، مانند Keychain در iOS یا Keystore در Android، نگه دارید و از نگهداری آن در حافظه یا فایل‌های خوانای عمومی دوری کنید. کتابخانه‌ای که این فضا را استفاده می‌کند باید با مدل تهدید، نسخه سیستم‌عامل و نیاز محصول ارزیابی شود. ذخیره‌سازی امن، مجوز سرور را جایگزین نمی‌کند؛ فقط احتمال افشای اعتبار روی دستگاه را کاهش می‌دهد.

دستگاه گم می‌شود، کاربر گوشی را می‌فروشد و گاهی بدافزار وجود دارد. برای نشست‌های مهم، فهرست دستگاه‌ها، قابلیت خروج از راه دور و ابطال Refresh Token به شما کمک می‌کند. همچنین هنگام تغییر رمز، تغییر شماره یا رفتار غیرعادی، نشست‌های قبلی را بازبینی کنید. پنهان‌کردن token در نام متغیر یا فشرده‌سازی برنامه، حفاظت واقعی نیست.

بیومتریک در اپ چه کاری انجام می‌دهد؟

اثر انگشت و تشخیص چهره معمولاً باید برای بازکردن یک کلید یا نشست محلی روی همان دستگاه استفاده شوند؛ داده بیومتریک نباید به سرور شما ارسال شود. در عمل، کاربر ابتدا با یک روش هویت اصلی وارد می‌شود، سپس اپ برای بازکردن امن نشست ذخیره‌شده در استفاده‌های بعدی از بیومتریک کمک می‌گیرد. بیومتریک جایگزین مدیریت نشست و سطح دسترسی نیست.

همیشه مسیر جایگزین قابل‌فهم داشته باشید: PIN دستگاه، ورود دوباره یا بازیابی حساب. کاربر ممکن است سنسور آسیب‌دیده، دستکش، نور نامناسب یا تنظیمات غیرفعال داشته باشد. اگر عملیات حساس مانند تغییر حساب بانکی یا تایید تراکنش دارید، با توجه به ریسک می‌توان بازاحراز هویت خواست؛ اما درخواست مداوم بیومتریک برای هر کلیک تجربه را فرسوده می‌کند.

امنیت نشست در اپلیکیشن از کجا آسیب می‌بیند؟

نشست طولانی بدون امکان خروج، توکن ثبت‌شده در لاگ، درخواست API بدون بررسی نقش، و پیام خطای افشاکننده شناسه، نمونه‌های رایج مشکل‌اند. نرخ تلاش ورود و ارسال OTP را سمت سرور محدود کنید و پاسخ خطا را طوری بنویسید که به مهاجم نگویید کدام شماره یا ایمیل در سیستم وجود دارد. هشدار امنیتی به کاربر باید راه اقدام بدهد، نه صرفاً ترس ایجاد کند.

برای داده‌های مالی، پزشکی یا سازمانی، مدل تهدید را پیش از کدنویسی بنویسید: چه چیزی باید محافظت شود، چه کسی ممکن است حمله کند و بدترین اثر چیست؟ سپس کنترل متناسب انتخاب کنید. OWASP MASVS و راهنمای موبایل OWASP برای مرور کنترل‌ها منابع خوبی هستند، اما چک‌لیست را بدون فهم محصول کپی نکنید. امنیت موفق ترکیب طراحی، سرور، تست و پاسخ به رخداد است.

اشتباهات رایج در احراز هویت اپ

• قرار دادن client secret یا کلید سرویس در باینری اپ
• ذخیره توکن در فایل یا فضای عمومی قابل خواندن
• استفاده از Access Token بسیار بلندمدت به جای طراحی Refresh Token
• اعتماد به نقش ارسالی از کلاینت بدون کنترل سرور
• OTP بدون انقضا، محدودیت تلاش یا کنترل ارسال مجدد
• استفاده از بیومتریک بدون مسیر جایگزین برای کاربر
• ثبت رمز، کد یا توکن در لاگ خطا و ابزار تحلیل
• نداشتن خروج از راه دور و ابطال نشست پس از رخداد حساس

چک‌لیست طراحی ورود و نشست

1. هویت کاربر و سطح دسترسی او به‌صورت دو مسئله جدا تعریف شده‌اند.
2. روش ورود با ریسک داده و رفتار واقعی کاربر متناسب است.
3. OTP یا رمز، انقضا، محدودیت تلاش و بازیابی قابل‌فهم دارد.
4. Access Token کوتاه‌عمر و اعتبار تمدید نشست به‌صورت امن نگهداری می‌شود.
5. برای کلاینت عمومی، secret بلندمدت داخل اپ قرار نگرفته است.
6. توکن و داده حساس از لاگ، پیام خطا و فضای عمومی دور مانده‌اند.
7. بیومتریک فقط برای حفاظت محلی و با fallback روشن استفاده می‌شود.
8. نقش و مالکیت داده در هر API سمت سرور بررسی می‌شوند.
9. خروج، ابطال نشست و مدیریت دستگاه گم‌شده تعریف شده‌اند.
10. مسیر ورود، خطا و بازیابی روی دستگاه واقعی آزموده شده است.

جمع‌بندی: ورود امن، یک مسیر است نه یک صفحه

احراز هویت اپلیکیشن با فرم ورود شروع می‌شود، اما در نگهداری توکن، کنترل نقش، انقضای نشست، بیومتریک محلی و امکان ابطال پایان می‌گیرد. OTP برای همه محصول‌ها جواب واحد نیست و Refresh Token هم بدون ذخیره‌سازی و سیاست درست می‌تواند ریسک بسازد. تصمیم‌ها را از حساسیت داده و سناریوی واقعی کاربر بگیرید.

برای طراحی محصول موبایل و اتصال آن به API و نقش‌های عملیاتی، صفحه طراحی اپلیکیشن روبینش و در پروژه‌های چندسیستمی توسعه اختصاصی مسیرهای مرتبط‌اند. برای بررسی دامنه پروژه از فرم تماس روبینش استفاده کنید؛ این مقاله جای تست نفوذ یا مشاوره حقوقی امنیت نیست.