استاندارد FedCM چیست؟

The Federated Credential Management (FedCM): یک استاندارد پیشنهادی جدید هویت که می‌تواند شیوه ورود ما به وب را تغییر دهد

نکات کلیدی

• FedCM یک API جدید پیشنهادی در سطح مرورگر است که ورود فدره (Federated Login) را بدون اصطکاک فراهم می‌کند.
• این API در تعدادی از مرورگرهای مبتنی بر Chromium پشتیبانی می‌شود و استفاده از آن برای توسعه‌دهندگان معمول وب ساده است.
• این پیشنهاد یک جریان ورود امن و مبتنی بر حفظ حریم خصوصی ارائه می‌دهد.
• این پیشنهاد در حال توسعه فعال است و پیش‌نویس کاری عمومی آن در مسیر تبدیل شدن به «توصیه‌نامه کاندید» قرار دارد. API مستندشده در پیش‌نویس کاری در مرورگرهای Chromium پیاده‌سازی شده است و حمایت سایر فروشندگان مرورگر از «مخالفتی نداریم» تا «کمک به بازبینی پیشنهاد» متغیر است.
• به‌عنوان یک توسعه‌دهنده، باید از این استاندارد پیشنهادی آگاه باشید، زیرا در صورت پیاده‌سازی کامل، روشی امن و آسان برای ورود کاربران شما فراهم می‌کند.

API مدیریت اعتبارنامه فدره (Federated Credential Management یا FedCM) یک مشخصه وب پیشنهادی است که می‌تواند تقریباً بر همه افرادی که از طریق مرورگر وارد اپلیکیشن‌ها می‌شوند تأثیر بگذارد. FedCM که در چارچوب W3C توسعه یافته، با معرفی یک روش بومی در مرورگر برای مدیریت ورودهای فدره، به‌دنبال ایجاد وبی با حفظ بهتر حریم خصوصی است. ورود فدره زمانی رخ می‌دهد که یک اپلیکیشن، فرایند ورود را به اپلیکیشن دیگری به نام ارائه‌دهنده هویت (Identity Provider) واگذار می‌کند.

انگیزه اولیه FedCM این بود که ورود فدره را بر پایه‌ای محکم‌تر و با پشتیبانی مرورگر بنا کند. به‌جای استفاده از primitiveهای عمومی وب مانند ریدایرکت‌ها، iframeها و کوکی‌های شخص ثالث ـ که بخشی به این دلیل کنار گذاشته می‌شوند که همین primitiveها توسط تبلیغ‌دهندگان برای ردیابی کاربران در سراسر وب استفاده می‌شوند ـ توسعه‌دهندگان می‌توانند از یک API بومی استفاده کنند. در حالی که گوگل کروم تصمیم مسدودسازی کوکی‌های شخص ثالث را به انتخاب کاربر واگذار کرده، مرورگرهای دیگر همچنان همه یا بخش زیادی از کوکی‌های شخص ثالث را به‌طور پیش‌فرض مسدود می‌کنند.

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

اگر شما با استفاده از یک ارائه‌دهنده اجتماعی شخص ثالث وارد یک اپلیکیشن وب می‌شوید، ممکن است به‌زودی در حال استفاده از FedCM باشید. بیشتر توسعه‌دهندگانی که از «Sign-In with Google» و کتابخانه Google Identity Services استفاده می‌کنند، در حال حاضر از FedCM استفاده می‌کنند؛ این کتابخانه در سال ۲۰۲۴ به‌روزرسانی شد تا از این API استفاده کند.

تاریخچه ورود به اپلیکیشن‌های وب

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

ورود مبتنی بر کوکی با یک سرور احراز هویت مرکزی در سال ۱۹۹۴ توسط تیم Netscape Navigator ابداع شد؛ این کار برخی از مشکلات احراز هویت تک‌سروری را حل کرد. با این حال، این راهکارها محدود هستند زیرا کوکی‌ها بین دامنه‌ها به اشتراک گذاشته نمی‌شوند. این جداسازی بخش مهمی از مدل امنیتی وب است. هرچند iframeهای توکار می‌توانند این محدودیت را دور بزنند، اما مشکلات امنیتی دارند، به‌ویژه در برابر clickjacking.

با انتشار SAML 1.0 در سال ۲۰۰۲، اولین جریان استاندارد ورود مبتنی بر ریدایرکت پیاده‌سازی شد. SAML از ریدایرکت‌ها و اسناد XML امضاشده استفاده می‌کرد تا اطمینان دهد کاربران احراز هویت شده‌اند و به اپلیکیشن‌ها اجازه می‌داد فرایند احراز هویت را به‌صورت امن واگذار کنند. گروه‌های دیگر که روی همین مسئله کار می‌کردند، SAML را بازبینی کردند و نسخه ۲.۰ آن در سال ۲۰۰۵ منتشر شد.

OAuth و OIDC در بازه ۲۰۱۲ تا ۲۰۱۴ منتشر شدند و قالب و سازوکارهای SAML را به‌روز کردند، اما همچنان از همان رویکرد ریدایرکت و اسناد امضاشده استفاده کردند. در حال حاضر، بیشتر اپلیکیشن‌ها یا احراز هویت را مستقیماً در اپلیکیشن خود پیاده می‌کنند و مشکلات امنیتی و پیاده‌سازی دهه ۹۰ را می‌پذیرند، یا احراز هویت را به یک سرور مرکزی واگذار می‌کنند. این سرورهای مرکزی ممکن است روی همان دامنه اپلیکیشن اصلی میزبانی نشوند. بنابراین، قابلیت‌هایی مانند refresh بی‌صدا مبتنی بر iframe یا درخواست‌های JavaScript بدون کوکی‌های شخص ثالث کار نمی‌کنند. اما کوکی‌های شخص ثالث همچنین به تبلیغ‌دهندگان و پلتفرم‌ها اجازه می‌دهند کاربران را در سراسر وب ردیابی کنند و رفتار آن‌ها را در سایت‌ها و اپلیکیشن‌های مختلف جمع‌آوری کنند.

مکانیزم مبتنی بر ریدایرکت که در OIDC و SAML استفاده می‌شود، مشکل پرچم NASCAR را نیز ایجاد می‌کند. وب‌سایت‌ها باید فهرستی از ارائه‌دهندگان هویت پشتیبانی‌شده را نمایش دهند. به دلیل محدودیت فضا در صفحه، این موضوع به نفع چند ارائه‌دهنده بزرگ تمام می‌شود و اپلیکیشن‌ها را از دادن حق انتخاب ارائه‌دهنده هویت به کاربران بازمی‌دارد. اهداف حفاظت از حریم خصوصی کاربر و تجربه کاربری بهتر که توسط مرورگرها میانجی‌گری می‌شود، به پروژه FedCM منجر شد. در ادامه نگاهی به خط زمانی این پروژه می‌اندازیم.

خط زمانی مدیریت اعتبارنامه فدره

مهم است تلاش FedCM را در بستر تغییرات کوکی‌های شخص ثالث که توسط گوگل و تیم کروم مطرح شد ببینیم. کار روی این پروژه کمی بعد از اعلام گوگل درباره اهمیت حریم خصوصی در وب آغاز شد.

اولین commit در مخزنی که بعدها به مخزن مدیریت هویت فدره تبدیل شد، در مارس ۲۰۲۰ انجام شد (نام اولیه آن WebID بود). گروه جامعه W3C در سال ۲۰۲۱ و گروه کاری در سال ۲۰۲۴ شکل گرفتند. (گروه‌های جامعه ایده‌ها را پرورش می‌دهند و گروه‌های کاری توصیه‌نامه‌ها را منتشر می‌کنند.)

در سال ۲۰۲۲، این پروژه توسط کارکنان گوگل به فایرفاکس معرفی شد. این تغییر مثبت ارزیابی شد و در اواخر ۲۰۲۲ نمونه اولیه به فایرفاکس اضافه شد. در حالی که مسیر حذف کوکی‌های شخص ثالث فراز و نشیب داشت، تلاش FedCM ادامه یافت. فقط مشخصه در حال تکامل نبود، بلکه کد مرورگرها نیز منتشر شد. بخشی از قابلیت‌های FedCM در Chrome و Edge نسخه ۱۰۸ که در سال ۲۰۲۲ منتشر شدند، عرضه شد. در سال ۲۰۲۵، یک باگ ردیابی برای انتشار کامل در فایرفاکس اضافه شد.

پشتیبانی اولیه FedCM در Selenium در سال ۲۰۲۳ اضافه شد و یک درخواست ویژگی باز برای Playwright است. مشخصه یک بخش سطح بالا درباره خودکارسازی مرورگر دارد، که نشان می‌دهد این موضوع مهم تلقی می‌شود. گروه کاری در اوت ۲۰۲۴ پیش‌نویس کاری را منتشر کرد، اما هنوز کار زیادی تا انتشار نسخه کاندید باقی مانده است. پیش‌نویس ویرایشگر نیز در دسترس است و به‌طور منظم به‌روزرسانی می‌شود.

در ادامه نگاهی به قابلیت‌هایی که FedCM ارائه می‌دهد می‌اندازیم.

قابلیت‌های مدیریت اعتبارنامه فدره

چند تعریف مفید قبل از بررسی قابلیت‌ها:

• RP یا relying party: وب‌سایتی که اپلیکیشن یا داده‌ای دارد که کاربر تلاش می‌کند از طریق مرورگر به آن دسترسی پیدا کند. این اپلیکیشن رویداد احراز هویت را آغاز می‌کند.
• IDP یا identity provider: نگه‌دارنده اطلاعات هویتی که با مرورگر تعامل می‌کند. پیش‌تر از آن به‌عنوان سرور مرکزی احراز هویت نام بردیم.
• User-agent: اصطلاح فنی برای مرورگر.

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

نمودار جریان کاربر با جریان مبتنی بر ریدایرکت

در این حالت، اولین باری که کاربر وارد می‌شود، از جریان مبتنی بر ریدایرکت استفاده می‌کند.

بار دوم که کاربر وارد می‌شود، به IDP هدایت می‌شود، اما چون کوکی‌هایش معتبر هستند، فرم ورود را نمی‌بیند.

جریان‌های ورود با FedCM

تجربه اولین ورود کاربر با FedCM به جزئیات درخواست RP بستگی دارد، اما معمولاً IDP با استفاده از یک iframe اطلاعات ورود را درخواست می‌کند.

این نمودار جریان حالت «passive» را نشان می‌دهد که به حداقل تعامل کاربر نیاز دارد.

وقتی در گام ۱۲ یک توکن توسط user-agent دریافت می‌شود، بخش FedCM کامل شده است. ممکن است RP هنوز کارهایی برای انجام دادن داشته باشد.

بار دوم که کاربر با FedCM وارد می‌شود، جایی است که جادو اتفاق می‌افتد. وقتی کاربر قبلاً از FedCM استفاده کرده و بیش از یک حساب ندارد، دیگر از او خواسته نمی‌شود وارد شود و بدون ترک RP به‌صورت خودکار دوباره احراز هویت می‌شود.

نویسندگان مشخصه FedCM سناریوهای ورود دیگری را نیز در نظر گرفته‌اند، از جمله:

• وجود چند حساب روی این دستگاه که قبلاً به ارائه‌دهنده هویت وارد شده‌اند
• حساب کاربری نامعتبر
• حالتی که کاربر از RP خارج شده اما از IDP خارج نشده است
• حالتی که کاربر اخیراً از IDP خارج شده است

در ادامه نمونه‌ای از چیزی که کاربر می‌بیند آورده شده است.

پشتیبانی مرورگرها

بر اساس فهرست مرورگرها بر حسب سهم بازار که توسط Cloudflare ارائه شده، مرورگرهایی با بیش از یک درصد سهم بازار و میزان پشتیبانی آن‌ها از FedCM به شرح زیر است:

• Chrome: پشتیبانی کامل از نسخه ۱۳۶. تیم Chrome در گروه کاری FedCM فعال است.
• Safari: حامی این تلاش است اما تا زمان نگارش، پیاده‌سازی‌ای منتشر نشده است. اشاره‌ای نیز در صفحه استانداردهای WebKit وجود ندارد.
• Edge: پشتیبانی کامل از نسخه ۱۳۶.
• Firefox: در مسیر پشتیبانی است اما در زمان انتشار پشتیبانی نمی‌شود. یک باگ ردیابی برای عرضه این ویژگی وجود دارد. تیم Firefox در گروه کاری فعال است، اما از اوت ۲۰۲۵ اجرای آن را موقتاً متوقف کرده است.
• Samsung Internet: تقریباً پشتیبانی کامل از نسخه ۲۶.
• Opera: تقریباً پشتیبانی کامل از نسخه ۱۰۸، یک قابلیت در حالت پیش‌نمایش است.
• Brave: حمایت از این تلاش در سال ۲۰۲۳ مطرح شد، یک issue باز در GitHub به آن اشاره دارد، اما حرکت اخیر قابل توجهی دیده نمی‌شود.

پشتیبانی ارائه‌دهندگان هویت (IDP)

پشتیبانی IDPها در حال رشد است، اما هنوز فراگیر نیست. بر اساس یک ارائه در پاییز ۲۰۲۴، ارائه‌دهندگان هویت زیر از FedCM پشتیبانی می‌کنند:

• Google (به همراه فایل .well-known مربوطه)
• NetID (GMX/Web.de)
• Shopify
• Seznam (پرتال وب و موتور جستجوی چک)
• Mobage (پرتال و شبکه اجتماعی بازی‌ها)
• Times Internet (شرکت چندملیتی فناوری هند)
• AMedia (شرکت روزنامه)
• Ory (ارائه‌دهنده زیرساخت که از FedCM پشتیبانی می‌کند)

همچنین علاقه گسترده‌تری در گروه کاری FedCM وجود دارد و IDPهای زیادی در فهرست مشارکت‌کنندگان دیده می‌شوند.

پشتیبانی RP

اپلیکیشن‌های وبی که از FedCM پشتیبانی می‌کنند سخت‌تر قابل شناسایی‌اند، اما شامل موارد زیر می‌شوند:

• Pinterest
• Kayak
• Booking.com
• Realtor.com

اگر کنجکاوید بدانید یک RP از FedCM پشتیبانی می‌کند یا نه، صفحه ورود را در ابزار inspect مرورگر باز کنید و به دنبال رشته «IdentityCredential» در JavaScript بگردید.

موارد استفاده پشتیبانی‌شده

FedCM روی موارد استفاده زیر تمرکز دارد:

• ورود کاربر، که به‌شکلی امن و سازگار با حریم خصوصی تأیید می‌کند کاربر RP در IDP حساب دارد.
• قطع اتصال حساب کاربر از فهرست مدیریت‌شده توسط مرورگر.

موارد استفاده مرتبط دیگری هم وجود دارد که تمرکز اصلی FedCM نیستند اما مجاور آن محسوب می‌شوند:

• جریان ثبت‌نام/ساخت حساب توسط یک افزونه انجام می‌شود که به کاربر اجازه می‌دهد با FedCM ثبت‌نام کند. ایجاد حساب کاملاً بین IDP و مرورگر انجام می‌شود.
  مورد استفاده خروج (logout) نیز پوشش داده شده است. اگر IDP در پاسخ به درخواست حساب‌های واردشده، هیچ حسابی ارائه ندهد، کاربر خارج می‌شود. IDP همچنین می‌تواند از طریق یک API کاربر را به‌عنوان خارج‌شده علامت‌گذاری کند.
• بازیابی حساب و مدیریت اعتبارنامه‌ها توسط FedCM یا افزونه‌هایش مدیریت نمی‌شود.

جزئیات پیاده‌سازی

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

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

جزئیات پیاده‌سازی در وب‌سایت

ورود

وب‌سایت یا RP فرایند احراز هویت را با استفاده از Identity Provider API آغاز می‌کند. ابتدا پشتیبانی API را بررسی کنید و فرایند را شروع کنید (اضافه کردن handler به دکمه یا آغاز ورود بعد از بارگذاری صفحه):

باید پشتیبانی FedCM را بررسی کنید، چون پشتیبانی مرورگرها کامل نیست و کاربران می‌توانند آن را غیرفعال کنند. در صورت نیاز به روش‌های دیگر بازگردید.

در ادامه به تابع signIn نگاه می‌کنیم:

این درخواست شناسه‌های کلاینت و URL پیکربندی را ارسال می‌کند که به IDP کمک می‌کند کاربر را شناسایی کند. پارامتر mode یا «active» است یا «passive». درخواست active به تعامل کاربر نیاز دارد، در حالی که passive بسته به مقدار mediation ممکن است بدون تعامل انجام شود. mediation چهار مقدار تعریف‌شده دارد که مشخص می‌کند چه مقدار از فرایند ورود بدون تعامل کاربر انجام شود. params شامل پارامترهای اضافی است؛ مثل loginHint برای مشخص کردن حساب‌ها یا nonce برای جلوگیری از حملات replay.

مرورگر سپس همه IDPهایی را که درخواست شده و پاسخ درست داده‌اند به کاربر نشان می‌دهد. RP می‌تواند با نگاه کردن به credential.configURL بفهمد کاربر با کدام IDP وارد شده است. دریافت یک توکن معتبر نتیجه احراز هویت موفق است. بعد از دریافت توکن، RP باید از آن استفاده کند؛ این منطق به اپلیکیشن بستگی دارد. با دریافت توکن، جریان FedCM کامل می‌شود.

قطع اتصال (Disconnecting)

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

قطع اتصال می‌تواند به دلایل مختلفی شکست بخورد، مثلاً اگر کاربر FedCM را در مرورگر غیرفعال کرده باشد. حالا به پیاده‌سازی IDP می‌پردازیم.

جزئیات پیاده‌سازی IDP

IDP باید بخش HTTP API مشخصه را پیاده‌سازی کند. پیش‌نویس اوت ۲۰۲۴ و آخرین پیش‌نویس ویرایشگر در دسترس است. از آنجا که این استاندارد پیشنهادی با سرعت در حال تغییر است، بهترین راه تست با مرورگرهای هدف و مراجعه هم‌زمان به پیش‌نویس و مستندات Google FedCM است.

اقدامات امنیتی

همان‌طور که گفته شد، دلیل اصلی FedCM این است که primitiveهای کوکی و ریدایرکت که برای احراز هویت مدرن حیاتی‌اند، می‌توانند برای ردیابی کاربران هم استفاده شوند. FedCM با محدود کردن اطلاعاتی که هر endpoint دریافت می‌کند، از این موضوع جلوگیری می‌کند. برای هر endpoint فقط اطلاعات ضروری ارسال می‌شود.

برای جلوگیری از سوءاستفاده از درخواست‌های مشروع مرورگر، هدر Sec-Fetch-Dest باید در همه درخواست‌های FedCM (غیر از popup) بررسی شود و مقدار آن همیشه webidentity باشد. کوکی‌ها با SameSite=None ارسال می‌شوند، که شاید نگران‌کننده به نظر برسد، اما این درخواست‌ها به‌شدت توسط مرورگر کنترل می‌شوند و این تنظیم امکان احراز هویت بین دامنه‌ای را فراهم می‌کند. نویسندگان مشخصه یک بخش کامل را به ملاحظات امنیتی اختصاص داده‌اند.

موارد در حال تغییر

در حالی که FedCM در Chrome و Edge عرضه شده، هنوز کار زیادی برای تثبیت مشخصه از سمت مرورگرها و حتی بیشتر از سمت IDPها باقی مانده است. دو تلاش مهم که هنوز در حال تغییر هستند عبارت‌اند از:

ثبت‌نام IDP، برای آسان‌تر کردن افزایش تعداد IDPهای پشتیبانی‌شده توسط FedCM.
واگذاری (Delegation)، برای بهبود جنبه‌های حریم خصوصی ورود فدره، به‌ویژه اینکه IDP نتواند بداند کدام RP احراز هویت را به آن واگذار کرده است.

انتظار می‌رود FedCM به‌تدریج شتاب بگیرد، اما احتمالاً ماه‌ها یا حتی سال‌ها زمان لازم است تا به یک استاندارد رسمی W3C تبدیل شود.

تأثیر بر ذی‌نفعان

توسعه‌دهندگان

استفاده از FedCM از نظر پیاده‌سازی ساده است: فراخوانی APIهای بومی مرورگر. FedCM به کاربران اجازه می‌دهد بدون ترک اپلیکیشن وب و با روشی امن و سازگار با حریم خصوصی در IDP احراز هویت شوند. با این حال، چند نگرانی وجود دارد:

پوشش: FedCM هنوز در بسیاری از مرورگرها مثل Safari و Firefox در دسترس نیست. نبود پشتیبانی Safari یعنی FedCM برای مدت طولانی راه‌حل کامل دسکتاپ نخواهد بود، چه برسد به موبایل. باید روش جایگزین ورود را حفظ کنید.

روش‌های جایگزین: FedCM تنها روش ورود نخواهد بود. مانند magic link یا passkey، سایت‌ها باید گزینه‌های دیگر ورود را نیز ارائه دهند.

برندسازی: احراز هویت دروازه ورودی اپلیکیشن شماست. با FedCM اصطکاک کمتر می‌شود، اما کنترل UX کاهش می‌یابد؛ هم در ظاهر و هم در ارائه روش‌های دیگر مثل SAML یا OIDC.

ارائه‌دهندگان هویت

پیاده‌سازی FedCM برای IDPها ساده نیست، اما مزایای بیشتری دارد. رعایت قوانین امنیتی مثل بررسی کوکی‌ها و هدرها ضروری است. پشتیبانی از FedCM به IDPها کمک می‌کند:

ورود بدون ریدایرکت
افزایش گزینه‌های ورود برای کاربران
آمادگی برای حذف احتمالی کوکی‌های شخص ثالث
کمک به RPها برای رعایت مقررات حریم خصوصی مانند GDPR و CCPA

کاربران نهایی

برای استفاده از FedCM، کاربران باید رفتار ورود خود را کمی تغییر دهند، اما به‌دلیل عرضه تدریجی، می‌توانند این تغییر را مدیریت کنند. روش‌های جایگزین برای مدت طولانی وجود خواهد داشت. تعامل ابزارهای غیربرنامه‌مرورگر مثل password managerها با FedCM هنوز کاملاً روشن نیست، اما پشتیبانی از خودکارسازی user-agent نشان می‌دهد این ابزارها احتمالاً سازگار خواهند شد.

جمع‌بندی

FedCM مهم است. این استاندارد پیشنهادی در حال حاضر روی بخش بزرگی از ترافیک دسکتاپ پشتیبانی می‌شود و با مشارکت ۳۰ سازمان در گروه کاری به‌طور فعال توسعه می‌یابد. با این حال، بیشتر افراد از صبر کردن تا انتشار پیش‌نویس بعدی و تثبیت API سود خواهند برد. اگر ریسک‌پذیر هستید و Google یک ارائه‌دهنده هویت حیاتی برای شماست، می‌توانید همین حالا از FedCM استفاده کنید. در نهایت، در شکل‌دهی این استاندارد پیشنهادی مشارکت کنید؛ جلسات و فرصت‌های متعددی برای همکاری وجود دارد.

برچسب‌ها (Tags):

کلمه کلیدی سئو:
استاندارد FedCM برای ورود امن به وب