سازمانها و توسعهدهندگان هنگام انتقال کاربران از رمزهای عبور به کلیدهای عبور با مانع قابل توجهی روبرو هستند. در حالی که کلیدهای عبور یک ارتقاء امنیتی حیاتی را فراهم میکنند، فرآیند ایجاد دستی اغلب میتواند باعث ایجاد اصطکاک شود. در یک محیط تجارت الکترونیک با حجم بالا، هر ثانیه تردید اهمیت دارد، زیرا هرگونه تأخیر میتواند به طور بالقوه مسیر خرید را مختل کرده و منجر به رها کردن سبد خرید شود. علاوه بر این، همگامسازی وضعیت اعتبارنامهها بین سرور و دستگاه کاربر برای جلوگیری از خطاهای ورود به سیستم و ناامیدی کاربر ضروری است.
آدیداس دقیقاً با همین چالشها روبرو بود. هدف اصلی آنها حذف موانع از فرآیند ورود به سیستم و سادهسازی تجربه کاربری در پلتفرمها و دستگاههای وب و اپلیکیشن بود. در حالی که امنیت همچنان از اولویت بالایی برخوردار است، تیم محصول بر یکپارچهسازی هرچه بیشتر جریانهای ثبت نام و ورود به سیستم با استفاده از کلیدهای عبور تمرکز کرد.
برای مقابله با این چالشها، آدیداس قابلیت ایجاد شرطی (Conditional Create) را برای ارتقاء خودکار رمز عبور کاربران به کلیدهای عبور و رابط برنامهنویسی کاربردی (API) سیگنال (Signal API) را برای حفظ ثبات اعتبارنامهها پیادهسازی کرد. علاوه بر این، آنها درخواستهای مبدا مرتبط (Related Origin Requests) را برای پشتیبانی از استفاده بین دامنهای در صورت نیاز، مستقر کردند.
نتایج
استراتژی آدیداس در خودکارسازی ایجاد رمز عبور و حفظ سلامت اعتبارنامه، نتایج فوری و قابل اندازهگیری را هم در پذیرش و هم در قابلیت اطمینان ورود به سیستم به همراه داشت:
- نرخ پذیرش بالا: از زمان راهاندازی فرآیند ورود با رمز عبور، آدیداس به نرخ کلی ایجاد رمز عبور ۴۷٪ دست یافته است. این شامل ایجاد شرطی خودکار و گزینههای انتخابی کاربر هنگام درخواست در جریانهای ثبت نام یا ورود به سیستم میشود. این پذیرش به ویژه در دستگاههای تلفن همراه بالا بود که نرخ تبدیل ۵۲٪ (در مقایسه با ۳۴٪ در دسکتاپ) داشتند.
- ارتقاء سریع با استفاده از ایجاد شرطی: فراتر از درخواستهای صریح، آدیداس با ارتقاء یکپارچه کاربران رمز عبور موجود در پسزمینه، بدون نیاز به اقدام دستی کاربر، به افزایش ۸ درصدی در ایجاد رمز عبور دست یافت.
- قابلیت اطمینان تقریباً بینقص ورود به سیستم: رمزهای عبور پس از شروع ورود، نرخ موفقیت بیش از ۹۹٪ را ارائه دادند. این یک ارتقاء امنیتی بزرگ در مقایسه با نرخ موفقیت رمز عبور تاریخی آدیداس ۷۰٪ است که اغلب به دلیل خطاهای انسانی مانند غلط املایی یا فراموشی اعتبارنامه کاهش مییافت.
- کاهش اصطکاک و خطاها: آدیداس با بهکارگیری API سیگنال برای همگامسازی خودکار اعتبارنامههای دستگاه و سرور، با موفقیت خطاهای
PASSKEY_NOT_FOUNDرا به کمتر از ۰.۳٪ از تلاشهای ورود به سیستم رساند. این امر به طور مؤثر ناامیدی کاربران از کلیدهای عبور یتیم را از بین برد.
۴۷ ٪
نرخ ایجاد کلید عبور
۸ ٪
ارتقاء در ایجاد کلید عبور با استفاده از ایجاد شرطی
>99 %
میزان موفقیت ورود با رمز عبور پس از شروع
<0.3 ٪
نرخ خطای کلید عبور یتیم
آدیداس چگونه این مشکل را حل کرد؟
در اینجا نحوه برخورد آدیداس با این چالشها آمده است:
۱. سرعت بخشیدن به پذیرش با ایجاد شرطی
برای کمک به کاربران در استفادهی یکپارچه از کلیدهای عبور، آدیداس قابلیت ایجاد مشروط (Conditional Create) را پیادهسازی کرده است. این ویژگی به وبسایت اجازه میدهد تا هنگام ورود کاربر با رمز عبور ذخیره شده در مدیریت رمز عبور خود، بهطور خودکار یک کلید عبور ایجاد کند. برای اطمینان از بالاترین میزان موفقیت، سیستم بلافاصله پس از ورود موفقیتآمیز، API را فراخوانی میکند تا سیستم، رمز عبور را بهعنوان رمز عبور جدید تشخیص دهد.
const cred = await navigator.credentials.create({
publicKey: options,
mediation: 'conditional' // Enables automatic passkey creation
});
آدیداس این ویژگی را با منطق سفارشی ادغام کرده است که ابتدا محیط کاربر را اعتبارسنجی میکند. به طور خاص، سیستم بررسی میکند که آیا ویژگی ایجاد شرطی توسط مرورگر پشتیبانی میشود یا خیر. این سیستم همچنین با نادیده گرفتن این درخواست در صورتی که کاربر در شش ماه گذشته سه بار از ایجاد رمز عبور صرف نظر کرده باشد، به ترجیحات کاربر احترام میگذارد.
اگر محیط سازگار باشد، سیستم بلافاصله پس از تأیید هویت موفقیتآمیز کاربر، سعی میکند کلید عبور را در پسزمینه ایجاد کند. این زمانبندی خاص، احتمال برآورده شدن پیشنیازها را افزایش میدهد. نکته مهم این است که پیادهسازی، استثنائات WebAuthn را با فلسفه "fail-open" مدیریت میکند تا همیشه دسترسی کاربر را در اولویت قرار دهد. اگر مرورگر InvalidStateError را گزارش دهد که نشان میدهد احتمالاً یک کلید عبور از قبل وجود دارد، سیستم ایجاد پسزمینه را متوقف کرده و بلافاصله کاربر را وارد سیستم میکند. برعکس، اگر NotAllowedError رخ دهد، به این معنی که شرایط خاص برای ایجاد خودکار برآورده نشده است، سیستم این حالت را تشخیص داده و کاربر را به صفحه " Passkey Collector " هدایت میکند تا آنها را در یک فرآیند راهاندازی دستی راهنمایی کند. آدیداس با تمایز قائل شدن بین این محدودیتهای فنی و رفتارهای کاربر، اطمینان حاصل میکند که فشار برای ارتقاء کلید عبور، تجربه ورود به سیستم را بهبود میبخشد، نه اینکه آن را مختل کند.
۲. با استفاده از Signal API، قابلیت اطمینان را تضمین کنید
همانطور که کاربران اعتبارنامههای خود را در دستگاههای مختلف مدیریت میکنند، ممکن است ناهماهنگیهایی ایجاد شود. به عنوان مثال، ممکن است یک کلید عبور از سرور حذف شود اما در دستگاه کاربر باقی بماند. برای جلوگیری از خرابیهای ورود به سیستم ناشی از این اعتبارنامههای "فانتوم"، آدیداس API سیگنال را پیادهسازی کرد. این API به سرور اجازه میدهد تا وضعیت اعتبارنامهها را به ارائهدهنده کلید عبور اطلاع دهد.
آدیداس از هر سه متد موجود در Signal API برای حفظ این سازگاری استفاده میکند. آدیداس به جای حدس زدن اینکه کدام اعتبارنامهها را حذف کند، رویدادهای چرخه عمر کاربر خاص را به فراخوانی API مناسب نگاشت میکند:
- خطاهای ثبت نام: هنگامی که یک کلید عبور در کلاینت ایجاد میشود اما در backend ثبت نمیشود، آدیداس
signalUnknownCredentialبرای حذف فوری اعتبارنامهی یتیم استفاده میکند. - ورودهای نامعتبر: اگر کاربری سعی کند با یک رمز عبور باطل شده یا قدیمی وارد سیستم شود،
signalUnknownCredentialبه ارائه دهنده سیگنال میدهد که آن را پنهان کند. - مدیریت کاربر: وقتی کاربری صراحتاً رمز عبوری را در تنظیمات حساب خود حذف میکند،
signalAllAcceptedCredentialsلیست مجوزها را همگامسازی میکند. این کار تضمین میکند که رمز عبور حذف شده دیگر ارائه نشود. - بهروزرسانیهای حساب کاربری: وقتی کاربری ایمیل یا نام کاربری خود را تغییر میدهد،
signalCurrentUserDetailsفرادادههای دستگاه را بهروزرسانی میکند تا با سرور مطابقت داشته باشد.
// Detect authentication failure due to lack of the credential
if (result.status === 404) {
if (PublicKeyCredential.signalUnknownCredential) {
await PublicKeyCredential.signalUnknownCredential({
rpId: "adidas.com",
credentialId: "..." // base64url encoded credential ID
});
}
}
۳. دسترسی را با درخواستهای مبدا مرتبط و لینکهای دارایی دیجیتال یکپارچه کنید
آدیداس برای پشتیبانی بیشتر از معماری چندبازاری خود، درخواستهای مبدا مرتبط را پیادهسازی کرد. در حالی که اکثر کاربران به بازار محلی خود (به عنوان مثال، adidas.nl ) پایبند هستند، این پیکربندی به کاربرانی که بین مناطق مختلف حرکت میکنند، اجازه میدهد تا با هدف قرار دادن یک شناسه طرف اتکا ( adidas.com )، از کلیدهای عبور در دامنههای مجاز استفاده مجدد کنند.
برای فعال کردن این قابلیت، آدیداس یک فایل پیکربندی webauthn را در دامنه اصلی Relying Party ID (RP ID) خود میزبانی میکند. این فایل حاوی یک لیست مجاز صریح از مبداهایی است که مجاز به استفاده adidas.com برای ثبت و احراز هویت رمز عبور هستند. با تعریف این روابط، مرورگر میتواند تأیید کند که رمز عبور ایجاد شده در یک سایت منطقهای برای استفاده در سایت دیگر معتبر است و تجربهای بدون مشکل را برای کاربران جهانی فراهم میکند.
// https://www.adidas.com/.well-known/webauthn
{
"origins": [
"https://www.adidas.fi",
"https://www.adidas.nl",
// ... abridged (the full file lists 50+ regional domains)
]
}
نکته مهم این است که آدیداس همچنین با استفاده از Digital Asset Links، پشتیبانی یکپارچه از رمز عبور را در برنامههای تلفن همراه اندروید خود ارائه داد. از آنجایی که برنامهها از یک WebView میزبانی شده در idp.adidas.com برای احراز هویت استفاده میکنند، Digital Asset Links موظف بود یک رابطه قابل اعتماد بین برنامه اندروید و شناسه طرف مربوطه ( adidas.com ) برقرار کند. این تأیید به برنامه اجازه میدهد تا به همان رمزهای عبور استفاده شده در وب دسترسی داشته باشد و یک تجربه ورود به سیستم یکپارچه و روان را در بین پلتفرمها ایجاد کند.
برای دستیابی به این هدف، آدیداس یک فایل Digital Asset Links ( assetlinks.json ) را در دامنههای وب مربوطه خود میزبانی میکند. این فایل به طور عمومی ارتباط رمزنگاری با برنامههای اندروید آنها را اعلام میکند. به طور مشابه، آدیداس برای پشتیبانی از اکوسیستم iOS خود از Associated Domains استفاده میکند. با میزبانی یک فایل apple-app-site-association ، آنها یک اتصال امن ایجاد میکنند که به برنامه iOS آنها اجازه میدهد تا به طور ایمن از کلیدهای عبور در یک نمای وب استفاده کند .
// https://www.adidas.fi/.well-known/assetlinks.json
[
{
"relation": [
"delegate_permission/common.handle_all_urls",
"delegate_permission/common.get_login_creds"
],
"target": {
"namespace": "android_app",
"package_name": "com.adidas.app",
"sha256_cert_fingerprints": [
"B2:55:43:78:89:F6:F6:FD:BB:16:5C:43:EE:66:14:18:D4:E8:33:6D:3A:1F:68:86:C3:A8:7C:89:2B:51:45:96",
"..."
]
}
},
// ... abridged
]
قدم بعدی آدیداس چیست؟
با پایه و اساس قوی ارتقاء خودکار و اعتبارنامههای همگامسازیشده که به صورت زنده در adidas.fi و adidas.nl موجود هستند، آدیداس این سیستم یکپارچه را تا پایان آوریل 2026 در تمام بازارهای جهانی دیگر نیز مستقر خواهد کرد. علاوه بر این، آدیداس با آزمایش نسخه آزمایشی واسطهگری فوری، در حال بررسی تجربیات ورود به سیستم بدون مشکلتری است. برنامههای آینده شامل اجازه دادن به کاربران برای ایجاد حسابهای کاربری مستقیماً با کلیدهای عبور است. این امر نیاز فعلی به ثبت نام با یک روش جایگزین را در ابتدا حذف میکند. این تیم همچنین در حال بررسی "فعالسازی هوشمند" برای فراخوانی مستقیم کادر گفتگوی کلید عبور سیستم در مرحله دوم ورود به سیستم است. این امر نیاز به کلیک اضافی را در زمانی که اطمینان بالایی وجود دارد که کاربر کلید عبور را در دستگاه فعلی خود دارد، از بین میبرد.
چرا این برای شما مهم است؟
تغییر به سمت احراز هویت بدون رمز عبور زمانی موفقیتآمیز است که تجربه کاربری یکپارچه باقی بماند. با پیادهسازی Conditional Create، میتوانید بدون ایجاد اختلال در عادات کاربران، آنها را به راحتی از رمزهای عبور دور کنید. با استفاده از Related Origin Requests، میتوانید این کلیدهای عبور را در دامنههای خود به اشتراک بگذارید و به کاربران اجازه دهید به طور یکپارچه با یک کلید عبور واحد به کل اکوسیستم شما دسترسی داشته باشند. در نهایت، ترکیب این قابلیت با Signal API تضمین میکند که تجربه یکپارچه و بدون رمز عبور شما قابل اعتماد و بدون خطا باقی بماند.