ফর্ম অটোফিলের মাধ্যমে একটি পাসকি দিয়ে সাইন ইন করুন

এমন একটি সাইন-ইন অভিজ্ঞতা তৈরি করুন যা পাসকি ব্যবহারের পাশাপাশি বিদ্যমান পাসওয়ার্ড ব্যবহারকারীদেরও সুবিধা দেবে।

Eiji Kitamura

এই নির্দেশিকাটি ব্যাখ্যা করে যে কীভাবে ফর্ম অটোফিল ব্যবহার করে ব্যবহারকারীদের পাসওয়ার্ডের পাশাপাশি পাসকি দিয়েও সাইন ইন করার সুযোগ দেওয়া যায়। ফর্ম অটোফিল ব্যবহার একটি সমন্বিত সাইন-ইন অভিজ্ঞতা তৈরি করে, যা পাসওয়ার্ড থেকে আরও সুরক্ষিত এবং ব্যবহারকারী-বান্ধব পাসকি প্রমাণীকরণ পদ্ধতিতে রূপান্তরকে সহজ করে তোলে।

আপনার বিদ্যমান সাইন-ইন ফর্মগুলিতে ন্যূনতম ঝামেলার সাথে পাসকি এবং পাসওয়ার্ড উভয় ব্যবহারকারীকে সমর্থন করার জন্য কীভাবে WebAuthn-এর কন্ডিশনাল UI প্রয়োগ করতে হয় তা শিখুন।

পাসকি দিয়ে সাইন-ইন করতে ফর্ম অটোফিল কেন ব্যবহার করবেন?

পাসকি ব্যবহারকারীদের আঙুলের ছাপ, মুখমণ্ডল বা ডিভাইসের পিন ব্যবহার করে ওয়েবসাইটে সাইন ইন করার সুযোগ দেয়।

যদি সকল ব্যবহারকারীর পাসকি থাকতো, তাহলে প্রমাণীকরণ প্রক্রিয়াটি একটিমাত্র সাইন-ইন বাটন হতে পারতো। বাটনটিতে ট্যাপ করলে ব্যবহারকারী সরাসরি স্ক্রিন লকের মাধ্যমে অ্যাকাউন্টটি যাচাই করে সাইন ইন করতে পারতেন।

তবে, পাসওয়ার্ড থেকে পাসকিতে রূপান্তর কিছু চ্যালেঞ্জ তৈরি করে। এই সময়ে ওয়েবসাইটগুলোকে পাসওয়ার্ড এবং পাসকি উভয় ব্যবহারকারীকেই সমর্থন করতে হবে। কোন কোন সাইট পাসকি ব্যবহার করে তা ব্যবহারকারীদের মনে রাখতে বলা এবং শুরুতেই তাদের একটি সাইন-ইন পদ্ধতি বেছে নিতে বলা একটি খারাপ ব্যবহারকারী অভিজ্ঞতা তৈরি করে।

পাসকিও একটি নতুন প্রযুক্তি, এবং এটি স্পষ্টভাবে ব্যাখ্যা করা কঠিন হতে পারে। পরিচিত অটোফিল ইন্টারফেস ব্যবহার করলে এই পরিবর্তনের প্রতিবন্ধকতা এবং ব্যবহারকারীর পরিচিতি—উভয়ই পূরণ করা সহজ হয়।

শর্তসাপেক্ষ UI ব্যবহার করুন

পাসকি এবং পাসওয়ার্ড উভয় ব্যবহারকারীকে কার্যকরভাবে সহায়তা করার জন্য, আপনার ফর্মের অটোফিল সাজেশনে পাসকি অন্তর্ভুক্ত করুন। এই পদ্ধতিটি কন্ডিশনাল UI ব্যবহার করে, যা WebAuthn স্ট্যান্ডার্ডের একটি বৈশিষ্ট্য।

যখন ব্যবহারকারী ইউজারনেম ইনপুট ফিল্ডে ফোকাস করেন, তখন একটি অটোফিল ডায়ালগ বক্স প্রদর্শিত হয়, যেখানে সেভ করা পাসওয়ার্ডের পাশাপাশি সংরক্ষিত পাসকিগুলোও দেখানো হয়। ব্যবহারকারী পাসকি অথবা পাসওয়ার্ড যেকোনো একটি বেছে নিয়ে সাইন ইন করতে পারেন এবং পাসকি বেছে নিলে ডিভাইসের স্ক্রিন লক ব্যবহার করতে পারেন।

এর মাধ্যমে ব্যবহারকারীরা বিদ্যমান সাইন-ইন ফর্ম ব্যবহার করে আপনার ওয়েবসাইটে সাইন ইন করতে পারেন, তবে তাদের কাছে পাসকি থাকলে তার বাড়তি নিরাপত্তা সুবিধাও পাওয়া যায়।

পাসকি প্রমাণীকরণ কীভাবে কাজ করে

পাসকি দিয়ে প্রমাণীকরণের জন্য, আপনি WebAuthn API ব্যবহার করেন।

পাসকি প্রমাণীকরণ প্রক্রিয়ার চারটি উপাদান হলো:

• ব্যাকএন্ড : পাবলিক কী সহ ব্যবহারকারীর অ্যাকাউন্টের বিবরণ সংরক্ষণ করে।
• ফ্রন্টএন্ড : ব্রাউজারের সাথে যোগাযোগ করে এবং ব্যাকএন্ড থেকে প্রয়োজনীয় ডেটা সংগ্রহ করে।
• ব্রাউজার : আপনার জাভাস্ক্রিপ্ট চালায় এবং WebAuthn API-এর সাথে যোগাযোগ স্থাপন করে।
• পাসকি প্রদানকারী : পাসকি তৈরি এবং সংরক্ষণ করে। এটি সাধারণত গুগল পাসওয়ার্ড ম্যানেজারের মতো কোনো পাসওয়ার্ড ম্যানেজার বা একটি সিকিউরিটি কী হয়ে থাকে।

পাসকি প্রমাণীকরণ প্রক্রিয়াটি নিম্নলিখিত প্রবাহ অনুসরণ করে:

1. ব্যবহারকারী সাইন-ইন পৃষ্ঠায় যান এবং ফ্রন্টএন্ড ব্যাকএন্ডের কাছে একটি প্রমাণীকরণ চ্যালেঞ্জের জন্য অনুরোধ করে।
2. ব্যাকএন্ড ব্যবহারকারীর অ্যাকাউন্টের সাথে যুক্ত একটি WebAuthn চ্যালেঞ্জ তৈরি করে ফেরত দেয়।
3. ব্রাউজার ব্যবহার করে প্রমাণীকরণ শুরু করার জন্য ফ্রন্টএন্ড চ্যালেঞ্জ সহ navigator.credentials.get() কল করে।
4. ব্রাউজারটি পাসকি প্রদানকারীর সাথে যোগাযোগ করে ব্যবহারকারীকে একটি পাসকি নির্বাচন করতে (প্রায়শই সাইন-ইন ফিল্ডে ফোকাস করার মাধ্যমে চালু হওয়া একটি অটোফিল ডায়ালগের মাধ্যমে) এবং ডিভাইসের স্ক্রিন লক বা বায়োমেট্রিক্স ব্যবহার করে তার পরিচয় যাচাই করতে অনুরোধ করে।
5. ব্যবহারকারীর সফল যাচাইকরণের পর, পাসকি প্রদানকারী চ্যালেঞ্জটিতে স্বাক্ষর করে এবং ব্রাউজারটি ফলস্বরূপ প্রাপ্ত পাবলিক কী ক্রেডেনশিয়ালটি (স্বাক্ষর সহ) ফ্রন্টএন্ডে ফেরত পাঠায়।
6. ফ্রন্টএন্ড এই ক্রেডেনশিয়ালটি ব্যাকএন্ডে পাঠায়।
7. ব্যাকএন্ড ব্যবহারকারীর সংরক্ষিত পাবলিক কী-এর সাথে ক্রেডেনশিয়ালের স্বাক্ষর যাচাই করে। যাচাই সফল হলে, ব্যাকএন্ড ব্যবহারকারীকে সাইন ইন করিয়ে দেয়।

ফর্ম অটোফিলের মাধ্যমে পাসকি দিয়ে প্রমাণীকরণ করুন।

ফর্ম অটোফিল ব্যবহার করে পাসকি অথেন্টিকেশন শুরু করতে, সাইন-ইন পেজ লোড হওয়ার সময় একটি কন্ডিশনাল WebAuthn get কল করুন। navigator.credentials.get() এর এই কলে mediation: 'conditional' অপশনটি অন্তর্ভুক্ত থাকে।
WebAuthn- এর navigator.credentials.get() API-তে একটি শর্তসাপেক্ষ অনুরোধ করলে UI তাৎক্ষণিকভাবে প্রদর্শিত হয় না। পরিবর্তে, এটি একটি পেন্ডিং অবস্থায় অপেক্ষা করে যতক্ষণ না ব্যবহারকারী ইউজারনেম ফিল্ডের অটোফিল প্রম্পটে ইন্টারঅ্যাক্ট করেন। যদি ব্যবহারকারী একটি পাসকি নির্বাচন করেন, তাহলে ব্রাউজারটি প্রচলিত ফর্ম সাবমিশনকে বাইপাস করে ব্যবহারকারীকে সাইন ইন করার জন্য একটি ক্রেডেনশিয়াল সহ পেন্ডিং প্রমিসটি রিজলভ করে। যদি ব্যবহারকারী এর পরিবর্তে একটি পাসওয়ার্ড বেছে নেন, তাহলে প্রমিসটি রিজলভ হয় না এবং স্ট্যান্ডার্ড পাসওয়ার্ড সাইন-ইন প্রক্রিয়া চলতে থাকে। তখন ব্যবহারকারীকে সাইন ইন করার দায়িত্ব পেজটির উপর বর্তায়।

ফর্ম ইনপুট ফিল্ডে টীকা যোগ করুন

পাসকি অটোফিল চালু করতে, আপনার ফর্মের ইউজারনেম input ফিল্ডে autocomplete অ্যাট্রিবিউটটি যোগ করুন। username এবং webauthn উভয়কেই স্পেস দিয়ে আলাদা করে লিখুন।

<input type="text" name="username" autocomplete="username webauthn" autofocus>

এই ফিল্ডে autofocus যোগ করলে পেজ লোড হওয়ার সাথে সাথে স্বয়ংক্রিয়ভাবে অটোফিল প্রম্পট চালু হয়ে যায় এবং সাথে সাথে উপলব্ধ পাসওয়ার্ড ও পাসকিগুলো দেখানো হয়।

বৈশিষ্ট্য সনাক্তকরণ

একটি শর্তসাপেক্ষ WebAuthn API কল করার আগে, যাচাই করুন যে:

• ব্রাউজারটি PublicKeyCredential সহ WebAuthn সমর্থন করে।

• ব্রাউজারটি PublicKeyCredential.getClientCapabilities() এর মাধ্যমে সক্ষমতা শনাক্তকরণ সমর্থন করে।

• ব্রাউজারটি conditionalGet এর মাধ্যমে WebAuthn কন্ডিশনাল UI সমর্থন করে।

নিচের কোড স্নিপেটটিতে দেখানো হয়েছে, ব্রাউজারটি এই ফিচারগুলো সমর্থন করে কিনা তা আপনি কীভাবে পরীক্ষা করতে পারেন:

if (window.PublicKeyCredential && PublicKeyCredential.getClientCapabilities) {
  const capabilities = await PublicKeyCredential.getClientCapabilities();
  // Check if conditional mediation is available.  
  if (capabilities.conditionalGet === true) {
    // The browser supports conditional mediation.
  }
}

ব্যাকএন্ড থেকে তথ্য সংগ্রহ করুন

navigator.credentials.get() কলটি শুরু করার জন্য আপনার ব্যাকএন্ডকে ফ্রন্টএন্ডে কয়েকটি অপশন সরবরাহ করতে হয়। এই অপশনগুলো সাধারণত আপনার সার্ভারের কোনো এন্ডপয়েন্ট থেকে একটি JSON অবজেক্ট হিসেবে সংগ্রহ করা হয়।

অপশনস অবজেক্টের প্রধান প্রোপার্টিগুলোর মধ্যে রয়েছে:

• challenge : একটি ArrayBuffer-এ সার্ভার-তৈরি চ্যালেঞ্জ (সাধারণত JSON পরিবহনের জন্য Base64URL এনকোড করা)। রিপ্লে অ্যাটাক প্রতিরোধ করার জন্য এটি অপরিহার্য। আপনার সার্ভারকে অবশ্যই প্রতিটি সাইন-ইন প্রচেষ্টার জন্য একটি নতুন চ্যালেঞ্জ তৈরি করতে হবে এবং অল্প সময়ের মধ্যে বা প্রচেষ্টা ব্যর্থ হলে সেটিকে বাতিল করে দিতে হবে।
• allowCredentials : ক্রেডেনশিয়াল বর্ণনাকারীর একটি অ্যারে। একটি খালি অ্যারে দিন। এটি ব্রাউজারকে নির্দিষ্ট rpId জন্য সমস্ত ক্রেডেনশিয়াল তালিকাভুক্ত করতে নির্দেশ দেয়।

• userVerification : ব্যবহারকারী যাচাইকরণের জন্য আপনার পছন্দ নির্দিষ্ট করে, যেমন ডিভাইসের স্ক্রিন লক আবশ্যক করা। ডিফল্ট এবং প্রস্তাবিত মান হলো "preferred" । সম্ভাব্য মানগুলো হলো:

  • "required" : প্রমাণীকরণকারী (যেমন পিন বা বায়োমেট্রিক্স) দ্বারা ব্যবহারকারী যাচাইকরণ অবশ্যই সম্পন্ন করতে হবে। যাচাইকরণ সম্পন্ন করা না গেলে অপারেশনটি ব্যর্থ হয়।
  • "preferred" : প্রমাণীকরণকারী ব্যবহারকারী যাচাই করার চেষ্টা করে, কিন্তু এটি ছাড়াও প্রক্রিয়াটি সফল হতে পারে।
  • "discouraged" : সম্ভব হলে প্রমাণীকরণকারীর ব্যবহারকারী যাচাইকরণ এড়িয়ে চলা উচিত।

• rpId : আপনার রিলায়িং পার্টি আইডি, সাধারণত আপনার ওয়েবসাইটের ডোমেইন (যেমন example.com )। এই মানটি অবশ্যই পাসকি ক্রেডেনশিয়াল তৈরি করার সময় ব্যবহৃত rp.id সাথে হুবহু মিলতে হবে।

আপনার সার্ভারকে এই অপশনস অবজেক্টটি তৈরি করতে হবে। JSON ট্রান্সপোর্টের জন্য ArrayBuffer ভ্যালুগুলোকে (যেমন ` challenge ) অবশ্যই Base64URL এনকোড করতে হবে। ফ্রন্টএন্ডে, JSON পার্স করার পর, অবজেক্টটিকে (Base64URL স্ট্রিং ডিকোডিং সহ) navigator.credentials.get() প্রত্যাশিত ফরম্যাটে রূপান্তর করতে PublicKeyCredential.parseRequestOptionsFromJSON() ব্যবহার করুন।

নিম্নলিখিত কোড স্নিপেটটি দেখায় কিভাবে আপনি একটি পাসকি দিয়ে প্রমাণীকরণের জন্য প্রয়োজনীয় তথ্য সংগ্রহ এবং ডিকোড করতে পারেন।

// Fetch an encoded PubicKeyCredentialRequestOptions from the server.
const _options = await fetch('/webauthn/signinRequest');

// Deserialize and decode the PublicKeyCredentialRequestOptions.
const decoded_options = JSON.parse(_options);
const options = PublicKeyCredential.parseRequestOptionsFromJSON(decoded_options);
...

ব্যবহারকারীকে প্রমাণীকরণের জন্য conditional ফ্ল্যাগ সহ WebAuthn API কল করুন।

একবার আপনার কাছে publicKeyCredentialRequestOptions অবজেক্টটি (নিচের উদাহরণ কোডে options হিসাবে উল্লিখিত) প্রস্তুত হয়ে গেলে, শর্তসাপেক্ষ পাসকি প্রমাণীকরণ শুরু করতে navigator.credentials.get() কল করুন।

// To abort a WebAuthn call, instantiate an AbortController.
const abortController = new AbortController();

// Invoke WebAuthn to authenticate with a passkey.
const credential = await navigator.credentials.get({
  publicKey: options,
  signal: abortController.signal,
  // Specify 'conditional' to activate conditional UI
  mediation: 'conditional'
});

এই কলের জন্য মূল প্যারামিটারসমূহ:

• publicKey : এটি অবশ্যই publicKeyCredentialRequestOptions অবজেক্টটি হতে হবে (উদাহরণে যার নাম options ), যা আপনি পূর্ববর্তী ধাপে আপনার সার্ভার থেকে সংগ্রহ করে প্রক্রিয়া করেছিলেন।
• signal : একটি AbortController এর সিগন্যাল (যেমন abortController.signal ) পাস করার মাধ্যমে আপনি প্রোগ্রাম্যাটিকভাবে get() রিকোয়েস্টটি বাতিল করতে পারেন। এটি তখন কাজে আসে যখন আপনি অন্য কোনো WebAuthn কল করতে চান।
• mediation: 'conditional' : এটি একটি অত্যন্ত গুরুত্বপূর্ণ ফ্ল্যাগ যা WebAuthn কলটিকে শর্তসাপেক্ষ করে তোলে। এটি ব্রাউজারকে তাৎক্ষণিকভাবে একটি মোডাল ডায়ালগ দেখানোর পরিবর্তে, একটি অটোফিল প্রম্পটের মাধ্যমে ব্যবহারকারীর ইন্টারঅ্যাকশনের জন্য অপেক্ষা করতে বলে।

ফেরত আসা পাবলিক কী ক্রেডেনশিয়ালটি RP সার্ভারে পাঠান।

যদি ব্যবহারকারী একটি পাসকি নির্বাচন করেন এবং সফলভাবে তার পরিচয় যাচাই করেন (উদাহরণস্বরূপ, তার ডিভাইসের স্ক্রিন লক ব্যবহার করে), navigator.credentials.get() প্রমিসটি রিজলভ হয়। এটি আপনার ফ্রন্টএন্ডে একটি PublicKeyCredential অবজেক্ট রিটার্ন করে।

বিভিন্ন কারণে প্রমিসটি প্রত্যাখ্যাত হতে পারে। আপনার কোডে Error অবজেক্টের name প্রপার্টিটি পরীক্ষা করে এই ত্রুটিগুলো সামাল দেওয়া উচিত:

• NotAllowedError : ব্যবহারকারী অপারেশনটি বাতিল করেছেন, অথবা কোনো পাসকি নির্বাচন করা হয়নি।
• AbortError : অপারেশনটি বাতিল করা হয়েছে, সম্ভবত আপনার কোডে AbortController ব্যবহারের কারণে।
• অন্যান্য ব্যতিক্রম: একটি অপ্রত্যাশিত ত্রুটি ঘটেছে। ব্রাউজার সাধারণত ব্যবহারকারীকে একটি ত্রুটি ডায়ালগ দেখায়।

PublicKeyCredential অবজেক্টটিতে বেশ কয়েকটি প্রোপার্টি থাকে। অথেনটিকেশনের জন্য প্রাসঙ্গিক প্রধান প্রোপার্টিগুলো হলো:

• id : প্রমাণীকৃত পাসকি ক্রেডেনশিয়ালের base64url এনকোডেড আইডি।
• rawId : ক্রেডেনশিয়াল আইডি-র একটি ArrayBuffer সংস্করণ।
• response.clientDataJSON : ক্লায়েন্ট ডেটার একটি ArrayBuffer। এই ফিল্ডটিতে চ্যালেঞ্জ এবং অরিজিনের মতো তথ্য থাকে, যা আপনার সার্ভারকে অবশ্যই যাচাই করতে হবে।
• response.authenticatorData : অথেন্টিকেটর ডেটার একটি অ্যারেবাফার। এই ফিল্ডে আরপি আইডি-র মতো তথ্য অন্তর্ভুক্ত থাকে।
• response.signature : স্বাক্ষর ধারণকারী একটি ArrayBuffer। এই মানটি ক্রেডেনশিয়ালের মূল অংশ এবং আপনার সার্ভারকে অবশ্যই ক্রেডেনশিয়ালের জন্য সংরক্ষিত পাবলিক কী ব্যবহার করে এই স্বাক্ষরটি যাচাই করতে হবে।
• response.userHandle : একটি ArrayBuffer যা পাসকি নিবন্ধনের সময় প্রদত্ত ব্যবহারকারী আইডি ধারণ করে।
• authenticatorAttachment : এটি নির্দেশ করে যে অথেন্টিকেটরটি ক্লায়েন্ট ডিভাইসের ( platform ) অংশ নাকি বাহ্যিক ( cross-platform )। ব্যবহারকারী যদি ফোন দিয়ে সাইন ইন করে থাকেন , তাহলে একটি cross-platform অ্যাটাচমেন্ট থাকতে পারে। এই ধরনের ক্ষেত্রে, ভবিষ্যতের সুবিধার জন্য তাদেরকে বর্তমান ডিভাইসে একটি পাসওয়ার্ড তৈরি করতে বলার কথা বিবেচনা করুন।
• type : এই ফিল্ডটি সর্বদা "public-key" হিসেবে সেট করা থাকে।

এই PublicKeyCredential অবজেক্টটি আপনার ব্যাকএন্ডে পাঠাতে, প্রথমে .toJSON() মেথডটি কল করুন। এই মেথডটি ক্রেডেনশিয়ালটির একটি JSON-সিরিয়ালাইজেবল সংস্করণ তৈরি করে, যা ArrayBuffer প্রোপার্টিগুলোকে (যেমন rawId , clientDataJSON , authenticatorData , signature , এবং userHandle ) Base64URL এনকোডেড স্ট্রিং-এ সঠিকভাবে রূপান্তর করে। এরপর, এই অবজেক্টটিকে একটি স্ট্রিং-এ রূপান্তর করতে JSON.stringify() ব্যবহার করুন এবং সার্ভারে আপনার রিকোয়েস্টের বডিতে এটি পাঠিয়ে দিন।

...
// Encode and serialize the PublicKeyCredential.
const _result = credential.toJSON();
const result = JSON.stringify(_result);

// Encode and send the credential to the server for verification.  
const response = await fetch('/webauthn/signinResponse', {
  method: 'post',
  credentials: 'same-origin',
  body: result
});

স্বাক্ষর যাচাই করুন

যখন আপনার ব্যাকএন্ড সার্ভার পাবলিক কী ক্রেডেনশিয়ালটি গ্রহণ করে, তখন তাকে এর সত্যতা যাচাই করতে হয়। এর মধ্যে অন্তর্ভুক্ত রয়েছে:

1. ক্রেডেনশিয়াল ডেটা পার্স করা হচ্ছে।
2. ক্রেডেনশিয়ালটির id সাথে যুক্ত সংরক্ষিত পাবলিক কী-টি খোঁজা হচ্ছে।
3. সংরক্ষিত পাবলিক কী-এর সাথে প্রাপ্ত signature যাচাই করা হচ্ছে।
4. অন্যান্য ডেটা যাচাই করা, যেমন চ্যালেঞ্জ এবং উৎস।

এই ক্রিপ্টোগ্রাফিক অপারেশনগুলো নিরাপদে পরিচালনা করার জন্য আমরা একটি সার্ভার-সাইড FIDO/WebAuthn লাইব্রেরি ব্যবহারের পরামর্শ দিই। আপনি awesome-webauthn গিটহাব রিপোজিটরিতে ওপেন সোর্স লাইব্রেরিগুলো খুঁজে পেতে পারেন ।

যদি স্বাক্ষর এবং অন্যান্য সমস্ত অ্যাসারশন বৈধ হয়, তবে সার্ভার ব্যবহারকারীকে সাইন ইন করতে পারে। সার্ভার-সাইড যাচাইকরণের বিস্তারিত ধাপগুলোর জন্য, সার্ভার-সাইড পাসকি অথেন্টিকেশন দেখুন।

ব্যাকএন্ডে উপযুক্ত ক্রেডেনশিয়াল খুঁজে না পাওয়া গেলে সংকেত দিন।

সাইন-ইন করার সময় আপনার ব্যাকএন্ড সার্ভার যদি মিলে যাওয়া আইডি সহ কোনো ক্রেডেনশিয়াল খুঁজে না পায়, তাহলে হতে পারে ব্যবহারকারী পূর্বে আপনার সার্ভার থেকে এই পাসকিটি মুছে ফেলেছেন, কিন্তু তার পাসকি প্রোভাইডারের কাছ থেকে তা করেননি। এই অমিলের কারণে ব্যবহারকারীর অভিজ্ঞতা বিভ্রান্তিকর হতে পারে, যদি পাসকি প্রোভাইডার এমন একটি পাসকি সাজেস্ট করতে থাকে যা আপনার সাইটে আর কাজ করে না। এই সমস্যা সমাধানের জন্য, আপনার উচিত পাসকি প্রোভাইডারকে এই অব্যবহৃত পাসকিটি সরিয়ে ফেলার জন্য সংকেত দেওয়া।

আপনি Webauthn Signal API- এর অংশ PublicKeyCredential.signalUnknownCredential() মেথডটি ব্যবহার করে পাসকি প্রোভাইডারকে জানাতে পারেন যে নির্দিষ্ট ক্রেডেনশিয়ালটি সরিয়ে ফেলা হয়েছে বা এর অস্তিত্ব নেই। যদি আপনার সার্ভার নির্দেশ করে (উদাহরণস্বরূপ, 404-এর মতো একটি নির্দিষ্ট HTTP স্ট্যাটাস কোডের মাধ্যমে) যে উপস্থাপিত ক্রেডেনশিয়াল আইডিটি অজানা, তাহলে ক্লায়েন্ট-সাইডে এই স্ট্যাটিক মেথডটি কল করুন। এই মেথডে RP ID এবং অজানা ক্রেডেনশিয়াল আইডিটি প্রদান করুন। পাসকি প্রোভাইডার, যদি এটি সিগন্যালটি সমর্থন করে, তবে পাসকিটি সরিয়ে ফেলবে।

// Detect authentication failure due to lack of the credential
if (response.status === 404) {
  // Feature detection
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "example.com",
      credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA" // base64url encoded credential ID
    });
  } else {
    // Encourage the user to delete the passkey from the password manager nevertheless.
    ...
  }
}

প্রমাণীকরণের পরে

ব্যবহারকারী কীভাবে সাইন ইন করেছেন তার ওপর নির্ভর করে আমরা অনুসরণ করার জন্য বিভিন্ন কর্মপ্রক্রিয়ার পরামর্শ দিই।

যদি ব্যবহারকারী পাসকি ছাড়া সাইন ইন করে থাকেন

যদি ব্যবহারকারী পাসকি ছাড়া আপনার ওয়েবসাইটে সাইন ইন করে থাকেন, তাহলে সম্ভবত সেই অ্যাকাউন্টের জন্য বা তার বর্তমান ডিভাইসে কোনো পাসকি রেজিস্টার করা নেই। পাসকি তৈরিতে উৎসাহিত করার জন্য এটি একটি উপযুক্ত মুহূর্ত। নিম্নলিখিত পদ্ধতিগুলো বিবেচনা করুন:

• পাসওয়ার্ডকে পাসকিতে আপগ্রেড করুন : কন্ডিশনাল ক্রিয়েট ব্যবহার করুন, এটি WebAuthn-এর একটি ফিচার যা সফলভাবে পাসওয়ার্ড দিয়ে সাইন-ইন করার পর ব্রাউজারকে ব্যবহারকারীর জন্য স্বয়ংক্রিয়ভাবে একটি পাসকি তৈরি করতে দেয়। এটি তৈরির প্রক্রিয়াকে সহজ করে পাসকি ব্যবহারের হার উল্লেখযোগ্যভাবে বাড়াতে পারে। এটি কীভাবে কাজ করে এবং কীভাবে প্রয়োগ করতে হয় তা জানুন “Help users adopt passkeys more seamlessly” থেকে।
• ম্যানুয়ালি পাসকি তৈরির জন্য অনুরোধ করুন : ব্যবহারকারীদের একটি পাসকি তৈরি করতে উৎসাহিত করুন। মাল্টি-ফ্যাক্টর অথেনটিকেশন (MFA)-এর মতো কোনো জটিল সাইন-ইন প্রক্রিয়া সম্পন্ন করার পর এটি কার্যকর হতে পারে। তবে, অতিরিক্ত অনুরোধ করা থেকে বিরত থাকুন, যা ব্যবহারকারীর অভিজ্ঞতার জন্য বিঘ্ন সৃষ্টিকারী হতে পারে।

কীভাবে আপনি ব্যবহারকারীদের পাসকি তৈরি করতে উৎসাহিত করতে পারেন এবং অন্যান্য ভালো অনুশীলনগুলো শিখতে পারেন, তা জানতে “ব্যবহারকারীদের কাছে পাসকি জানানো” শীর্ষক উদাহরণগুলো দেখুন।

যদি ব্যবহারকারী পাসকি দিয়ে সাইন ইন করে থাকেন

কোনো ব্যবহারকারী পাসকি দিয়ে সফলভাবে সাইন ইন করার পর, তাদের অভিজ্ঞতা আরও উন্নত করতে এবং অ্যাকাউন্টের ধারাবাহিকতা বজায় রাখার জন্য আপনার কাছে বেশ কয়েকটি সুযোগ থাকে।

ক্রস-ডিভাইস প্রমাণীকরণের পরে একটি নতুন পাসকি তৈরি করতে উৎসাহিত করুন।

যদি কোনো ব্যবহারকারী ক্রস-ডিভাইস পদ্ধতি ব্যবহার করে (যেমন, ফোন দিয়ে কিউআর কোড স্ক্যান করে) পাসকি দিয়ে সাইন ইন করেন, তাহলে তিনি যে ডিভাইসে সাইন ইন করছেন, সেখানে ব্যবহৃত পাসকিটি স্থানীয়ভাবে সংরক্ষিত নাও থাকতে পারে। এটি নিম্নলিখিত ক্ষেত্রে ঘটতে পারে:

• তাদের একটি পাসকি আছে, কিন্তু সেই পাসকি প্রদানকারী সাইন-ইন করার অপারেটিং সিস্টেম বা ব্রাউজারকে সমর্থন করে না।
• তারা সাইন-ইন করা ডিভাইসটিতে পাসকি প্রদানকারীর অ্যাক্সেস হারিয়েছেন, কিন্তু অন্য একটি ডিভাইসে এখনও একটি পাসকি পাওয়া যাচ্ছে।

এই পরিস্থিতিতে, ব্যবহারকারীকে বর্তমান ডিভাইসে একটি নতুন পাসকি তৈরি করতে বলার কথা বিবেচনা করুন। এটি ভবিষ্যতে তাদের একাধিক ডিভাইসে সাইন-ইন করার প্রক্রিয়াটি পুনরাবৃত্তি করা থেকে বাঁচাতে পারে। ব্যবহারকারী একাধিক ডিভাইসের পাসকি ব্যবহার করে সাইন-ইন করেছেন কিনা তা নির্ধারণ করতে, ক্রেডেনশিয়ালের authenticatorAttachment প্রপার্টিটি পরীক্ষা করুন। যদি এর মান "cross-platform" হয়, তবে এটি একাধিক ডিভাইসের প্রমাণীকরণ নির্দেশ করে। সেক্ষেত্রে, একটি নতুন পাসকি তৈরি করার সুবিধা ব্যাখ্যা করুন এবং তৈরির প্রক্রিয়াটিতে তাদের নির্দেশনা দিন।

সিগন্যাল ব্যবহার করে প্রোভাইডারের সাথে পাসকি-র বিবরণ সিঙ্ক্রোনাইজ করুন।

সামঞ্জস্যতা এবং উন্নততর ব্যবহারকারীর অভিজ্ঞতা নিশ্চিত করতে, আপনার রিলায়িং পার্টি (RP) ক্রেডেনশিয়াল ও ব্যবহারকারীর তথ্য সংক্রান্ত আপডেটগুলো পাসকি প্রোভাইডারকে জানানোর জন্য WebAuthn Signals API ব্যবহার করতে পারে।

উদাহরণস্বরূপ, পাসকি প্রোভাইডারের কাছে থাকা কোনো ব্যবহারকারীর পাসকির তালিকা নির্ভুল রাখতে, ব্যাকএন্ডে ক্রেডেনশিয়ালগুলো সিঙ্ক করে রাখুন। আপনি সংকেত দিতে পারেন যে একটি পাসকি আর বিদ্যমান নেই, যাতে পাসকি প্রোভাইডাররা অপ্রয়োজনীয় পাসকিগুলো সরিয়ে ফেলতে পারে।

একইভাবে, কোনো ব্যবহারকারী আপনার পরিষেবাতে তার ইউজারনেম বা ডিসপ্লে নেম আপডেট করলে আপনি সংকেত দিতে পারেন , যা পাসকি প্রদানকারীর দ্বারা প্রদর্শিত ব্যবহারকারীর তথ্য (উদাহরণস্বরূপ, অ্যাকাউন্ট নির্বাচন ডায়ালগে) হালনাগাদ রাখতে সাহায্য করে।

পাসকি সামঞ্জস্যপূর্ণ রাখার উত্তম অনুশীলন সম্পর্কে আরও জানতে, “সিগন্যাল এপিআই ব্যবহার করে আপনার সার্ভারে ক্রেডেনশিয়ালের সাথে পাসকি সামঞ্জস্যপূর্ণ রাখুন” দেখুন।

দ্বিতীয় কোনো ফ্যাক্টরের জন্য জিজ্ঞাসা করবেন না।

পাসকি ফিশিংয়ের মতো সাধারণ হুমকি থেকে শক্তিশালী ও অন্তর্নির্মিত সুরক্ষা প্রদান করে। তাই, দ্বিতীয় কোনো প্রমাণীকরণ ব্যবস্থা নিরাপত্তায় উল্লেখযোগ্য কোনো বাড়তি সুবিধা যোগ করে না। বরং, এটি সাইন-ইন করার সময় ব্যবহারকারীদের জন্য একটি অপ্রয়োজনীয় ধাপ তৈরি করে।

চেকলিস্ট

• ফর্ম অটোফিলের মাধ্যমে ব্যবহারকারীদের পাসকি দিয়ে সাইন ইন করার অনুমতি দিন।
• ব্যাকএন্ডে পাসকি-র সাথে মেলে এমন ক্রেডেনশিয়াল খুঁজে না পাওয়া গেলে সংকেত দিন।
• সাইন-ইন করার পর ব্যবহারকারী যদি আগে থেকে পাসকি তৈরি না করে থাকেন, তাহলে তাকে ম্যানুয়ালি একটি পাসকি তৈরি করতে বলুন।
• ব্যবহারকারী পাসওয়ার্ড (এবং একটি দ্বিতীয় ফ্যাক্টর) দিয়ে সাইন ইন করার পর স্বয়ংক্রিয়ভাবে একটি পাসকি তৈরি করুন (শর্তসাপেক্ষে)।
• ব্যবহারকারী যদি একাধিক ডিভাইসে ব্যবহারযোগ্য পাসকি দিয়ে সাইন ইন করে থাকেন, তাহলে স্থানীয় পাসকি তৈরির জন্য অনুরোধ করা হবে।
• সাইন-ইন করার পরে বা কোনো পরিবর্তন ঘটলে, উপলব্ধ পাসকিগুলির তালিকা এবং হালনাগাদ করা ব্যবহারকারীর বিবরণ (ইউজারনেম, ডিসপ্লে নেম) প্রদানকারীকে জানান।

সম্পদ

• সার্ভার-সাইড পাসকি প্রমাণীকরণ
• পাসওয়ার্ডবিহীন লগইনের জন্য একটি পাসকি তৈরি করুন।
• ব্যবহারকারীদের পাসকিগুলি কার্যকরভাবে পরিচালনা করতে সহায়তা করুন
• পাসকি
• অ্যাপল ডকুমেন্ট: ওয়েব সার্ভিসের মাধ্যমে একজন ব্যবহারকারীকে প্রমাণীকরণ
• গুগল ডকুমেন্ট: পাসকি ব্যবহার করে পাসওয়ার্ডবিহীন লগইন