ارائه ورود به سیستم یکپارچه و اعتبارنامه‌های دیجیتال در Android

سلام به همه.

از اینکه امروز به ما پیوستید سپاس‌گزاریم.

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

من تام کالوین هستم.

من مدیر ارشد فناوری Apptaura و GDE در Android هستم و چیپینگ یه، مهندس ارشد روابط توسعه‌دهندگان Android در Google، نیز به من پیوسته است.

گذرواژه قدیمی دیگر ازبین رفته است.

یا حداقل باید این‌طور باشد.

امروز می‌خواهم درباره دنیای بدون گذرواژه با شما صحبت کنم.

گذرواژه‌ها آسیب‌پذیری شناخته‌شده‌ای در زیرساخت امنیتی ما هستند.

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

به‌عنوان یک صنعت، تلاش کرده‌ایم با اعمال پیچیدگی به این موضوع بپردازیم: نویسه‌های خاص، اعداد، چرخش‌های اجباری.

شواهد نشان می‌دهد که این روش شکست خورده است، تاحدی به این دلیل که هرچه آن را دشوارتر کنید، به‌طور متناقضی، رفتار ناامن را بیشتر تشویق می‌کنید.

زیرا گذرواژه پیچیده‌ای که مرتباً تغییر می‌کند احتمالاً روی یک یادداشت چسبان نوشته می‌شود.

و حتی اصالت‌سنجی دوعاملی مبتنی بر پیامک دربرابر رهگیری‌هایی مانند تعویض سیم‌کارت آسیب‌پذیر است.

اما امروزه این مشکل تا حد زیادی حل شده است.

گذرکلیدها براساس استانداردهای FIDO ساخته شده‌اند و از رمزنگاری کلید عمومی-خصوصی استفاده می‌کنند.

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

بیانیه امروز ما ساده است.

وقت آن رسیده که به دنیای بدون گذرواژه وارد شویم.

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

برای ایجاد این جهش در Android، ما Jetpack Credential Manager را داریم.

این ویژگی از Android 4.4 به بعد پشتیبانی می‌شود و با پشتیبانی از گذرکلیدها از Android 9، یک میانای برنامه‌سازی کاربردی واحد و یکپارچه ارائه می‌دهد که هم از گذرکلیدها و هم از روش‌های سنتی اصالت‌سنجی مانند ورود به سیستم فدرال (مثل ورود به سیستم با Google) پشتیبانی می‌کند و درصورت نیاز، امکان بازگشت به گذرواژه‌ها را نیز فراهم می‌کند.

شما Credential Manager API را فراخوانی می‌کنید و این API واسط کاربر را برای انتخاب روش اصالت‌سنجی موردنظر کاربر مدیریت می‌کند.

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

این برنامه از ورود به سیستم، ثبت‌نام، و پشتیبان‌گیری از اعتبارنامه‌ها پشتیبانی می‌کند.

و می‌توانید از آن برای به‌روزرسانی و حذف اعتبارنامه‌ها استفاده کنید.

همچنین به کاربران کمک می‌کند گذرواژه‌ها و گذرکلیدهایشان را فقط با چند کلیک بین ارائه‌دهندگان اطلاعات کاربری جابه‌جا کنند و نیازی به بارگیری فایل نیست.

این ابزار به‌گونه‌ای طراحی شده است که به کاربران کنترل کامل بر داده‌هایشان و آزادی تغییر ارائه‌دهنده را در هر زمان که نیاز داشته باشند می‌دهد.

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

و مهم‌تر از همه برای ما، این برنامه جریان اختصاصی برای گذرکلیدها دارد.

در اینجا نحوه نمایش آن برای کاربر درطول ثبت‌نام آورده شده است.

برنامه من به Credential Manager می‌گوید که اصالت‌سنجی گذرکلید دردسترس است و جزئیات جمع‌آوری‌شده از پس‌زمینه را به آن ارائه می‌دهد.

روی «ثبت» ضربه می‌زنید و «مدیر اطلاعات کاربری» برگه‌ای در پایین صفحه با پیام‌واره قفل صفحه به شما می‌دهد.

این مورد معمولاً با داده‌های زیست‌سنجشی مانند اثر انگشت یا اسکن چهره باز می‌شود.

و سپس «مدیر اطلاعات کاربری» کارهای پیچیده رمزنگاری را مثل ایجاد واقعی گذرکلید انجام می‌دهد.

و گذرکلید را در مدیر اطلاعات کاربری من ذخیره می‌کند که در این مورد «مدیر گذرواژه Google» است، اما می‌تواند چیز دیگری باشد.

کد به این شکل است.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

val createCredentialResponse =  credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

ابتدا، این شیء createPublicKeyCredentialRequest را بااستفاده از جزئیاتی که پس‌زمینه ارائه می‌دهد ایجاد می‌کنیم، یعنی این registerRequestJson.

سپس، متد جادویی credentialManager.createCredential را فراخوانی می‌کنیم.

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

ضمناً توجه داشته باشید که من مجبور نبوده‌ام هیچ کد واسط کاربری‌ای در اینجا بنویسم.

Credential Manager این کار را کاملاً برای ما انجام می‌دهد.

اکنون، این فرایند ورود به سیستم است.

برای کاربر، این فرایند بسیار شبیه به فرایند ثبت‌نام است.

یک پیام‌واره باز کردن قفل وجود دارد و کارتان تمام است.

برای توسعه‌دهندگان، فقط کمی متفاوت است.

val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
   requestJson = authenticationRequestJson
)
val signInRequest =
   GetCredentialRequest(listOf(getPublicKeyCredentialOption))

val result =  credentialManager.getCredential  (
   context = localActivity,
   request = signInRequest
)

ابتدا جزئیات ورود به سیستم را از پس‌زمینه دریافت می‌کنیم تا نمونه GetPublicKeyCredential را بسازیم.

به Credential Manager می‌گوییم از چه نوع اعتبارنامه‌هایی پشتیبانی می‌کنیم.

اینجا فقط گذرکلیدها هستند.

اما اگر بخواهیم می‌توانیم انواع دیگر اطلاعات اعتباری را هم اضافه کنیم.

سپس credentialManager.getCredential را فراخوانی می‌کنیم و آن فهرست اعتبارنامه‌هایی را که به‌تازگی درخواست کرده‌ایم به آن ارسال می‌کنیم.

باز هم بدون کد واسط کاربر.

نیازی به نوشتن کد واسط کاربر نیست.

Credential Manager کاملاً این کار را برای ما انجام می‌دهد.

این ویژگی کاربر را به‌سمت گزینه‌ای که بیشتر از همه استفاده می‌شود سوق می‌دهد و گزینه‌های دیگر را به‌عنوان پشتیبان دردسترس نگه می‌دارد.

این کار به‌طور خودکار یکی از آزاردهنده‌ترین مشکلات اصالت‌سنجی امروزی را حل می‌کند.

متوجه شدید؟

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

ببینید، پاسخ به‌طور مرتب در برگ زیرین ارائه شده است.

ضمناً این موضوع فقط برای کاربر آزاردهنده نیست.

این یک نقطه اصطکاک واقعی است.

این کار باعث بازیابی‌های غیرضروری حساب می‌شود و تأثیر تجاری مانند سبدهای خرید رهاشده دارد.

این کد برنامه نمایشی من است که می‌توانید از آن برای امتحان کردن Credential Manager استفاده کنید.

و می‌توانید این جریان‌ها را در دستگاه خودتان ببینید.

و نمونه‌های کد رسمی Goo-- در سمت چپ قرار دارد.

این کار ایجاد گذرکلید را مدیریت می‌کند.

ارتقا دادن کاربران گذرواژه موجود به گذرکلید چطور؟

خب، ابزار قدرتمند برای این کار «ساختن شرطی» است.

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

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

این نوار گردش کار کاربر را مختل نمی‌کند.

گذروا-- گذرکلید به‌طور بی‌صدا تولید و ذخیره می‌شود.

«مدیر گذرواژه Google» اعلانی را برای تأیید این اتفاق نمایش می‌دهد.

دیگر مدیرهای گذرواژه ممکن است متفاوت عمل کنند.

کد «ایجاد شرطی» بسیار شبیه کد ثبت‌نام است.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson,
   preferImmediatelyAvailableCredentials = false,
   isConditional = true
)

val createCredentialResponse = credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

پرچم جادویی isConditional درست است، که تضمین می‌کند کاربر آن میانای کاربر را نمی‌بیند.

و چون به‌صورت فرصت‌طلبانه کار می‌کند، آن را در try-catch قرار می‌دهیم.

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

سپس گذرکلید در Credential Manager کاربر ذخیره می‌شود و دفعه بعد در آنجا دردسترس او قرار می‌گیرد.

Credential Manager همچنین به ارائه‌دهندگان اطلاعات اعتباری اجازه می‌دهد اطلاعات اعتباری خود را به‌طور ایمن وارد و صادر کنند.

فقط چند کلیک.

نیازی به بارگیری نیست.

این کار انعطاف‌پذیری بیشتری را فراهم می‌کند و درعین‌حال اطلاعات را ایمن نگه می‌دارد.

جریان به این شکل است.

کاربر در ارائه‌دهنده اطلاعات اعتباری جدید خود درخواست می‌کند اطلاعات اعتباری را وارد کند.

سپس «مدیر اطلاعات کاربری» واسط کاربر وارد کردن را مدیریت می‌کند و به کاربر اجازه می‌دهد منبع داده‌های اطلاعات کاربری را انتخاب کند.

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

و درنهایت، ارائه‌دهنده اطلاعات اعتباری جدید کاربر داده‌ها را ازطریق کانال امن دریافت می‌کند.

بنابراین می‌تواند آن را بدون هیچ‌گونه تعامل کاربر وارد کند.

اما اگر کاربر گذرکلیدی را از برنامه یا وب‌سایت خود لغو کند چه اتفاقی می‌افتد؟

سپس ارائه‌دهنده اطلاعات کاربری لزوماً از این اتفاق مطلع نمی‌شود.

دفعه بعد که کاربر بخواهد به سیستم وارد شود، «مدیر اطلاعات کاربری» آن گذرکلید غیرفعال را ارائه خواهد داد و تلاش کاربر رد خواهد شد.

به‌همین ترتیب، وقتی کاربری نام کاربری یا نام نمایشی خود را به‌روز می‌کند، همگام‌سازی لازم است.

اکنون با Signal API، برنامه‌تان می‌تواند این وضعیت‌های خاص را برای ارائه‌دهنده اطلاعات کاربری پرچم‌گذاری کند.

برای مثال، ورود به سیستم با گذرواژه لغوشده را درنظر بگیرید.

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

سپس ارائه‌دهنده اطلاعات کاربری می‌تواند خودش را به‌روز کند تا آن گذرکلید خاص ارائه نشود.

این‌ها برخی‌از ویژگی‌های Credential Manager هستند و این ابزار برای ترغیب کاربران به ثبت‌نام بااستفاده از گذرکلید و اولویت دادن به گذرکلید نسبت‌به روش‌های دیگر هنگام ورود به سیستم بسیار مفید است.

اما به‌خاطر داشته باشید که هدف نهایی ما در اینجا این است که کاملاً بدون گذرواژه شویم.

‫Credential Manager چگونه به این هدف کمک می‌کند؟

در اینجا فرایند پنج مرحله‌ای پیشنهادی ما آمده است.

در دو مرحله اول، کاربران گذرواژه را به گذرکلید ارتقا می‌دهید.

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

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

می‌توانیم به‌تدریج آن‌ها را بیشتر و برجسته‌تر نشان دهیم.

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

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

اما آن کاربران قدیمی، این همان چیزی است که در این سه مرحله آخر با آن سروکار داریم.

کاربران گذرکلید را تشویق می‌کنیم گذرواژه‌هایشان را بردارند.

بنابراین در مرحله ۳، به آن‌ها اجازه می‌دهیم این کار را به‌صورت دستی انجام دهند، با گزینه بسیار واضح «حذف گذرواژه» در تنظیمات حسابشان.

در مرحله ۴، بااستفاده از اعلان‌های درون‌برنامه و متن‌های آموزشی، کاربران را به حذف گذرواژه تشویق می‌کنیم.

و درنهایت، حذف گذرواژه را از حالت موافقت کردن به حالت انصراف دادن تغییر می‌دهید.

درنهایت، حتی آن آخرین انصراف هم ممکن است ناپدید شود.

Analytics به ما اطمینان می‌دهد که جریان‌های گذرواژه را به‌طور کامل از برنامه برداریم.

بنابراین، حرکت به‌سمت دنیای بدون گذرواژه دیگر یک مفهوم امنیتی نظری برای آینده نیست.

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

میاناهای برنامه‌سازی کاربردی قوی هستند و تجربه کاربری عالی است.

شما را تشویق می‌کنم که از همین امروز ادغام جریان‌های گذرکلید با Credential Manager را شروع کنید.

ارتقا دادن کاربران را شروع کنید و بیایید بالاخره گذرواژه‌ها را به گذشته بسپاریم.

متشکریم.

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

باحال.

بسیار خوب، متشکرم، تام.

همان‌طور که تام اشاره کرد، اصالت‌سنجی یکپارچه در دستگاه‌های کاربر بسیار مهم است.

اما وقتی کاربر تلفن جدیدی می‌گیرد چه اتفاقی می‌افتد؟

بزرگ‌ترین ریزش در مسیر کاربر امروزه اغلب زمانی اتفاق می‌افتد که کاربر دستگاهش را عوض می‌کند.

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

از آوریل ۲۰۲۷، Google Play از برنامه‌ها می‌خواهد که الزامات ورود به سیستم بدون ضربه را برآورده کنند تا بتوانند قابلیت‌های انتشار کامل و رؤیت‌پذیری بهینه را در «فروشگاه Play» حفظ کنند.

ورود به سیستم بدون ضربه چیست؟

درواقع، این یعنی کاربران هنگام انتقال به دستگاه جدید نیازی به اصالت‌سنجی مجدد دستی در برنامه شما ندارند.

چگونه این را پیاده‌سازی می‌کنیم؟

روش اصلی‌ای که برای انجام این کار توصیه می‌کنیم، ازطریق «میانای برنامه‌سازی کاربردی بازگرداندن اعتبارنامه‌ها» در Android ازطریق Credential Manager است.

این میانای برنامه‌سازی کاربردی به شما امکان می‌دهد چیزی را که به‌عنوان کلید بازیابی شناخته می‌شود تولید کنید. این کلید براساس تنظیمات پشتیبان‌گیری کاربر در دستگاه کاربر یا در فضای ابری ذخیره می‌شود.

توصیه می‌کنیم این کلید را پس‌از ورود کاربر به سیستم در پس‌زمینه تولید کنید.

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

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

سپس این کلید به‌صورت محلی یا، درصورت فعال بودن، ازراه‌دور در فضای ابری ذخیره می‌شود.

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

کاربران می‌توانند انتخاب کنند که داده‌ها را از فضای ابری یا انتقال دستگاه‌به‌دستگاه بازیابی کنند.

سپس، وقتی برنامه‌تان باز می‌شود، می‌توانید Credential Manager API را فراخوانی کنید تا از این کلید بازیابی برای وارد کردن کاربر به سیستم در دستگاه جدید در اولین راه‌اندازی استفاده کنید.

این کار به کاربر اجازه می‌دهد به‌سرعت و به‌طور ایمن فوراً به سیستم برنامه شما وارد شود.

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

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

برخی‌از شرکای ما قبلاً این ویژگی را در برنامه خود پیاده‌سازی کرده‌اند.

Uber بزرگ‌ترین شرکت هم‌پیمایی در جهان است که برای میلیون‌ها نفر حمل‌ونقل فراهم می‌کند و درعین‌حال از تحویل غذا، حمل‌ونقل مراقبت‌های بهداشتی، و لجستیک باربری پشتیبانی می‌کند.

سادگی دسترسی بسیار مهم است.

و وقتی کاربران به دستگاه جدیدی می‌روند، انتظار دارند انتقال بدون مشکلی داشته باشند و لازم نباشد دوباره به سیستم برنامه Uber وارد شوند یا هربار اصالت‌سنجی یک‌باره مبتنی بر پیامک را انجام دهند.

این گردش مکرر دستگاه چالشی برای حفظ کاربر ایجاد می‌کند.

به‌دنبال ارزیابی تقاضای کاربر و نمونه‌سازی کد، Uber پشتیبانی از «بازگرداندن اعتبارنامه‌ها» را به برنامه Uber Rider اضافه کرد و نتایج بسیار مثبتی به‌دست آورد.

آن‌ها تخمین می‌زنند که این کار باعث صرفه‌جویی در ۴ میلیون ورود به سیستم میانگین روزانه در روز می‌شود و انتظار دارند که با افزایش پذیرش، این تعداد افزایش یابد.

لطفاً این رمزینه پاسخ‌سریع و پیوند را ببینید تا درباره این خط‌مشی آتی و نحوه برآورده کردن الزامات بازیابی بدون ضربه توسط برنامه‌تان بیشتر بدانید.

تکرار می‌کنم، این تغییر در آوریل ۲۰۲۷ اعمال خواهد شد، پس لطفاً حتماً آن را در تقویمتان علامت‌گذاری کنید.

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

از این مهارت می‌توان برای کمک به توسعه یا آزمایش سریع ویژگی با عامل انتخابی‌تان استفاده کرد.

اکنون بیایید به مرز بعدی هویت دیجیتال نگاه کنیم: Digital Credentials API ازطریق Credential Manager.

بیایید ببینیم «اعتبارنامه‌های دیجیتال» چیست و چگونه کار می‌کند.

«اطلاعات اعتباری دیجیتال» اسناد دیجیتالی قابل‌تأیید ازطریق رمزنگاری هستند که کاربران می‌توانند از آن‌ها برای ارائه اطلاعات درباره خودشان استفاده کنند.

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

موارد استفاده گسترده و متنوع است، از درستی‌سنجی هویت گرفته تا دسترسی به سرویس‌ها و خرید آنلاین کالا.

«مدارک دیجیتال» روشی امن و راحت برای هم‌رسانی اطلاعات بدون نیاز به کارت‌های فیزیکی ارائه می‌دهد.

«اعتبارنامه‌های دیجیتال» شامل سه طرف می‌شود: صادرکننده، دارنده، و درستی‌سنج.

عمر اعتبارنامه دیجیتال معمولاً از چپ به راست جریان دارد.

بیایید هریک از این نهادها و نقشی را که ایفا می‌کنند بررسی کنیم.

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

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

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

فقط باید اعتبارنامه‌ای بسازید و آن را امضا کنید.

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

این طرف بعدی است که دارنده نامیده می‌شود و معمولاً به‌عنوان کیف پول دیجیتال نیز توصیف می‌شود.

دارندگان، همان‌طور که از نامشان پیداست، عمدتاً اعتبارنامه‌هایی را که ازسوی صادرکنندگان صادر شده است نگهداری می‌کنند.

این مدارک به‌صورت برنامه‌ای در دستگاهتان ذخیره می‌شوند و سپس می‌توانید آن‌ها را به طرف‌های درخواست‌کننده ارائه دهید.

و مانند صادرکنندگان، هرکسی می‌تواند دارنده باشد.

درواقع، غیرمعمول نیست که صادرکنندگان و دارندگان توسط یک نهاد مدیریت شوند.

مثلاً باشگاهی که می‌خواهد هم گواهی عضویت دیجیتال خودش را ایجاد کند و هم آن را ازطریق برنامه خودش مدیریت کند.

این یعنی هم صادرکننده و هم دارنده در یک شخص جمع شده‌اند.

بسیار خوب، طرف سوم همان درستی‌سنج یا طرفی است که «اطلاعات اعتباری دیجیتال» را درخواست می‌کند.

درستی‌سنج‌ها معمولاً برای بررسی مشخصه‌های کاربر، مثل الزامات سنی، نام خانوادگی، و غیره، درخواست اطلاعات کاربری می‌کنند.

این‌ها کسب‌وکارها یا برنامه‌هایی هستند که برای انجام سرویس، مثلاً خرید الکل یا درستی‌سنجی حداقل سن، به داده‌های کاربر اضافی نیاز دارند.

در Android، تعاملات بین این سه طرف و کاربر ازطریق Credential Manager با Digital Credentials API هماهنگ می‌شود.

صادرکننده می‌تواند برای صدور اطلاعات کاربری برای دارنده با API تماس بگیرد، هرچند اگر هر دو یک نهاد باشند این کار ضروری نیست.

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

«مدیر اطلاعات کاربری» درخواست را با همه دارندگان موجود مطابقت می‌دهد و آن‌ها را به کاربر ارائه می‌دهد تا اطلاعات کاربری را انتخاب کند و رضایت دهد.

وقتی دارنده انتخاب شد، فراخوانی می‌شود و درصورت نیاز می‌تواند قبل‌از هم‌رسانی نهایی اعتبارنامه با درستی‌سنج، بررسی‌های بیشتری انجام دهد.

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

اکنون ممکن است از خود بپرسید که «اعتبارنامه‌های دیجیتال» دقیقاً چگونه ایمن هستند؟

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

بنابراین، در سمت صادرکننده، وقتی صادرکننده می‌خواهد اعتبارنامه‌ای را با دارنده هم‌رسانی کند، باید تأیید کند که دارنده نمی‌تواند دستکاری یا کپی شود، اساساً باید قابل‌اعتماد باشد.

چگونه می‌تواند این را درستی‌سنجی کند؟

خب، قبل‌از اینکه صادرکننده اعتبارنامه را صادر کند، دارنده باید هویت خود و امنیت دستگاهی را که اعتبارنامه در آن استفاده می‌شود اثبات کند.

دارنده گواهی کیف پول خود را معمولاً به‌صورت زنجیره گواهی قابل‌تأیید ارسال می‌کند.

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

این برنامه کلید عمومی را از این جفت کلید با تصدیق کلید Android به صادرکننده ارسال می‌کند تا صادرکننده بتواند مشروعیت سخت‌افزار را اعتبارسنجی کند.

صادرکننده این کلید عمومی را در اطلاعات کاربری صادرشده امضا می‌کند تا اطلاعات کاربری به‌طور رسمی به یک دستگاه محدود شود.

در سمت دارنده، وقتی دارنده اطلاعات اعتباری جدیدی داشته باشد، فقط فراداده اطلاعات اعتباری خود را در Credential Manager ثبت می‌کند.

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

هیچ داده واقعی کاربر هرگز در Credential Manager ثبت نمی‌شود یا دراختیار Google قرار نمی‌گیرد.

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

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

همان‌طور که ممکن است به‌خاطر داشته باشید، دارنده فقط یک برنامه است، بنابراین برنامه فراخوانی می‌شود.

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

خود داده‌های اعتبارنامه برای Google قابل‌دسترسی نیست.

فقط فراداده مسیریابی ثبت می‌شود و بار داده بین دارنده و درستی‌سنج به‌صورت سرتاسر رمزگذاری می‌شود.

این کار به دارنده کنترل می‌دهد که اطلاعات اعتباری خود را با کدام طرف‌ها هم‌رسانی کند.

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

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

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

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

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

اکنون که درباره امنیت «مدارک دیجیتال» صحبت کردیم، بیایید به برخی‌از موارد استفاده «مدارک دیجیتال» که امروزه ازطریق Digital Credentials API در Android دردسترس است بپردازیم.

اولین موردی که می‌خواهم به آن بپردازم درستی‌سنجی ایمیل نام دارد.

این میانای برنامه‌سازی کاربردی، Gmail واردشده به سیستم کاربر را مستقیماً از دستگاه او می‌گیرد و آن را به‌عنوان اعتبارنامه دیجیتال تأییدشده توسط Google به برنامه شما ارائه می‌دهد و نیاز به ارسال گذرواژه‌های یک‌باره یا پیوندهای جادویی را ازبین می‌برد.

این یعنی کاربر هرگز از برنامه شما خارج نمی‌شود و فقط باید با یک تک‌ضرب روی برگه پایین Credential Manager آشنا رضایت دهد.

در اینجا نسخه نمایشی از ضبط نسخه نمایشی API درحال اجرا وجود دارد.

این یک برنامه نمونه است که درستی‌سنجی ایمیل را ازطریق Digital Credentials API پیاده‌سازی می‌کند.

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

در این مورد، فقط Google دارنده این اعتبارنامه ایمیل درستی‌سنجی‌شده است که آن را در برگ پایین می‌بینید.

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

و درواقع، Google در این مورد هم صادرکننده و هم دارنده گواهی دیجیتال است.

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

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

برای کاربر، این کار واقعاً به‌سادگی اعلام موافقت و سپس رفتن به صفحه بعدی است.

اگر می‌خواهید آن را امتحان کنید، می‌توانید به نمونه GitHub ما بروید و آن را در دستگاه خودتان نصب کنید.

لطفاً سعی کنید از آن در دستگاه فیزیکی استفاده کنید و توجه داشته باشید که باید حداقل به یک حساب Gmail در دستگاهتان وارد شده باشید.

بنابراین، اگر افراد علاقه‌مند باشند، کمی بیشتر وقت خواهم گذاشت.

بسیار خوب.

هیجان‌انگیز است، نه؟

و وقتی به درستی‌سنجی ایمیل فکر می‌کنید، شکل بعدی درستی‌سنجی کاربر که به ذهنتان می‌رسد چیست؟

درست است، درستی‌سنجی شماره تلفن.

Digital Credentials API همچنین به‌طور بومی از درستی‌سنجی شماره تلفن پشتیبانی می‌کند و اصطکاک و آسیب‌پذیری گذرواژه‌های یک‌بارمصرف پیامکی را ازبین می‌برد.

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

کاربر فقط برگه پایین Credential Manager آشنا را برای هم‌رسانی یا درستی‌سنجی شماره تلفن خود می‌بیند، در برنامه می‌ماند، و فقط با چند ضربه درستی‌سنجی را تکمیل می‌کند.

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

خب، این راه‌اندازی چگونه کار می‌کند؟

خوب، اگر این را به طرف‌های اعتبارنامه دیجیتال نگاشت کنیم، صادرکننده در این مورد شرکت مخابراتی شماره تلفن موجود در سیم‌کارت دستگاه است و دارنده Android Telephony است.

وقتی درستی‌سنجی‌کننده‌ای، مثل برنامه شما، شماره تلفن کاربر را درخواست می‌کند، این شماره تلفن ازطریق فراخوانی Digital Credentials API از Google Telephony بازیابی می‌شود.

ممکن است برایتان سؤال باشد که صدور صورت‌حساب چگونه کار می‌کند.

مرحله اضافه‌ای وجود دارد که مختص این جریان است، که در آن اعتبارنامه برای اهداف صورت‌حساب به شرکت مخابراتی یا تجمیع‌کننده شما ارسال می‌شود.

این اتفاق پس‌از بازیابی شماره تلفن از Google Telephony رخ می‌دهد، جایی که شماره تلفن به‌صورت رمزگذاری‌شده ذخیره می‌شود.

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

نکته عالی درباره این روش این است که شرکت مخابراتی فقط برای درستی‌سنجی‌های موفق از شما هزینه دریافت می‌کند که ازطریق داده یا Wi-Fi منتقل می‌شوند و بسیار قابل‌اعتمادتر از پیامک هستند.

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

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

این کاربر چند سیم‌کارت دارد و یکی را برای هم‌رسانی با برنامه انتخاب می‌کند.

وقتی کاربر انتخابش را تأیید کرد، تبادل به‌طور کامل در پس‌زمینه انجام می‌شود.

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

کاربر هرگز مجبور نبود برنامه را ترک کند و فقط باید شماره تلفن را برای هم‌رسانی انتخاب و تأیید می‌کرد تا به‌راحتی و تنها با چند ضربه در جریان پیش برود.

فقط اجازه دهید این تمام شود تا بتوانید تکمیل را یک بار دیگر ببینید.

و بنابراین شماره تلفن را در آن صفحه نهایی می‌بینید.

و همین.

امروز به موضوعات زیادی پرداختیم.

ابتدا استفاده از Credential Manager را برای بهبود پیاده‌سازی گذرکلید و حرکت به‌سمت دنیای بدون گذرواژه بررسی کردیم.

برای کسب اطلاعات بیشتر و دسترسی به برنامه‌های نمونه ما، لطفاً منابع ما درباره «مدیر اطلاعات کاربری» و گذرکلیدها را در اینجا ببینید.

سپس، الزام آتی ورود به سیستم با یک ضربه را برای برنامه‌هایتان پوشش دادیم که باعث می‌شود کاربران شما هنگام راه‌اندازی دستگاه جدید به‌راحتی به سیستم وارد شوند.

این مورد تا آوریل ۲۰۲۷ در «فروشگاه Play» اجباری خواهد شد، بنابراین لطفاً این موضوع را در تقویمتان یادداشت کنید.

درنهایت، نحوه عملکرد اطلاعات اعتباری دیجیتال و برخی‌از مفیدترین ویژگی‌های آن‌ها را در Android پوشش دادیم.

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

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

آینده هویت در Android اینجاست و هیجان‌انگیزتر از همیشه است.

از وقتی که گذاشتید سپاس‌گزارم و می‌دانم که وقت ناهار است، پس لطفاً از غذای بیرون لذت ببرید.

و اگر درباره گذرکلیدها یا اطلاعات کاربری دیجیتال سؤالی دارید، حتماً از من یا تام بپرسید.

به‌سلامتی.