Firebase Authentication ইউজার অবজেক্টটি এমন একটি ইউজার অ্যাকাউন্টকে প্রতিনিধিত্ব করে, যেটি আপনার প্রোজেক্টের কোনো একটি অ্যাপে সাইন আপ করেছে। অ্যাপগুলোতে সাধারণত অনেক নিবন্ধিত ব্যবহারকারী থাকে এবং একটি প্রোজেক্টের প্রতিটি অ্যাপ একটি ইউজার ডেটাবেস শেয়ার করে।
ইউজার ইনস্ট্যান্সগুলো Firebase Authentication ইনস্ট্যান্স থেকে স্বাধীন, তাই আপনি একই কনটেক্সটের মধ্যে বিভিন্ন ইউজারের একাধিক রেফারেন্স রাখতে পারেন এবং তারপরেও তাদের যেকোনো মেথড কল করতে পারেন।
ব্যবহারকারীর বৈশিষ্ট্য
Authentication ব্যবহারকারীদের কিছু নির্দিষ্ট মৌলিক বৈশিষ্ট্য থাকে—একটি অনন্য আইডি, একটি প্রাথমিক ইমেল ঠিকানা, একটি নাম এবং একটি ছবির ইউআরএল—যা প্রোজেক্টের ব্যবহারকারী ডেটাবেসে সংরক্ষিত থাকে এবং ব্যবহারকারী ( iOS , Android , web ) তা আপডেট করতে পারেন। আপনি সরাসরি ইউজার অবজেক্টে অন্য কোনো বৈশিষ্ট্য যোগ করতে পারবেন না; এর পরিবর্তে, আপনি অতিরিক্ত বৈশিষ্ট্যগুলো গুগল ক্লাউড ফায়ারস্টোরের মতো অন্য যেকোনো স্টোরেজ সার্ভিসে সংরক্ষণ করতে পারেন।
যখন কোনো ব্যবহারকারী প্রথমবার আপনার অ্যাপে সাইন আপ করেন, তখন উপলব্ধ তথ্য ব্যবহার করে ব্যবহারকারীর প্রোফাইল ডেটা পূরণ করা হয়:
- যদি ব্যবহারকারী ইমেল ঠিকানা এবং পাসওয়ার্ড দিয়ে সাইন আপ করে থাকেন, তাহলে শুধুমাত্র প্রাথমিক ইমেল ঠিকানা প্রপার্টিটি পূরণ করা হয়।
- যদি ব্যবহারকারী গুগল বা ফেসবুকের মতো কোনো ফেডারেটেড আইডেন্টিটি প্রোভাইডারের মাধ্যমে সাইন আপ করে থাকেন, তাহলে সেই প্রোভাইডারের দেওয়া অ্যাকাউন্টের তথ্য ব্যবহারকারীর প্রোফাইল পূরণ করতে ব্যবহৃত হয়।
- যদি ব্যবহারকারী আপনার নিজস্ব প্রমাণীকরণ সিস্টেম ব্যবহার করে সাইন আপ করে থাকেন, তাহলে আপনাকে অবশ্যই ব্যবহারকারীর প্রোফাইলে আপনার প্রয়োজনীয় তথ্যগুলো স্পষ্টভাবে যোগ করতে হবে।
একবার ব্যবহারকারী অ্যাকাউন্ট তৈরি হয়ে গেলে, ব্যবহারকারী অন্য কোনো ডিভাইসে যে পরিবর্তনগুলো করে থাকতে পারেন, সেগুলো অন্তর্ভুক্ত করার জন্য আপনি তার তথ্য পুনরায় লোড করতে পারেন।
সাইন-ইন প্রদানকারী
আপনি বিভিন্ন পদ্ধতি ব্যবহার করে আপনার অ্যাপে ব্যবহারকারীদের সাইন ইন করাতে পারেন: ইমেল ঠিকানা ও পাসওয়ার্ড, ফেডারেটেড আইডেন্টিটি প্রোভাইডার এবং আপনার নিজস্ব অথেন্টিকেশন সিস্টেম। আপনি একজন ব্যবহারকারীর সাথে একাধিক সাইন-ইন পদ্ধতি যুক্ত করতে পারেন: উদাহরণস্বরূপ, একজন ব্যবহারকারী একই অ্যাকাউন্টে ইমেল ঠিকানা ও পাসওয়ার্ড ব্যবহার করে অথবা গুগল সাইন-ইন ব্যবহার করে সাইন ইন করতে পারেন।
ইউজার ইনস্ট্যান্সগুলো ব্যবহারকারীর সাথে লিঙ্কযুক্ত প্রতিটি প্রোভাইডারের হিসাব রাখে। এটি আপনাকে কোনো প্রোভাইডারের দেওয়া তথ্য ব্যবহার করে খালি প্রোফাইলের বৈশিষ্ট্যগুলো আপডেট করার সুযোগ দেয়। ব্যবহারকারী ব্যবস্থাপনা ( iOS , Android , web ) দেখুন।
বর্তমান ব্যবহারকারী
যখন কোনো ব্যবহারকারী সাইন আপ বা সাইন ইন করেন, তখন সেই ব্যবহারকারী Auth ইনস্ট্যান্সটির বর্তমান ব্যবহারকারী হয়ে যান। ইনস্ট্যান্সটি ব্যবহারকারীর অবস্থা সংরক্ষণ করে, ফলে (ব্রাউজারে) পৃষ্ঠাটি রিফ্রেশ করলে বা অ্যাপ্লিকেশনটি পুনরায় চালু করলেও ব্যবহারকারীর তথ্য হারিয়ে যায় না।
যখন ব্যবহারকারী সাইন আউট করেন, তখন Auth ইনস্ট্যান্সটি user অবজেক্টের রেফারেন্স রাখা বন্ধ করে দেয় এবং এর অবস্থা আর ধরে রাখে না; তখন কোনো বর্তমান ব্যবহারকারী থাকে না। তবে, user ইনস্ট্যান্সটি সম্পূর্ণ কার্যকরী থাকে: যদি আপনি এটির একটি রেফারেন্স রাখেন, তাহলে আপনি তখনও ব্যবহারকারীর ডেটা অ্যাক্সেস এবং আপডেট করতে পারবেন।
ব্যবহারকারীর জীবনচক্র
Auth ইনস্ট্যান্সের বর্তমান অবস্থা ট্র্যাক করার জন্য প্রস্তাবিত উপায় হলো লিসেনার (জাভাস্ক্রিপ্টে যাকে "অবজারভার"ও বলা হয়) ব্যবহার করা। যখনই Auth অবজেক্টে প্রাসঙ্গিক কিছু ঘটে, তখনই একটি Auth লিসেনার অবহিত হয়। ব্যবহারকারী ব্যবস্থাপনা ( iOS , Android , web ) দেখুন।
নিম্নলিখিত পরিস্থিতিগুলিতে একটি অথেন্টিকেশন লিসেনারকে অবহিত করা হয়:
- Auth অবজেক্টটির ইনিশিয়ালাইজেশন সম্পন্ন হয়েছে এবং একজন ব্যবহারকারী পূর্ববর্তী সেশন থেকে ইতিমধ্যেই সাইন ইন করা ছিলেন, অথবা কোনো আইডেন্টিটি প্রোভাইডারের সাইন-ইন ফ্লো থেকে তাকে রিডাইরেক্ট করা হয়েছে।
- একজন ব্যবহারকারী সাইন ইন করেন (বর্তমান ব্যবহারকারী সেট করা আছে)।
- একজন ব্যবহারকারী সাইন আউট করলে (বর্তমান ব্যবহারকারী নাল হয়ে যায়)
- বর্তমান ব্যবহারকারীর অ্যাক্সেস টোকেন রিফ্রেশ করা হয়। নিম্নলিখিত পরিস্থিতিতে এটি ঘটতে পারে:
- অ্যাক্সেস টোকেনের মেয়াদ শেষ হয়ে যায়: এটি একটি সাধারণ পরিস্থিতি। নতুন ও বৈধ টোকেন সেট পেতে রিফ্রেশ টোকেন ব্যবহার করা হয়।
- ব্যবহারকারী তার পাসওয়ার্ড পরিবর্তন করলে, Authentication নতুন অ্যাক্সেস ও রিফ্রেশ টোকেন প্রদান করে এবং পুরোনো টোকেনগুলোকে মেয়াদোত্তীর্ণ করে দেয়। নিরাপত্তাজনিত কারণে, এটি স্বয়ংক্রিয়ভাবে ব্যবহারকারীর টোকেনের মেয়াদ শেষ করে দেয় এবং/অথবা প্রতিটি ডিভাইস থেকে তাকে সাইন আউট করে দেয়।
- ব্যবহারকারী পুনরায় প্রমাণীকরণ করেন: কিছু কাজের জন্য ব্যবহারকারীর ক্রেডেনশিয়াল সম্প্রতি ইস্যু করা প্রয়োজন; এই ধরনের কাজের মধ্যে রয়েছে অ্যাকাউন্ট ডিলিট করা, প্রাইমারি ইমেল অ্যাড্রেস সেট করা এবং পাসওয়ার্ড পরিবর্তন করা। ব্যবহারকারীকে সাইন আউট করে আবার সাইন ইন করানোর পরিবর্তে, ব্যবহারকারীর কাছ থেকে নতুন ক্রেডেনশিয়াল নিন এবং সেই নতুন ক্রেডেনশিয়ালগুলো user অবজেক্টের reauthenticate মেথডে পাস করুন।
ব্যবহারকারী স্ব-পরিষেবা
ডিফল্টরূপে, Firebase Authentication ব্যবহারকারীদের কোনো প্রশাসনিক হস্তক্ষেপ ছাড়াই তাদের অ্যাকাউন্ট সাইন-আপ এবং ডিলিট করার সুযোগ দেয়। অনেক ক্ষেত্রে, এটি ব্যবহারকারীদের আপনার অ্যাপ্লিকেশন বা পরিষেবা সম্পর্কে জানতে এবং ন্যূনতম বাধায় এতে যুক্ত (বা বিচ্ছিন্ন) হতে সাহায্য করে।
তবে, এমন পরিস্থিতিও রয়েছে যেখানে আপনি চান যে কোনো প্রশাসক অ্যাডমিন এসডিকে (Admin SDK) বা Firebase কনসোল (Firebase console) ব্যবহার করে ম্যানুয়ালি বা প্রোগ্রাম্যাটিকভাবে ব্যবহারকারী তৈরি করুক। এই ক্ষেত্রে, আপনি Firebase Authentication সেটিংস (Firebase Authentication Settings) পৃষ্ঠা থেকে ব্যবহারকারীর কার্যকলাপ নিষ্ক্রিয় (disable) করতে পারেন, যা সাধারণ ব্যবহারকারীদের অ্যাকাউন্ট তৈরি এবং মুছে ফেলা থেকে বিরত রাখে। আপনি যদি মাল্টি-টেনেন্সি (multi-tenancy) ব্যবহার করেন, তবে প্রতিটি টেন্যান্টের জন্য আলাদাভাবে এই বৈশিষ্ট্যগুলি নিষ্ক্রিয় করতে আপনাকে একটি HTTP অনুরোধ করতে হবে।
যদি কোনো ব্যবহারকারী আপনার সিস্টেমে একটি অ্যাকাউন্ট তৈরি বা মুছে ফেলার চেষ্টা করেন, তাহলে Firebase Authentication পরিষেবাটি একটি ত্রুটি কোড ফেরত দেবে: Web API কলের জন্য auth/admin-restricted-operation , অথবা Android এবং iOS-এর জন্য ERROR_ADMIN_RESTRICTED_OPERATION । আপনার ফ্রন্ট-এন্ডে ব্যবহারকারীকে আপনার পরিষেবার জন্য উপযুক্ত পদক্ষেপ নিতে বলে ত্রুটিটি সুন্দরভাবে সামাল দেওয়া উচিত।
প্রমাণীকরণ টোকেন
যখন আপনি Authentication ব্যবহার করে প্রমাণীকরণ সম্পন্ন করেন, তখন আপনি তিন ধরনের অথ টোকেনের সম্মুখীন হতে পারেন:
| Authentication আইডি টোকেন | যখন কোনো ব্যবহারকারী একটি অ্যাপে সাইন ইন করেন, তখন Authentication দ্বারা এটি তৈরি হয়। এই টোকেনগুলো হলো স্বাক্ষরিত JWT, যা একটি Firebase প্রোজেক্টে একজন ব্যবহারকারীকে নিরাপদে শনাক্ত করে। এই টোকেনগুলোতে একজন ব্যবহারকারীর প্রাথমিক প্রোফাইল তথ্য থাকে, যার মধ্যে ব্যবহারকারীর আইডি স্ট্রিংও অন্তর্ভুক্ত, যা Firebase প্রোজেক্টটির জন্য অনন্য। যেহেতু আইডি টোকেনগুলোর অখণ্ডতা যাচাই করা যায় , তাই বর্তমানে সাইন-ইন করা ব্যবহারকারীকে শনাক্ত করার জন্য আপনি এগুলো একটি ব্যাকএন্ড সার্ভারে পাঠাতে পারেন। |
| পরিচয় প্রদানকারী টোকেন | গুগল এবং ফেসবুকের মতো ফেডারেটেড আইডেন্টিটি প্রোভাইডারদের দ্বারা তৈরি। এই টোকেনগুলোর বিভিন্ন ফরম্যাট থাকতে পারে, তবে এগুলো প্রায়শই OAuth 2.0 অ্যাক্সেস টোকেন হয়ে থাকে। অ্যাপগুলো এই টোকেনগুলো ব্যবহার করে যাচাই করে যে ব্যবহারকারীরা আইডেন্টিটি প্রোভাইডারের কাছে সফলভাবে প্রমাণীকৃত হয়েছেন কিনা, এবং তারপর সেগুলোকে Authentication সার্ভিস দ্বারা ব্যবহারযোগ্য ক্রেডেনশিয়ালে রূপান্তরিত করে। |
| Authentication কাস্টম টোকেন | আপনার কাস্টম অথেন্টিকেশন সিস্টেম ব্যবহারকারীদের সেই সিস্টেম ব্যবহার করে কোনো অ্যাপে সাইন ইন করার সুযোগ দেওয়ার জন্য এটি তৈরি করে। কাস্টম টোকেন হলো একটি সার্ভিস অ্যাকাউন্টের প্রাইভেট কী ব্যবহার করে স্বাক্ষরিত JWT। অ্যাপগুলো এই টোকেনগুলো ঠিক সেভাবেই ব্যবহার করে, যেভাবে তারা ফেডারেটেড আইডেন্টিটি প্রোভাইডারদের থেকে পাওয়া টোকেনগুলো ব্যবহার করে। |
যাচাইকৃত ইমেল ঠিকানা
Authentication একটি ইমেলকে যাচাইকৃত বলে বিবেচনা করে, যদি এটি দুটি শর্ত পূরণ করে:
- ব্যবহারকারী Authentication যাচাইকরণ প্রক্রিয়াটি সম্পন্ন করেন।
- ইমেলটি একটি বিশ্বস্ত আইডেন্টিটি প্রোভাইডার বা সংক্ষেপে IdP দ্বারা যাচাই করা হয়।
যেসব IdP একবার ইমেল যাচাই করে, কিন্তু তারপর পুনরায় যাচাইকরণের প্রয়োজন ছাড়াই ব্যবহারকারীদের ইমেল ঠিকানা পরিবর্তন করার অনুমতি দেয়, সেগুলো বিশ্বস্ত নয়। যেসব IdP হয় ডোমেইনের মালিক অথবা সর্বদা যাচাইকরণের প্রয়োজন রাখে, সেগুলোকে বিশ্বস্ত বলে গণ্য করা হয়।
বিশ্বস্ত পরিষেবা প্রদানকারী:
- গুগল (@gmail.com ঠিকানার জন্য)
- ইয়াহু ( @yahoo.com ঠিকানার জন্য)
- মাইক্রোসফট ( @outlook.com এবং @hotmail.com অ্যাড্রেসগুলোর জন্য)
- অ্যাপল (সর্বদা যাচাইকৃত, কারণ অ্যাকাউন্টগুলো সর্বদা যাচাইকৃত এবং মাল্টি-ফ্যাক্টর-অথেনটিকেটেড থাকে)
অবিশ্বস্ত সরবরাহকারী:
- ফেসবুক
- টুইটার
- গিটহাব
- যে আইডেন্টিটি প্রোভাইডার দ্বারা ডোমেইনগুলো ইস্যু করা হয়নি, সেগুলোর জন্য গুগল, ইয়াহু এবং মাইক্রোসফট।
- ইমেল যাচাইকরণ ছাড়া ইমেল / পাসওয়ার্ড
কিছু ক্ষেত্রে, যখন কোনো ব্যবহারকারী একই ইমেল ঠিকানা ব্যবহার করে বিভিন্ন প্রোভাইডারের মাধ্যমে সাইন ইন করেন, তখন Authentication স্বয়ংক্রিয়ভাবে অ্যাকাউন্টগুলো লিঙ্ক করে দেয়। তবে, এটি কেবল তখনই ঘটতে পারে যখন নির্দিষ্ট কিছু শর্ত পূরণ হয়। এর কারণ বোঝার জন্য, নিম্নলিখিত পরিস্থিতিটি বিবেচনা করুন: একজন ব্যবহারকারী একটি @gmail.com অ্যাকাউন্ট দিয়ে গুগলে সাইন ইন করেন এবং একজন ক্ষতিকারক ব্যক্তি একই @gmail.com ঠিকানা ব্যবহার করে একটি অ্যাকাউন্ট তৈরি করে, কিন্তু ফেসবুকের মাধ্যমে সাইন ইন করে। যদি এই দুটি অ্যাকাউন্ট স্বয়ংক্রিয়ভাবে লিঙ্ক হয়ে যেত, তাহলে ক্ষতিকারক ব্যক্তিটি ব্যবহারকারীর অ্যাকাউন্টে অ্যাক্সেস পেয়ে যেত।
নিম্নলিখিত ক্ষেত্রগুলিতে বর্ণনা করা হয়েছে কখন আমরা স্বয়ংক্রিয়ভাবে অ্যাকাউন্ট লিঙ্ক করি এবং কখন ব্যবহারকারী বা ডেভেলপারের পদক্ষেপের প্রয়োজন হয় এমন একটি ত্রুটি দেখাই:
- ব্যবহারকারী প্রথমে একটি অবিশ্বস্ত প্রোভাইডার দিয়ে সাইন ইন করেন, তারপর একই ইমেল ব্যবহার করে আরেকটি অবিশ্বস্ত প্রোভাইডার দিয়ে সাইন ইন করেন (উদাহরণস্বরূপ, প্রথমে ফেসবুক এবং তারপর গিটহাব)। এর ফলে একটি ত্রুটি দেখা দেয় এবং অ্যাকাউন্ট লিঙ্ক করার প্রয়োজন হয়।
- ব্যবহারকারী প্রথমে একটি বিশ্বস্ত প্রোভাইডার দিয়ে সাইন ইন করেন, তারপর একই ইমেল ব্যবহার করে একটি অবিশ্বস্ত প্রোভাইডার দিয়ে সাইন ইন করেন (উদাহরণস্বরূপ, প্রথমে গুগল এবং তারপর ফেসবুক)। এর ফলে একটি ত্রুটি দেখা দেয় এবং অ্যাকাউন্ট লিঙ্ক করার প্রয়োজন হয়।
- ব্যবহারকারী প্রথমে একটি অবিশ্বস্ত প্রোভাইডার দিয়ে সাইন ইন করেন, তারপর একই ইমেল ব্যবহার করে একটি বিশ্বস্ত প্রোভাইডার দিয়ে সাইন ইন করেন (উদাহরণস্বরূপ, প্রথমে ফেসবুক এবং তারপর গুগল)। বিশ্বস্ত প্রোভাইডারটি অবিশ্বস্ত প্রোভাইডারটিকে ওভাররাইট করে দেয়। যদি ব্যবহারকারী আবার ফেসবুক দিয়ে সাইন ইন করার চেষ্টা করেন, তাহলে একটি ত্রুটি দেখা দেবে এবং অ্যাকাউন্ট লিঙ্ক করার প্রয়োজন হবে।
- ব্যবহারকারী প্রথমে একটি বিশ্বস্ত প্রোভাইডার দিয়ে সাইন ইন করেন, তারপর একই ইমেল ব্যবহার করে অন্য একটি বিশ্বস্ত প্রোভাইডার দিয়ে সাইন ইন করেন (উদাহরণস্বরূপ, প্রথমে অ্যাপল এবং তারপর গুগল)। উভয় প্রোভাইডারই কোনো ত্রুটি ছাড়াই লিঙ্ক হয়ে যাবে।
আপনি অ্যাডমিন এসডিকে ব্যবহার করে ম্যানুয়ালি একটি ইমেলকে যাচাইকৃত হিসেবে সেট করতে পারেন, কিন্তু আমরা কেবল তখনই এটি করার পরামর্শ দিই, যখন আপনি নিশ্চিত হন যে ব্যবহারকারী সত্যিই ইমেলটির মালিক।