Authentication কী? লগইন, সেশন ও OAuth ব্যাখ্যা
Authentication হলো অ্যাপ কীভাবে নিশ্চিত করে ব্যবহারকারী কে — সাধারণত তারা যা জানে (একটি পাসওয়ার্ড) তা যাচাই করে, যা তাদের কাছে থাকে (তাদের ফোন বা ইমেইলে পাঠানো একটি কোড), বা অন্য একটি বিশ্বস্ত সার্ভিসের পরিচয় (যেমন “Google দিয়ে সাইন ইন”) দিয়ে। একবার ব্যবহারকারীর পরিচয় যাচাই হলে, অ্যাপ একটি সেশন বা টোকেন দিয়ে তাকে মনে রাখে, যাতে প্রতিটি পেজে আবার লগইন না করতে হয়। সেই পরিচিত ব্যবহারকারী কী করতে পারবেন তা ঠিক করা একটি আলাদা ধাপ, যাকে authorization বলে।
AI দিয়ে অ্যাপ বানালে এটি কেন গুরুত্বপূর্ণ
লগইন যোগ করা AI বিল্ডারের কাছে মানুষের সবচেয়ে সাধারণ অনুরোধগুলোর একটি, এবং ভুল করা সবচেয়ে সহজগুলোর একটি। একটি লগইন পেজ তৈরি করা সহজ। কঠিন অংশ হলো তার চারপাশের সবকিছু:
- পাসওয়ার্ড কি নিরাপদভাবে সংরক্ষিত হচ্ছে?
- প্রতিটি ব্যক্তিগত পেজ ও প্রতিটি API এন্ডপয়েন্ট কি সত্যিই যাচাই করে কে অনুরোধ করছে?
- লগইন করা একজন গ্রাহক কি URL-এর একটি সংখ্যা বদলে অন্য গ্রাহকের ডেটা দেখতে পারে?
- কেউ পাসওয়ার্ড ভুলে গেলে কী হয়?
একটি অ্যাপ এই প্রতিটি প্রশ্নে ব্যর্থ হয়েও দেখতে পুরোপুরি নিরাপদ মনে হতে পারে। কার্যকর অংশগুলো বুঝলে সঠিক প্রশ্ন করা ও সঠিক জিনিস পরীক্ষা করা সহজ হয়।
একটি দৈনন্দিন উপমা
হোটেলে চেক-ইন করার কথা ভাবুন।
ফ্রন্ট ডেস্কে আপনি পরিচয়পত্র দেখান। এটিই authentication: আপনি যে কে তা প্রমাণ করা। রিসেপশনিস্ট আপনাকে একটি কি-কার্ড দেন। সেই কার্ডই আপনার সেশন: থাকার বাকি সময় আপনাকে আর পরিচয়পত্র দেখাতে হয় না; শুধু কার্ড ট্যাপ করেন।
কার্ড আপনার রুম, জিম ও আপনার ফ্লোরের লিফট খোলে — কিন্তু অন্য অতিথিদের রুম বা স্টাফ অফিস খোলে না। এটিই authorization: আপনার পরিচয় কী কী অ্যাক্সেস পেতে পারে। কার্ড হারালে হোটেল ডেস্কে সেটি নিষ্ক্রিয় করতে পারে (সেশন বাতিল)। চেক-আউটের পর এটি কাজ করা বন্ধ করে (লগআউট বা মেয়াদ শেষ)।
“Google দিয়ে সাইন ইন” যেন একটি হোটেল বিশ্বস্ত অংশীদারের কাছ থেকে একটি চিঠি মেনে নিচ্ছে — “এই ব্যক্তি এই” — নিজে আপনার পরিচয়পত্র না দেখেই।
প্রধান লগইন পদ্ধতি
| পদ্ধতি | কীভাবে কাজ করে | সুবিধা | অসুবিধা |
|---|---|---|---|
| ইমেইল + পাসওয়ার্ড | ব্যবহারকারী একটি পাসওয়ার্ড বাছেন; অ্যাপ তার একটি hash সংরক্ষণ করে | পরিচিত, বাইরের নির্ভরতা নেই | হ্যাশ নিরাপদে সংরক্ষণ ও রিসেট সামলাতে হয় |
| ম্যাজিক লিংক / এক-বারের কোড | অ্যাপ একটি লিংক বা কোড ইমেইল করে, যা দিয়ে ব্যবহারকারী লগইন করে | চুরি বা ভুলে যাওয়ার মতো পাসওয়ার্ড নেই | ইমেইল ডেলিভারির ওপর নির্ভরশীল; লগইন কিছুটা ধীর |
| সোশ্যাল লগইন (OAuth / OpenID Connect) | ব্যবহারকারী Google, Apple, GitHub ইত্যাদি দিয়ে সাইন ইন করেন | ব্যবহারকারীর জন্য দ্রুত; আপনি পাসওয়ার্ড সংরক্ষণ করেন না | প্রতিটি প্রদানকারীর সাথে আলাদা সেটআপ; যাঁদের ওই অ্যাকাউন্ট নেই তাঁদের সমস্যা |
| হোস্টেড auth প্রোভাইডার | Clerk, Auth0 বা Supabase Auth-এর মতো একটি সার্ভিস সাইন-আপ, লগইন ও রিসেট সামলায় | আপনার নিরাপত্তার কাজ কম | স্কেলে মাসিক খরচ; আরেকটি নির্ভরতা |
| মাল্টি-ফ্যাক্টর (MFA / 2FA) | প্রথম যাচাইয়ের পর দ্বিতীয় একটি যাচাই, যেমন authenticator অ্যাপের কোড | ভাঙা অনেক কঠিন | একটু বাড়তি ঝামেলা |
পাসওয়ার্ড কীভাবে সংরক্ষণ করা উচিত
একটি নিরাপদ অ্যাপ কখনও আপনার আসল পাসওয়ার্ড সংরক্ষণ করে না। বরং এটি একটি hash রাখে: একটি একমুখী ফাংশনের আউটপুট, যা পাসওয়ার্ডকে একটি নির্দিষ্ট দৈর্ঘ্যের স্ট্রিংয়ে রূপান্তর করে। আপনি লগইন করলে অ্যাপ যা টাইপ করেছেন তার হ্যাশ বানিয়ে সংরক্ষিত হ্যাশের সাথে মেলায়।
দুটি বিষয় এটিকে নিরাপদ করে:
- একটি salt — প্রতিটি পাসওয়ার্ডে হ্যাশ করার আগে যোগ করা একটি এলোমেলো মান, যাতে একই পাসওয়ার্ড দুইজনের হ্যাশ আলাদা হয় এবং আগে থেকে তৈরি লুকআপ টেবিল কাজে আসে না।
- পাসওয়ার্ডের জন্য তৈরি একটি ধীর অ্যালগরিদম — যেমন Argon2, bcrypt বা scrypt। MD5 বা SHA-256-এর মতো সাধারণ-উদ্দেশ্যের হ্যাশ নিজে থেকেই অনেক বেশি দ্রুত; আক্রমণকারী বিলিয়ন অনুমান চালাতে পারে।
Hashing ও encryption এক জিনিস নয়। এনক্রিপ্ট করা ডেটা একটি কী দিয়ে ডিক্রিপ্ট করা যায়; পাসওয়ার্ড হ্যাশ ডিজাইনই করা হয়েছে যেন তা উল্টানো না যায়।
সেশন বনাম টোকেন
লগইনের পর অ্যাপকে প্রতিটি অনুরোধে আপনাকে চিনতে হয়। এর জন্য দুটি সাধারণ পদ্ধতি আছে।
| সেশন (কুকি) | টোকেন (যেমন JWT) | |
|---|---|---|
| ব্রাউজার কী ধরে রাখে | কুকিতে একটি এলোমেলো সেশন ID | ব্যবহারকারীর তথ্য ও মেয়াদসহ একটি স্বাক্ষরিত টোকেন |
| লগইনের অবস্থা কোথায় থাকে | সার্ভারে, একটি ডেটাবেস বা স্টোরে | টোকেনের ভেতরেই |
| সবখান থেকে কাউকে লগআউট করা | সহজ: সার্ভার থেকে সেশন মুছে ফেলুন | কঠিন: ব্লক-লিস্ট না রাখলে মেয়াদ শেষ না হওয়া পর্যন্ত টোকেন বৈধ থাকে |
| সাধারণ ব্যবহার | ঐতিহ্যবাহী ওয়েব অ্যাপ | API, মোবাইল অ্যাপ, একে অপরের সাথে কথা বলা সার্ভিস |
কুকির জন্য তিনটি সেটিং গুরুত্বপূর্ণ: HttpOnly (পেজের JavaScript কুকি পড়তে পারে না), Secure (শুধু HTTPS-এ পাঠানো হয়) এবং SameSite (অন্য সাইটের অনুরোধে এটি পাঠানো সীমিত করে)। ব্রাউজারের localStorage-এ টোকেন রাখা সাধারণ, কিন্তু তাতে পেজে চলা যেকোনো স্ক্রিপ্ট টোকেন পেতে পারে।
OAuth ও “Google দিয়ে সাইন ইন”
OAuth 2.0 হলো delegated authorization-এর একটি স্ট্যান্ডার্ড: এটি কোনো অ্যাপকে আপনার Google পাসওয়ার্ড না দেখেই অন্য সার্ভিসে আপনার অ্যাকাউন্টের সীমিত অ্যাক্সেস দিতে দেয় — যেমন আপনার Google Calendar পড়া। আপনাকে Google-এ পাঠানো হয়, আপনি নির্দিষ্ট অনুমতি (যাকে scopes বলে) অনুমোদন করেন, এবং Google অ্যাপকে শুধু সেই অনুমতির জন্য একটি টোকেন দেয়।
OAuth নিজে থেকে অ্যাক্সেস দেওয়ার জন্য ডিজাইন করা হয়েছিল, আপনি কে তা বলার জন্য নয়। OpenID Connect (OIDC) হলো OAuth 2.0-এর ওপর একটি স্তর, যা পরিচয় যোগ করে — “Google দিয়ে সাইন ইন” বা “Apple দিয়ে সাইন ইন” এটিই ব্যবহার করে। সেটআপ করতে আপনি প্রদানকারীর কাছে আপনার অ্যাপ নিবন্ধন করেন এবং একটি client ID ও client secret পান; secret আপনার সার্ভারে থাকে।
একটি বাস্তব উদাহরণ: একটি ক্লায়েন্ট পোর্টালের লগইন
ধরুন আপনি একটি পোর্টাল বানাচ্ছেন, যেখানে একটি ডিজাইন এজেন্সির ক্লায়েন্টরা তাদের প্রজেক্ট ও ইনভয়েস দেখেন।
- Authentication: ক্লায়েন্টরা ইমেইল ও একটি ম্যাজিক লিংক দিয়ে লগইন করেন, তাই পাসওয়ার্ড ব্যবস্থাপনার কিছু নেই। এজেন্সির স্টাফ Google Workspace অ্যাকাউন্ট দিয়ে লগইন করেন।
- রোল: প্রতিটি ব্যবহারকারীর একটি রোল থাকে —
clientবাstaff। - Authorization নিয়ম:
| কাজ | ক্লায়েন্ট | স্টাফ |
|---|---|---|
| নিজের কোম্পানির প্রজেক্ট দেখা | হ্যাঁ | হ্যাঁ |
| অন্য কোম্পানির প্রজেক্ট দেখা | না | হ্যাঁ |
| একটি প্রজেক্টে ফাইল আপলোড | শুধু নিজের প্রজেক্টে | হ্যাঁ |
| একটি ইনভয়েস পরিশোধিত চিহ্নিত করা | না | হ্যাঁ |
- কোথায় প্রয়োগ হয়: সার্ভারে, প্রতিটি অনুরোধে। সার্ভার বর্তমান ব্যবহারকারীকে খোঁজে, তারপর শুধু সেই প্রজেক্টগুলো ফেরত দেয় যেখানে
project.company_idব্যবহারকারীর কোম্পানির সাথে মেলে। “Mark paid” বোতাম লুকিয়ে রাখলেই যথেষ্ট নয় — এন্ডপয়েন্টকেই অস্বীকার করতে হবে।
সাধারণ শব্দের ব্যাখ্যা
| শব্দ | অর্থ |
|---|---|
| Authentication (AuthN) | কে কেউ তা নিশ্চিত করা। |
| Authorization (AuthZ) | তারা কী করতে পারবে তা ঠিক করা। |
| Session | অনুরোধগুলোর মধ্যে অ্যাপ মনে রাখে আপনি লগইন আছেন। |
| Cookie | ছোট একটি ডেটা, যা ব্রাউজার প্রতিটি অনুরোধে সাইটে ফেরত পাঠায়। |
| JWT | JSON Web Token: একটি স্বাক্ষরিত, সংক্ষিপ্ত টোকেন, যাতে ব্যবহারকারী ID ও মেয়াদের মতো দাবি থাকে। |
| Role / permission | admin বা member-এর মতো লেবেল, যা অ্যাক্সেস ঠিক করে। |
| MFA / 2FA | দ্বিতীয় একটি প্রমাণ চাওয়া, যেমন authenticator অ্যাপের কোড। |
| SSO | Single sign-on: অনেক অ্যাপের জন্য একটি লগইন (প্রায়ই একটি কোম্পানির অ্যাকাউন্ট)। |
| 401 বনাম 403 | “আপনি কে?” (প্রমাণীকৃত নন) বনাম “আপনি এটি করতে পারবেন না” (অনুমোদিত নন)। |
সাধারণ ভুল ও ভুল ধারণা
- শুধু পেজে অনুমতি যাচাই করা। ব্রাউজার একটি বোতাম লুকালেও যদি API যাচাই না করে, যেকেউ সরাসরি API কল করতে পারে।
- URL-এর ID-কে বিশ্বাস করা।
/invoices/1042অবশ্যই যাচাই করবে যে ইনভয়েস 1042 লগইন করা ব্যবহারকারীর। - নিজের ক্রিপ্টো বানানো। পরিচিত লাইব্রেরি বা প্রদানকারী ব্যবহার করুন; AI-কে নিজের হ্যাশিং পদ্ধতি বানাতে দেবেন না।
- দুর্বল পাসওয়ার্ড রিসেট। রিসেট লিংক একবারই ব্যবহারযোগ্য, দ্রুত মেয়াদোত্তীর্ণ হওয়া উচিত এবং কোনো ইমেইলের অ্যাকাউন্ট আছে কি না তা প্রকাশ করা উচিত নয়।
- আপনার অ্যাপের লগইন ও আপনার বিল্ডারের লগইন গুলিয়ে ফেলা। আপনার অ্যাপের ব্যবহারকারীরা আপনি যে টুল দিয়ে অ্যাপ বানাচ্ছেন সেখানকার অ্যাকাউন্ট থেকে আলাদা।
- লগইনে রেট লিমিট না থাকা। এটি ছাড়া আক্রমণকারী অসীমভাবে পাসওয়ার্ড চেষ্টা করতে পারে।
আপনার AI বিল্ডারকে কী চাইবেন
- “[একটি সুপরিচিত লাইব্রেরি বা প্রদানকারী] ব্যবহার করে সাইন-আপ ও লগইন যোগ করো। নিজে পাসওয়ার্ড হ্যাশিং লিখো না।”
- “পাসওয়ার্ড bcrypt বা Argon2 দিয়ে হ্যাশ করে সংরক্ষণ করো।”
- “সেশনের জন্য HttpOnly, Secure কুকি ব্যবহার করো।”
- “রোল যোগ করো: admin ও member। প্রতিটি এন্ডপয়েন্ট ও কোন রোল সেটি কল করতে পারে তার তালিকা দাও।”
- “সার্ভারে নিশ্চিত করো ব্যবহারকারী শুধু নিজের রেকর্ড পড়তে ও বদলাতে পারে। তারপর দেখাও কীভাবে যাচাই করেছ।”
- “এক ঘণ্টায় মেয়াদোত্তীর্ণ হওয়া একবার-ব্যবহারযোগ্য লিংক দিয়ে পাসওয়ার্ড রিসেট যোগ করো।”
- “লগইনের চেষ্টা রেট-লিমিট করো।”
তারপর নিজে পরীক্ষা করুন: দুটি অ্যাকাউন্ট তৈরি করুন এবং একটি অ্যাকাউন্টে লগইন থাকা অবস্থায় অন্যটির ডেটায় পৌঁছানোর চেষ্টা করুন। আরও বিস্তারিত জানতে দেখুন লগইন যোগের গাইড ও নিরাপত্তা চেকলিস্ট।
Mythex-এ Authentication
Mythex আপনার অ্যাপের ব্যবহারকারীদের জন্য কোনো বিল্ট-ইন auth প্রোডাক্ট দেয় না; আপনি একটি পদ্ধতি বাছেন — আপনার প্রজেক্টের ডেটাবেসে ইমেইল ও পাসওয়ার্ড, বা হোস্টেড প্রদানকারীর SDK — এবং এজেন্টকে যোগ করতে বলেন। প্রদানকারীর কী প্রজেক্ট সিক্রেটে যায়, চ্যাটে নয়। এটি Mythex-এ নিজের সাইন-ইন থেকে আলাদা। ডকসের অ্যাপে লগইন যোগের রেসিপিতে একটি স্টার্টার প্রম্পট আছে, যা আপনি মানিয়ে নিতে পারেন, এবং API কী ব্যাখ্যা করে সার্ভার-সাইড যাচাইগুলো কোথায় থাকে।
প্রশ্নোত্তর
Authentication ও authorization-এর মধ্যে পার্থক্য কী?
Authentication যাচাই করে আপনি কে, যেমন আপনার পাসওয়ার্ড মিলিয়ে। Authorization ঠিক করে আপনাকে চেনার পর আপনি কী করতে পারবেন, যেমন অ্যাডমিন পেজ দেখতে পারবেন কি না বা অন্য কারও বুকিং বদলাতে পারবেন কি না। অ্যাপের দুটোই দরকার।
OAuth কী?
OAuth 2.0 একটি স্ট্যান্ডার্ড, যা কোনো অ্যাপকে আপনার পাসওয়ার্ড না দেখেই অন্য একটি সার্ভিসে আপনার অ্যাকাউন্টের সীমিত অ্যাক্সেস দিতে দেয়। “Google দিয়ে সাইন ইন” OpenID Connect ব্যবহার করে, যা OAuth 2.0-এর ওপর তৈরি একটি পরিচয়-স্তর, তাই অ্যাপ Google থেকে জানতে পারে আপনি কে।
আমার অ্যাপের কি পাসওয়ার্ড সংরক্ষণ করা উচিত?
পাঠযোগ্য আকারে কখনও নয়। ইমেইল ও পাসওয়ার্ড লগইন ব্যবহার করলে পাসওয়ার্ড অবশ্যই salted hash হিসেবে রাখতে হবে, পাসওয়ার্ডের জন্য ডিজাইন করা ধীর অ্যালগরিদম যেমন Argon2 বা bcrypt দিয়ে। অনেক অ্যাপ হোস্টেড authentication প্রোভাইডার, সোশ্যাল লগইন বা ইমেইল ম্যাজিক লিংক ব্যবহার করে এই ঝামেলা এড়ায়।
সেশন না টোকেন — আমার অ্যাপের কোনটি ব্যবহার করা উচিত?
দুটোই কাজ করে। সেশন লগইনের অবস্থা সার্ভারে রাখে এবং ব্রাউজারকে কুকিতে একটি এলোমেলো ID দেয়, যা সহজে বাতিল করা যায়। JWT-র মতো টোকেন নিজের ভেতরেই স্বাক্ষরিত তথ্য বহন করে, যা API ও মোবাইল ক্লায়েন্টের জন্য উপযুক্ত, কিন্তু মেয়াদ শেষের আগে বাতিল করা কঠিন। একটি সাধারণ ওয়েব অ্যাপের জন্য কুকি-ভিত্তিক সেশন একটি নিরাপদ ডিফল্ট।