Passkey یا کلید عبور به کاربر اجازه می‌دهد بدون وارد کردن رمز حساب، وارد یک سرویس شود. تأیید روی دستگاه انجام می‌شود و سایت پاسخ رمزنگاری‌شده را بررسی می‌کند. این تغییر بخشی از دردسر حفظ و تکرار رمزها را کم می‌کند، اما حذف کادر رمز به‌تنهایی محصول را آماده نمی‌کند. کاربری که تلفنش را عوض کرده یا به کلید خود دسترسی ندارد، هنوز باید راه روشنی برای ادامه داشته باشد.
این راهنما با مراجعه به منابع رسمی در ۹ اکتبر ۲۰۲۶ بازبینی شده است. درباره نرخ استفاده همه کاربران یا زمان ثابت پیاده‌سازی ادعایی نداریم. سازگاری، مسیر بازیابی و سیاست حساب برای هر سرویس متفاوت است. مثال‌ها آموزشی‌اند و طراحی کامل امنیتی را جایگزین نمی‌کنند. هدف، مشخص کردن سؤال‌هایی است که تیم باید پیش از عرضه پاسخ دهد و تبدیل کردن آن‌ها به رفتار قابل فهم در محصول.
کلید عبور با رمز حساب چه تفاوتی دارد؟
معرفی رسمی FIDO Alliance کلید عبور را بر پایه رمزنگاری کلید عمومی توضیح می‌دهد. اعتبار ورود با یک جفت کلید مرتبط است و سرویس با بخش عمومی، پاسخ را بررسی می‌کند. کاربر راز مشترکی مثل رمز حساب را در فرم سایت تایپ نمی‌کند. این تفاوت زمینه مقاومت در برابر فیشینگ و استفاده دوباره از رمز دزدیده‌شده را فراهم می‌کند.
تأیید کاربر ممکن است با اثر انگشت، تشخیص چهره یا روش باز کردن دستگاه مثل PIN انجام شود. اثر انگشت قرار نیست به سایت فرستاده شود. بنابراین Passkey را با «ورود فقط با چهره» یکسان ندانید. روش قابل استفاده به دستگاه و تنظیمات آن وابسته است. متن رابط باید توضیح دهد چه کاری روی دستگاه رخ می‌دهد، بدون اینکه یک گزینه خاص را برای همه کاربران فرض کند.
مقاومت در برابر فیشینگ، امنیت کامل حساب نیست
کلید عبور به سرویس مربوط متصل است و مانند رمز قابل تایپ در هر صفحه نیست. با این حال، حساب فقط از مسیر ورود تشکیل نمی‌شود. نشست فعال، دستگاه، تغییر ایمیل، بازیابی و اختیارات پشتیبانی هم در نتیجه امنیت اثر دارند. اگر بازیابی به‌سادگی قابل سوءاستفاده باشد، قوی‌تر شدن ورود اصلی مسئله را کامل حل نکرده است. تیم باید مسیرهای مختلف دسترسی را کنار هم ببیند.
در مثال فرضی پنل کاری، کاربر با کلید عبور وارد می‌شود اما تغییر مالک حساب تنها با تماس و چند اطلاعات عمومی انجام می‌شود. این طراحی مرز حساس دیگری ساخته است. پرسش مناسب این است که هر عملیات مهم چه تأییدی لازم دارد و کدام نقش اختیار آن را دارد. از شعار «دیگر چیزی هک نمی‌شود» برای معرفی قابلیت استفاده نکنید؛ رفتار واقعی و محدوده حفاظت را روشن کنید.
همگام‌سازی و وابستگی به دستگاه را توضیح دهید
بعضی کلیدهای عبور از طریق ارائه‌دهنده مربوط میان دستگاه‌های کاربر همگام می‌شوند و بعضی به یک دستگاه یا ابزار مشخص وابسته‌اند. این تفاوت روی جابه‌جایی دستگاه و ادامه دسترسی اثر دارد. فرض نکنید همه کاربران دقیقاً یک تجربه دارند. کسی که دستگاه تازه را به محیط مناسب متصل کرده ممکن است کلید همگام‌شده را در دسترس ببیند؛ برای کلید وابسته به دستگاه، از دست دادن ابزار وضعیت دیگری ایجاد می‌کند.
برای تیم محصول، نتیجه عملی نوشتن سناریوهاست: دستگاه فعلی، دستگاه دوم، دستگاه مشترک و از دست رفتن دسترسی. این وضعیت‌ها نباید فقط در یادداشت توسعه باقی بمانند. کاربر در بخش مدیریت حساب باید بداند چه کلیدهایی ثبت شده‌اند و برای افزودن یا حذف آن‌ها چه اقدامی دارد. نام قابل فهم برای کلید، از فهرستی با شناسه فنی مفیدتر است و انتخاب درست را آسان‌تر می‌کند.
ساخت کلید را در زمان مناسب پیشنهاد دهید
پیشنهاد ساخت کلید باید بعد از روشن بودن هویت حساب و در شرایط مناسب مطرح شود. کاربری که کار فوری دارد شاید آماده فهم تنظیم تازه نباشد. توضیح کوتاه نشان دهد این قابلیت چه تغییری در ورود ایجاد می‌کند و چگونه مدیریت می‌شود. اجازه بدهید تصمیم بدون فشار و با مسیر قابل ادامه گرفته شود. اضافه شدن قابلیت امنیتی نباید کار اصلی را بی‌دلیل متوقف کند.
راهنمای ثبت کلید در web.dev جریان ساخت اعتبار و تعامل مرورگر و سرور را معرفی می‌کند. تأیید ثبت را پس از تکمیل سمت سرور نشان دهید. باز شدن پنجره دستگاه یا دریافت نتیجه در مرورگر به‌تنهایی برای اعلام موفقیت نهایی کافی نیست. پیام پایان باید با وضعیت حساب هماهنگ باشد تا کاربر در ورود بعدی غافلگیر نشود و بداند این روش واقعاً ثبت شده است.
صفحه ورود باید مسیرهای موجود را روشن کند
در دوره گذار، حساب‌ها ممکن است روش‌های مختلف ورود داشته باشند. دکمه‌ها باید نشان دهند کاربر کدام مسیر را انتخاب می‌کند و اگر کلیدی ندارد چه کاری می‌تواند انجام دهد. اصطلاح فنی را بدون توضیح تنها نام گزینه نگذارید. برای کاربری که با مفهوم آشنا نیست، یک جمله درباره تأیید روی دستگاه از چند پاراگراف بازاریابی مفیدتر است. توضیح را نزدیک همان تصمیم قرار دهید.
راهنمای ورود از طریق تکمیل خودکار فرم یکی از مسیرهای تجربه ورود را شرح می‌دهد. رفتار دقیق باید با قابلیت مرورگر و کتابخانه انتخابی هماهنگ باشد. کاربر ممکن است درخواست را لغو کند؛ این اتفاق را همیشه خطای خطرناک نشان ندهید. لغو، نبود کلید قابل استفاده و شکست ارتباط، پیام و قدم بعدی متفاوتی می‌خواهند. یک پیام یکسان برای همه، مسئله را مبهم نگه می‌دارد.
بازیابی را پیش از حذف رمز طراحی کنید
کاربر فرضی تلفنش را از دست داده و می‌خواهد وارد حساب شود. تیم باید بداند کدام روش‌های دیگری در دسترس‌اند و درخواست بازیابی چگونه بررسی می‌شود. پاسخ «با کلید عبور وارد شوید» در چنین موقعیتی کمکی نمی‌کند. بازیابی باید برای صاحب حساب قابل انجام باشد و از تغییر مالکیت بی‌ضابطه جلوگیری کند. پیچیدگی تصمیم به حساسیت داده و سیاست سرویس مربوط است؛ یک مسیر عمومی برای همه حساب‌ها کافی نیست.
افزودن ابزار یا کلید دیگری می‌تواند بخشی از برنامه دسترسی باشد، اما توضیح باید با روش‌های پشتیبانی‌شده سرویس سازگار بماند. روش پشتیبان را بدون بررسی معرفی نکنید. کاربر باید پیامد حذف آخرین روش قابل استفاده را بفهمد. این حذف ظاهراً ساده می‌تواند دسترسی آینده را تغییر دهد و به پیام روشن نیاز دارد. برای حذف کلید قدیمی و افزودن کلید تازه نیز ترتیب اقدامات را قابل فهم کنید.
پیاده‌سازی فقط فراخوانی یک API نیست
ساخت و ورود باید در سمت سرور بررسی معتبر داشته باشند. چالش، دامنه مورد انتظار، ارتباط اعتبار با حساب و نتیجه تأیید کاربر موضوع‌هایی هستند که باید با کتابخانه و مستندات معتبر رسیدگی شوند. نمونه کوتاه رابط جای این منطق را نمی‌گیرد. اگر کتابخانه آماده انتخاب می‌کنید، محدوده مسئولیت آن و پیکربندی لازم را مشخص کنید. نصب بسته به معنی پایان طراحی حساب و ورود نیست.
برای تفاوت شکل درخواست و اجازه انجام عملیات، راهنمای اعتبارسنجی داده با Zod ادامه مرتبطی است. دریافت شیء با ساختار درست، اعتبار پاسخ ورود را اثبات نمی‌کند. اعتبارسنجی ساختاری و بررسی امنیتی نقش‌های جدا دارند. تغییر تنظیم حساس حساب نیز باید در همان مدل دسترسی دیده شود تا مسیر فرعی تصمیم ورود را دور نزند. این تفکیک به تقسیم کار توسعه‌دهندگان هم کمک می‌کند.
از یک مسیر محدود و قابل مشاهده شروع کنید
برای عرضه اولیه، گروه کاربران و سناریو را مشخص کنید. مثلاً کاربران فعلی پس از ورود کلید اضافه کنند و مسیر قبلی حسابشان هنوز حفظ شود. این نمونه آموزشی برای بحث تیم است، نه توصیه قطعی به همه سرویس‌ها. هدف دیدن موانع ثبت، ورود و پشتیبانی پیش از تغییر بزرگ است. تصمیم بعدی باید با اطلاعات همان محصول گرفته شود، نه صرفاً موفقیت یک نمونه نمایشی.
رخدادهای لازم را بدون ثبت داده حساس دنبال کنید: شروع ثبت، پایان موفق، لغو و شکست قابل دسته‌بندی. درباره ورود هم روشن کنید کدام حساب‌ها کلید دارند و چه مشکلی رخ می‌دهد. افزایش ثبت به‌تنهایی بهتر شدن تجربه را ثابت نمی‌کند. شاید کاربر کلید ساخته اما بعداً مسیر ورود را پیدا نکرده است. معیار باید به کامل شدن کار و امکان ادامه دسترسی مربوط باشد و علت شکست را قابل بررسی کند.
تجربه دستگاه و پشتیبانی را فراموش نکنید
رابط موبایل و پنجره تأیید دستگاه روی درک کاربر اثر دارند. مقاله طراحی موبایل‌نخست برای وب‌اپ برای مرور حالت انتظار و خطا مفید است. کاربر باید بداند هنوز در سایت است یا باید روی دستگاه اقدامی انجام دهد. بعد از برگشت از آن مرحله نیز وضعیت باید قابل فهم باشد، حتی اگر عملیات کامل نشده باشد. تفاوت محیط‌ها را در توضیح کوتاه و جای مناسب نشان دهید.
پشتیبانی باید واژگان و مسیر واقعی سرویس را بشناسد. «دستگاه عوض شده» یا «کلید دیده نمی‌شود» با «رمز را فراموش کرده‌ام» یکسان نیستند. راهنمای داخلی را بر اساس سناریو بنویسید و اختیار تغییر حساب را روشن نگه دارید. وضعیت Passkey در محصول شما با همین تصمیم‌ها مشخص می‌شود: کاربر چگونه وارد می‌شود، چه چیزی را مدیریت می‌کند و وقتی مسیر معمول در دسترس نیست چه راهی دارد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!