ফ্রন্টএন্ড ক্রেডেনশিয়াল ম্যানেজমেন্ট: পাসওয়ার্ড ও আইডেন্টিটি এপিআই-এর গভীর বিশ্লেষণ

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

সৌভাগ্যবশত, ওয়েব প্ল্যাটফর্মটি উল্লেখযোগ্যভাবে বিকশিত হয়েছে। আধুনিক ব্রাউজারগুলিতে এখন শক্তিশালী এপিআই-এর একটি স্যুট রয়েছে যা বিশেষভাবে এই প্রমাণীকরণের চ্যালেঞ্জগুলি মোকাবিলা করার জন্য ডিজাইন করা হয়েছে। এই সরঞ্জামগুলি, সম্মিলিতভাবে ক্রেডেনশিয়াল ম্যানেজমেন্ট-এর আওতায় পড়ে, যা আমাদের সাইন-আপ এবং সাইন-ইন অভিজ্ঞতা তৈরি করতে দেয় যা কেবল আরও সুরক্ষিতই নয়, শেষ ব্যবহারকারীর জন্য নাটকীয়ভাবে সহজও। এই নিবন্ধটি ফ্রন্টএন্ড ডেভেলপারদের জন্য একটি বিস্তৃত নির্দেশিকা যা এই এপিআইগুলি কীভাবে ব্যবহার করতে হয় তা তুলে ধরে—ভিত্তিগত ক্রেডেনশিয়াল ম্যানেজমেন্ট এপিআই থেকে WebAuthn-এর পাসওয়ার্ডবিহীন ভবিষ্যৎ এবং ফেডারেটেড ক্রেডেনশিয়াল ম্যানেজমেন্ট (FedCM)-এর গোপনীয়তা-সংরক্ষণকারী জগৎ পর্যন্ত।

পুরানো পদ্ধতি: প্রচলিত ফর্ম-ভিত্তিক প্রমাণীকরণের চ্যালেঞ্জ

আধুনিক সমাধানগুলিতে প্রবেশ করার আগে, তারা যে সমস্যাগুলি সমাধান করে তা বোঝা অত্যন্ত গুরুত্বপূর্ণ। ইমেল এবং পাসওয়ার্ড ইনপুট সহ ক্লাসিক <form> বছরের পর বছর ধরে ওয়েবে পরিষেবা দিয়েছে, কিন্তু এর সীমাবদ্ধতাগুলি এখনকার বর্ধিত নিরাপত্তা হুমকি এবং ব্যবহারকারীর প্রত্যাশার জগতে আরও স্পষ্ট।

• দুর্বল ব্যবহারকারীর অভিজ্ঞতা (UX): ব্যবহারকারীদের কয়েক ডজন পরিষেবার জন্য অনন্য, জটিল পাসওয়ার্ড মনে রাখতে হয়। এর ফলে তারা ক্রেডেনশিয়াল ভুলে যায়, যা হতাশাজনক পাসওয়ার্ড রিসেট প্রক্রিয়ার দিকে নিয়ে যায়। মোবাইল ডিভাইসে, জটিল পাসওয়ার্ড টাইপ করা আরও বেশি কষ্টকর।
• নিরাপত্তা ঝুঁকি: পাসওয়ার্ডের জটিলতা মোকাবেলা করার জন্য, ব্যবহারকারীরা প্রায়ই असुरक्षित অভ্যাস অবলম্বন করে যেমন সহজ, সহজে অনুমানযোগ্য পাসওয়ার্ড ব্যবহার করা, একাধিক সাইটে একই পাসওয়ার্ড পুনরায় ব্যবহার করা, বা সেগুলি লিখে রাখা। এটি তাদের ক্রেডেনশিয়াল স্টাফিং আক্রমণের শিকার করে তোলে, যেখানে আক্রমণকারীরা অন্যান্য পরিষেবাগুলিতে অননুমোদিত অ্যাক্সেস পেতে চুরি করা ক্রেডেনশিয়ালের তালিকা ব্যবহার করে।
• ফিশিংয়ের ঝুঁকি: এমনকি অভিজ্ঞ ব্যবহারকারীরাও অত্যাধুনিক ফিশিং সাইট দ্বারা প্রতারিত হতে পারে যা তাদের ক্রেডেনশিয়াল চুরি করার জন্য বৈধ লগইন পৃষ্ঠাগুলির অনুকরণ করে। প্রচলিত পাসওয়ার্ড এর বিরুদ্ধে প্রায় কোনো সুরক্ষাই দেয় না।
• উচ্চ ডেভেলপমেন্ট ওভারহেড: স্ক্র্যাচ থেকে সুরক্ষিত প্রমাণীকরণ প্রবাহ তৈরি করা জটিল। ডেভেলপারদের অবশ্যই পাসওয়ার্ড হ্যাশিং এবং সল্টিং পরিচালনা করতে হবে, মাল্টি-ফ্যাক্টর অথেন্টিকেশন (MFA) প্রয়োগ করতে হবে, পাসওয়ার্ড রিসেট টোকেন পরিচালনা করতে হবে, এবং ব্রুট-ফোর্সিং এবং টাইমিং আক্রমণের মতো বিভিন্ন আক্রমণের বিরুদ্ধে সুরক্ষা দিতে হবে।

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

আধুনিক সমাধান: ক্রেডেনশিয়াল ম্যানেজমেন্ট এপিআই

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

এই এপিআইটি জাভাস্ক্রিপ্টে navigator.credentials অবজেক্টের মাধ্যমে অ্যাক্সেসযোগ্য এবং তিনটি মূল পদ্ধতির উপর ভিত্তি করে কাজ করে: get(), create(), এবং store()।

ক্রেডেনশিয়াল ম্যানেজমেন্ট এপিআই-এর মূল সুবিধা

• এক-ট্যাপে সাইন-ইন: ফিরে আসা ব্যবহারকারীদের জন্য, এপিআইটি প্রায় তাৎক্ষণিক সাইন-ইন অভিজ্ঞতা প্রদান করে। ব্রাউজার ব্যবহারকারীকে একটি সংরক্ষিত অ্যাকাউন্ট নির্বাচন করার জন্য অনুরোধ করতে পারে এবং একটি মাত্র ট্যাপ বা ক্লিকের মাধ্যমে ক্রেডেনশিয়ালগুলি ওয়েবসাইটে সরবরাহ করা হয়।
• সহজ সাইন-আপ: রেজিস্ট্রেশনের সময়, এপিআইটি পরিচিত তথ্য স্বয়ংক্রিয়ভাবে পূরণ করে সাহায্য করে এবং সফল সাইন-আপের পরে, ব্যবহারকারীকে তাদের নতুন ক্রেডেনশিয়াল সংরক্ষণ করার জন্য নির্বিঘ্নে অনুরোধ করে।
• একাধিক ক্রেডেনশিয়াল প্রকারের জন্য সমর্থন: এটি সম্ভবত এর সবচেয়ে শক্তিশালী বৈশিষ্ট্য। এপিআইটি এক্সটেনসিবল হওয়ার জন্য ডিজাইন করা হয়েছে, যা কেবল প্রচলিত পাসওয়ার্ড (PasswordCredential) সমর্থন করে না, বরং ফেডারেটেড আইডেন্টিটি (FederatedCredential) এবং WebAuthn দ্বারা ব্যবহৃত পাবলিক-কি ক্রেডেনশিয়াল (PublicKeyCredential) সমর্থন করে।
• উন্নত নিরাপত্তা: ইন্টারঅ্যাকশনে মধ্যস্থতা করার মাধ্যমে, ব্রাউজার নিরাপত্তা ঝুঁকি কমাতে সাহায্য করে। উদাহরণস্বরূপ, এটি নিশ্চিত করে যে ক্রেডেনশিয়ালগুলি শুধুমাত্র সেই অরিজিন (ডোমেইন) এর জন্য উপলব্ধ যার জন্য সেগুলি সংরক্ষণ করা হয়েছিল, যা অনেক ফিশিং আক্রমণের বিরুদ্ধে সহজাত সুরক্ষা প্রদান করে।

বাস্তব প্রয়োগ: `navigator.credentials.get()` ব্যবহার করে ব্যবহারকারীদের সাইন ইন করানো

get() পদ্ধতিটি সাইন ইন করার জন্য ব্যবহারকারীর ক্রেডেনশিয়াল পুনরুদ্ধার করতে ব্যবহৃত হয়। আপনি নির্দিষ্ট করতে পারেন যে আপনার অ্যাপ্লিকেশন কোন ধরণের ক্রেডেনশিয়াল সমর্থন করে।

কল্পনা করুন একজন ব্যবহারকারী আপনার লগইন পৃষ্ঠায় এসেছেন। তাদের কিছু টাইপ করার পরিবর্তে, আপনি অবিলম্বে পরীক্ষা করতে পারেন যে তাদের একটি সংরক্ষিত ক্রেডেনশিয়াল আছে কিনা।

            async function handleSignIn() {
  try {
    // Check if the API is available
    if (!navigator.credentials) {
      console.log('Credential Management API not supported.');
      // Fallback to showing the traditional form
      return;
    }

    const cred = await navigator.credentials.get({
      // We are requesting a password-based credential
      password: true,
      // You can also request other types, which we'll cover later
    });

    if (cred) {
      // A credential was selected by the user
      console.log('Credential received:', cred);
      // Now, send the credential to your server for verification
      await serverLogin(cred.id, cred.password);
    } else {
      // The user dismissed the prompt or has no saved credentials
      console.log('No credential selected.');
    }
  } catch (err) {
    console.error('Error getting credential:', err);
    // Handle errors, e.g., show the traditional form
  }
}

async function serverLogin(username, password) {
  // This is a mock function. In a real app, you would send
  // this to your backend via a POST request.
  const response = await fetch('/api/login', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ username, password }),
  });

  if (response.ok) {
    window.location.href = '/dashboard'; // Redirect on success
  } else {
    // Handle login failure
    console.error('Login failed on the server.');
  }
}

            

              
                Copy
              
            
          

এই উদাহরণে, navigator.credentials.get({ password: true }) কল করা হলে ব্রাউজার একটি নেটিভ UI (প্রায়শই একটি অ্যাকাউন্ট চয়নকারী) প্রদর্শন করে যা বর্তমান ডোমেনের জন্য সমস্ত সংরক্ষিত ক্রেডেনশিয়াল তালিকাভুক্ত করে। যদি ব্যবহারকারী একটি নির্বাচন করে, তাহলে প্রমিসটি একটি PasswordCredential অবজেক্টের সাথে রিজলভ হয় যাতে id (ইউজারনেম) এবং password থাকে। আপনার অ্যাপ্লিকেশন তখন এই তথ্য সার্ভারে পাঠাতে পারে প্রমাণীকরণ প্রক্রিয়াটি সম্পূর্ণ করার জন্য।

বাস্তব প্রয়োগ: `navigator.credentials.store()` ব্যবহার করে ক্রেডেনশিয়াল সংরক্ষণ করা

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

            async function handleSuccessfulSignUp(username, password) {
  try {
    // Create a new PasswordCredential object
    const newCredential = new PasswordCredential({
      id: username,
      password: password,
      name: 'User display name' // Optional: for the account chooser
    });

    // Store the credential
    await navigator.credentials.store(newCredential);
    console.log('Credential stored successfully!');

    // Proceed to redirect the user or update the UI
    window.location.href = '/welcome';
  } catch (err) {
    console.error('Error storing credential:', err);
  }
}

            

              
                Copy
              
            
          

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

পরবর্তী দিগন্ত: WebAuthn এবং পাসকি-এর মাধ্যমে পাসওয়ার্ডবিহীন প্রমাণীকরণ

যদিও ক্রেডেনশিয়াল ম্যানেজমেন্ট এপিআই পাসওয়ার্ডের অভিজ্ঞতাকে নাটকীয়ভাবে উন্নত করে, অনেকের জন্য চূড়ান্ত লক্ষ্য হল পাসওয়ার্ড সম্পূর্ণরূপে নির্মূল করা। এখানেই Web Authentication API (WebAuthn) আসে। WebAuthn একটি W3C স্ট্যান্ডার্ড যা পাবলিক-কি ক্রিপ্টোগ্রাফি ব্যবহার করে পাসওয়ার্ডবিহীন, ফিশিং-প্রতিরোধী প্রমাণীকরণ সক্ষম করে।

আপনি হয়তো সম্প্রতি পাসকি (Passkeys) শব্দটি শুনেছেন। পাসকি হল WebAuthn-এর পেছনের স্ট্যান্ডার্ডের ব্যবহারকারী-বান্ধব বাস্তবায়ন। একটি পাসকি হল একটি ডিজিটাল ক্রেডেনশিয়াল যা ব্যবহারকারীর ডিভাইসে (যেমন একটি ফোন, কম্পিউটার, বা হার্ডওয়্যার নিরাপত্তা কী) সংরক্ষণ করা হয়। এটি পাসওয়ার্ড ছাড়াই ওয়েবসাইট এবং অ্যাপে সাইন ইন করতে ব্যবহৃত হয়। এগুলি প্রায়শই ক্লাউড পরিষেবাগুলির (যেমন iCloud Keychain বা Google Password Manager) মাধ্যমে ব্যবহারকারীর ডিভাইসগুলিতে সিঙ্ক্রোনাইজ করা হয়, যা এগুলিকে অবিশ্বাস্যভাবে সুবিধাজনক করে তোলে।

WebAuthn কেন একটি নিরাপত্তা গেম-চেঞ্জার

• ফিশিং-প্রতিরোধী: একটি পাসকি ক্রিপ্টোগ্রাফিকভাবে ওয়েবসাইটের অরিজিনের সাথে আবদ্ধ থাকে যেখানে এটি তৈরি হয়েছিল। এর মানে হল my-bank.com-এর জন্য তৈরি একটি পাসকি my-bank-login.com-এর মতো একটি ফিশিং সাইটে লগ ইন করতে ব্যবহার করা যাবে না। ব্রাউজার সহজভাবে এটি অনুমতি দেবে না।
• কোনো শেয়ার্ড সিক্রেট নেই: WebAuthn-এর সাথে, ব্যবহারকারীর ডিভাইস একটি পাবলিক/প্রাইভেট কী পেয়ার তৈরি করে। প্রাইভেট কী ব্যবহারকারীর সুরক্ষিত ডিভাইস (অথেন্টিকেটর) থেকে কখনও বের হয় না। শুধুমাত্র পাবলিক কী সার্ভারে পাঠানো হয়। এমনকি যদি আপনার সার্ভারের ডাটাবেস লঙ্ঘন হয়, আক্রমণকারীরা চুরি করার জন্য কোনো পাসওয়ার্ড খুঁজে পাবে না।
• শক্তিশালী মাল্টি-ফ্যাক্টর অথেন্টিকেশন: একটি পাসকি সহজাতভাবে ব্যবহারকারীর কাছে যা আছে (প্রাইভেট কী সহ ডিভাইস) এবং ব্যবহারকারী কে (তার ফিঙ্গারপ্রিন্ট/মুখ) বা যা জানে (তার ডিভাইস পিন) তা একত্রিত করে। এটি প্রায়শই একটি সহজ ধাপে MFA প্রয়োজনীয়তা পূরণ করে।

ক্রেডেনশিয়াল ম্যানেজমেন্ট এপিআই-এর মাধ্যমে WebAuthn ফ্লো

WebAuthn এছাড়াও navigator.credentials অবজেক্টের মাধ্যমে পরিচালিত হয়, PublicKeyCredential টাইপ ব্যবহার করে। প্রক্রিয়াটিতে দুটি প্রধান পর্যায় জড়িত: রেজিস্ট্রেশন এবং প্রমাণীকরণ।

১. রেজিস্ট্রেশন (একটি পাসকি তৈরি করা)

এটি একটি সরলীকৃত ওভারভিউ। প্রকৃত বাস্তবায়নের জন্য ক্রিপ্টোগ্রাফিক চ্যালেঞ্জগুলির যত্নশীল সার্ভার-সাইড হ্যান্ডলিং প্রয়োজন।

1. ক্লায়েন্টের রেজিস্ট্রেশনের অনুরোধ: ব্যবহারকারী জানায় যে তারা একটি পাসকি তৈরি করতে চায়।
2. সার্ভারের চ্যালেঞ্জ পাঠানো: আপনার সার্ভার একটি অনন্য, র‍্যান্ডম চ্যালেঞ্জ এবং কিছু কনফিগারেশন অপশন (একটি publicKeyCreationOptions অবজেক্ট) তৈরি করে।
3. ক্লায়েন্টের `navigator.credentials.create()` কল: আপনার ফ্রন্টএন্ড কোড সার্ভার থেকে প্রাপ্ত অপশনগুলি এই পদ্ধতিতে পাস করে।

            const creationOptions = await fetch('/api/webauthn/register-options').then(r => r.json());

// Important: The server-generated challenge must be decoded from Base64URL to a BufferSource
creationOptions.challenge = bufferDecode(creationOptions.challenge);
creationOptions.user.id = bufferDecode(creationations.user.id);

const credential = await navigator.credentials.create({ publicKey: creationOptions });

            

              
                Copy
              
            
          

4. ব্যবহারকারীর অনুমোদন: ব্রাউজার/ওএস ব্যবহারকারীকে তার ডিভাইসের অথেন্টিকেটর (যেমন, ফেস আইডি, উইন্ডোজ হ্যালো, বা একটি ফিঙ্গারপ্রিন্ট স্ক্যান) ব্যবহার করে একটি পাসকি তৈরি করার জন্য অনুরোধ করে। অথেন্টিকেটর একটি নতুন পাবলিক/প্রাইভেট কী পেয়ার তৈরি করে।
5. ক্লায়েন্টের পাবলিক কী সার্ভারে পাঠানো: ফলস্বরূপ ক্রেডেনশিয়াল, যার মধ্যে নতুন পাবলিক কী এবং একটি স্বাক্ষরিত অ্যাটেস্টেশন রয়েছে, তা যাচাই এবং সংরক্ষণের জন্য আপনার সার্ভারে ফেরত পাঠানো হয়।

২. প্রমাণীকরণ (পাসকি দিয়ে সাইন ইন করা)

1. ক্লায়েন্টের সাইন ইন করার অনুরোধ: ব্যবহারকারী তার পাসকি দিয়ে সাইন ইন করতে চায়।
2. সার্ভারের চ্যালেঞ্জ পাঠানো: আপনার সার্ভার একটি নতুন র‍্যান্ডম চ্যালেঞ্জ তৈরি করে এবং এটি ক্লায়েন্টকে পাঠায় (একটি publicKeyRequestOptions অবজেক্টের মধ্যে)।
3. ক্লায়েন্টের `navigator.credentials.get()` কল: এবার, আপনি `publicKey` অপশনটি ব্যবহার করেন।

            const requestOptions = await fetch('/api/webauthn/login-options').then(r => r.json());
requestOptions.challenge = bufferDecode(requestOptions.challenge);

const credential = await navigator.credentials.get({ publicKey: requestOptions });

            

              
                Copy
              
            
          

4. ব্যবহারকারীর অনুমোদন: ব্যবহারকারী তার ডিভাইস দিয়ে প্রমাণীকরণ করে। ডিভাইসের অথেন্টিকেটর সার্ভার থেকে আসা চ্যালেঞ্জে স্বাক্ষর করার জন্য সংরক্ষিত প্রাইভেট কী ব্যবহার করে।
5. ক্লায়েন্টের অ্যাসারশন সার্ভারে পাঠানো: স্বাক্ষরিত চ্যালেঞ্জ (যাকে অ্যাসারশন বলা হয়) আপনার সার্ভারে ফেরত পাঠানো হয়। সার্ভার সংরক্ষিত পাবলিক কী ব্যবহার করে স্বাক্ষর যাচাই করে। যদি এটি বৈধ হয়, ব্যবহারকারী লগ ইন হয়ে যায়।

দ্রষ্টব্য: র WebAuthn এপিআই-তে বিশেষ করে ডেটা এনকোডিং/ডিকোডিং (যেমন ArrayBuffers এবং Base64URL) এর ক্ষেত্রে যথেষ্ট জটিলতা জড়িত। ক্লায়েন্ট এবং সার্ভার উভয় দিকেই নিম্ন-স্তরের বিবরণ পরিচালনা করার জন্য SimpleWebAuthn-এর মতো একটি পরীক্ষিত লাইব্রেরি বা একটি পরিষেবা প্রদানকারী ব্যবহার করার জন্য অত্যন্ত সুপারিশ করা হয়।

গোপনীয়তা-প্রথম লগইন: ফেডারেটেড ক্রেডেনশিয়াল ম্যানেজমেন্ট (FedCM)

বছরের পর বছর ধরে, "গুগল/ফেসবুক/গিটহাব দিয়ে সাইন ইন করুন" সাইন-আপের ঘর্ষণ কমানোর একটি জনপ্রিয় উপায়। এই মডেলটিকে ফেডারেটেড আইডেন্টিটি বলা হয়। ঐতিহাসিকভাবে, এটি সাইট জুড়ে লগইন স্ট্যাটাস ট্র্যাক করার জন্য রিডাইরেক্ট, পপ-আপ এবং থার্ড-পার্টি কুকিজের মতো পদ্ধতির উপর ব্যাপকভাবে নির্ভর করত। যেহেতু ব্রাউজারগুলি ব্যবহারকারীর গোপনীয়তা বাড়ানোর জন্য থার্ড-পার্টি কুকিজ পর্যায়ক্রমে বন্ধ করার দিকে এগোচ্ছে, এই ঐতিহ্যবাহী ফ্লো গুলি ভেঙে যাওয়ার ঝুঁকিতে রয়েছে।

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

FedCM-এর মূল লক্ষ্য

• ফেডারেটেড লগইন সংরক্ষণ: ব্যবহারকারীদের তাদের পছন্দের আইডেন্টিটি প্রোভাইডার (IdPs) ব্যবহার করে রিলিইং পার্টিতে (RPs, আপনার ওয়েবসাইট) সহজে লগ ইন করা চালিয়ে যাওয়ার অনুমতি দেওয়া।
• গোপনীয়তা বৃদ্ধি: IdP-দের তাদের সুস্পষ্ট সম্মতি ছাড়া ওয়েব জুড়ে ব্যবহারকারীদের প্যাসিভভাবে ট্র্যাক করা থেকে বিরত রাখা।
• ব্যবহারকারীর অভিজ্ঞতা এবং নিরাপত্তা উন্নত করা: ফেডারেটেড লগইনের জন্য একটি ব্রাউজার-মধ্যস্থিত, মানসম্মত UI প্রদান করা, যা ব্যবহারকারীদের কী ডেটা শেয়ার করা হচ্ছে তার উপর আরও স্বচ্ছতা এবং নিয়ন্ত্রণ দেয়। এটি UI-ভিত্তিক ফিশিং আক্রমণ প্রতিরোধেও সহায়তা করে।

FedCM কিভাবে কাজ করে (উচ্চ-স্তর)

FedCM-এর সাথে, ব্রাউজার নিজেই লগইন ফ্লো পরিচালনা করে, আপনার সাইট (RP) এবং আইডেন্টিটি প্রোভাইডার (IdP) এর মধ্যে একটি বিশ্বস্ত মধ্যস্থতাকারী হিসেবে কাজ করে।

1. RP একটি ক্রেডেনশিয়াল অনুরোধ করে: আপনার ওয়েবসাইট navigator.credentials.get() কল করে, এবার একটি federated প্রোভাইডার নির্দিষ্ট করে।

            async function handleFedCMLogin() {
  try {
    const cred = await navigator.credentials.get({
      federated: {
        providers: ['https://accounts.google.com', 'https://facebook.com'], // Example IdPs
        // The browser will look for a well-known manifest file on these domains
      }
    });

    // If successful, the credential object contains a token
    if (cred) {
      console.log('Received token:', cred.token);
      // Send the token to your server for validation and login
      await serverLoginWithToken(cred.token, cred.provider);
    }
  } catch (err) {
    console.error('FedCM Error:', err);
  }
}

            

              
                Copy
              
            
          

2. ব্রাউজার ম্যানিফেস্ট নিয়ে আসে: ব্রাউজার IdP-এর ডোমেনে একটি /.well-known/web-identity ফাইলে স্যান্ডবক্সড অনুরোধ করে। এই ফাইলটি ব্রাউজারকে জানায় যে অ্যাকাউন্ট তালিকা আনা এবং টোকেন ইস্যু করার জন্য প্রয়োজনীয় এন্ডপয়েন্টগুলি কোথায় পাওয়া যাবে।
3. ব্রাউজার একটি অ্যাকাউন্ট চয়নকারী প্রদর্শন করে: যদি ব্যবহারকারী IdP-তে লগ ইন করা থাকে, ব্রাউজার তার নিজস্ব নেটিভ UI (যেমন, স্ক্রিনের উপরের-ডান কোণে একটি ড্রপডাউন) প্রদর্শন করে যা ব্যবহারকারীর উপলব্ধ অ্যাকাউন্টগুলি দেখায়। RP-এর পৃষ্ঠার বিষয়বস্তু কখনও অস্পষ্ট হয় না।
4. ব্যবহারকারী সম্মতি দেয়: ব্যবহারকারী একটি অ্যাকাউন্ট নির্বাচন করে এবং সাইন ইন করতে সম্মতি দেয়।
5. ব্রাউজার একটি টোকেন নিয়ে আসে: ব্রাউজার একটি আইডি টোকেন পেতে IdP-এর টোকেন এন্ডপয়েন্টে একটি চূড়ান্ত অনুরোধ করে।
6. RP টোকেনটি গ্রহণ করে: get() থেকে প্রমিসটি রিজলভ হয়, টোকেন ধারণকারী একটি FederatedCredential অবজেক্ট ফেরত দেয়। আপনার ওয়েবসাইট এই টোকেনটি আপনার ব্যাকএন্ডে পাঠায়, যা ব্যবহারকারীর জন্য একটি সেশন তৈরি করার আগে IdP-এর সাথে এটি যাচাই করতে হবে।

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

একটি একীভূত কৌশল: প্রমাণীকরণের জন্য প্রগতিশীল উন্নতি

তিনটি ভিন্ন ধরণের ক্রেডেনশিয়াল উপলব্ধ থাকায়, আপনার ফ্রন্টএন্ড কোডটি কীভাবে গঠন করা উচিত? সেরা পদ্ধতি হল প্রগতিশীল উন্নতি (progressive enhancement)। আপনার লক্ষ্য হওয়া উচিত সবচেয়ে আধুনিক, সুরক্ষিত অভিজ্ঞতা প্রদান করা, প্রয়োজনে পুরানো পদ্ধতিতে সুন্দরভাবে ফলব্যাক করা।

ক্রেডেনশিয়াল ম্যানেজমেন্ট এপিআই এর জন্য ডিজাইন করা হয়েছে। আপনি একটি একক get() কলে সমস্ত সমর্থিত ক্রেডেনশিয়াল প্রকারের অনুরোধ করতে পারেন, এবং ব্রাউজার ব্যবহারকারীর কাছে সেরা বিকল্পটিকে অগ্রাধিকার দেবে এবং উপস্থাপন করবে।

প্রস্তাবিত প্রমাণীকরণ ফ্লো

1. পাসকি-কে অগ্রাধিকার দিন (যদি উপলব্ধ থাকে): সবচেয়ে সুরক্ষিত এবং নির্বিঘ্ন অভিজ্ঞতার জন্য, প্রথমে ব্যবহারকারীর একটি পাসকি আছে কিনা তা পরীক্ষা করুন। আপনি শর্তসাপেক্ষে একটি "পাসকি দিয়ে সাইন ইন করুন" বোতাম দেখানোর জন্য ফিচার সনাক্তকরণের জন্য PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() ব্যবহার করতে পারেন।
2. একটি একীভূত `get()` কল ব্যবহার করুন: navigator.credentials.get()-এ একটি একক কল করুন যাতে publicKey, password, এবং সম্ভাব্যত federated-এর জন্য অপশন অন্তর্ভুক্ত থাকে। ব্রাউজার এই বিষয়ে স্মার্ট; উদাহরণস্বরূপ, যদি একটি পাসকি উপলব্ধ এবং পছন্দসই হয় তবে এটি একটি পাসওয়ার্ড প্রম্পট দেখাবে না।
3. ফেরত আসা ক্রেডেনশিয়ালটি হ্যান্ডেল করুন: instanceof ব্যবহার করে ফেরত আসা ক্রেডেনশিয়াল অবজেক্টের প্রকারটি পরীক্ষা করুন এবং সেই অনুযায়ী এটি প্রক্রিয়া করুন।
4. সুন্দর ফলব্যাক: যদি ব্যবহারকারী প্রম্পটটি বাতিল করে বা এপিআই কলটি কোনো কারণে ব্যর্থ হয় (যেমন, একটি অসমর্থিত ব্রাউজারে), তবে এবং কেবল তখনই আপনার সম্পূর্ণ, ঐতিহ্যবাহী ইউজারনেম/পাসওয়ার্ড ফর্মটি প্রদর্শন করা উচিত।

উদাহরণ: একটি একীভূত `get()` কল

            async function unifiedSignIn() {
  try {
    // Note: These `publicKey` and `federated` options would come from your server
    const publicKeyOptions = await fetch('/api/webauthn/login-options').then(r => r.json());
    // ... (buffer decoding logic here) ...

    const cred = await navigator.credentials.get({
      password: true,
      publicKey: publicKeyOptions,
      federated: {
        providers: ['https://idp.example.com']
      },
      // 'optional' prevents an error if the user has no credentials
      mediation: 'optional' 
    });

    if (!cred) {
      console.log('User cancelled or no credentials. Showing form.');
      showTraditionalLoginForm();
      return;
    }

    // Handle the credential based on its type
    if (cred instanceof PasswordCredential) {
      console.log('Handling password credential...');
      await serverLogin(cred.id, cred.password);
    } else if (cred instanceof PublicKeyCredential) {
      console.log('Handling PublicKeyCredential (Passkey)...');
      await serverLoginWithPasskey(cred);
    } else if (cred instanceof FederatedCredential) {
      console.log('Handling FederatedCredential (FedCM)...');
      await serverLoginWithToken(cred.token, cred.provider);
    }

  } catch (err) {
    console.error('Unified sign-in error:', err);
    showTraditionalLoginForm(); // Fallback on any error
  }
}

            

              
                Copy
              
            
          

বিশ্বব্যাপী বিবেচনা এবং সেরা অনুশীলন

বিশ্বব্যাপী দর্শকদের জন্য এই আধুনিক প্রমাণীকরণ ফ্লো গুলি প্রয়োগ করার সময়, নিম্নলিখিত বিষয়গুলি মনে রাখবেন:

• ব্রাউজার সাপোর্ট: সর্বদা caniuse.com-এর মতো সাইটে প্রতিটি এপিআই-এর জন্য ব্রাউজার সামঞ্জস্যতা পরীক্ষা করুন। পুরানো ব্রাউজার ব্যবহারকারীদের জন্য শক্তিশালী ফলব্যাক সরবরাহ করুন যাতে কেউ লক আউট না হয়।
• সার্ভার-সাইড ভ্যালিডেশন অপরিহার্য: ফ্রন্টএন্ড একটি অবিশ্বস্ত পরিবেশ। ক্লায়েন্ট থেকে প্রাপ্ত সমস্ত ক্রেডেনশিয়াল, টোকেন এবং অ্যাসারশন একটি সেশন তৈরি করার আগে সার্ভারে কঠোরভাবে যাচাই করা আবশ্যক। এই এপিআইগুলি ফ্রন্টএন্ড UX উন্নত করে; তারা ব্যাকএন্ড নিরাপত্তাকে প্রতিস্থাপন করে না।
• ব্যবহারকারী শিক্ষা: পাসকি-এর মতো ধারণাগুলি অনেক ব্যবহারকারীর কাছে নতুন। স্পষ্ট, সহজ ভাষা ব্যবহার করুন। ব্যবহারকারীদের প্রক্রিয়াটির মাধ্যমে গাইড করতে এবং বিশ্বাস তৈরি করতে টুলটিপ বা সংক্ষিপ্ত ব্যাখ্যার লিঙ্ক যুক্ত করার কথা বিবেচনা করুন (যেমন, "পাসকি কী?")।
• আন্তর্জাতিকীকরণ (i18n): যদিও ব্রাউজার-নেটিভ UI গুলি সাধারণত ব্রাউজার ভেন্ডর দ্বারা স্থানীয়করণ করা হয়, আপনার যোগ করা যেকোনো কাস্টম টেক্সট, ত্রুটি বার্তা, বা নির্দেশাবলী অবশ্যই আপনার টার্গেট দর্শকদের জন্য সঠিকভাবে অনুবাদ করতে হবে।
• অ্যাক্সেসিবিলিটি (a11y): আপনি যদি এই ফ্লো গুলি ট্রিগার করার জন্য কাস্টম UI উপাদান তৈরি করেন (যেমন কাস্টম বোতাম), তবে নিশ্চিত করুন যে সেগুলি সম্পূর্ণ অ্যাক্সেসিবল, সঠিক ARIA অ্যাট্রিবিউট, ফোকাস স্টেট এবং কীবোর্ড নেভিগেশন সমর্থন সহ।

উপসংহার: ভবিষ্যৎ এখন

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

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