আর্কিটেকচার সিদ্ধান্ত রেকর্ড: প্রমাণীকরণ ও অনুমোদনের বিকল্প

ওয়েব অ্যাপ্লিকেশনের প্রমাণীকরণ (authentication) ও অনুমোদন (authorization) অ্যাপ্লিকেশন ও সেবায় প্রবেশাধিকার সুরক্ষিত করার দুটি অত্যন্ত গুরুত্বপূর্ণ ধারণা। উভয়ই ব্যবহারকারীদের পরিচয় এবং অনুমতি কীভাবে দেওয়া হয় তা নিয়ে কাজ করে, কিন্তু তারা ভিন্ন ভিন্ন দিকে মনোযোগ দেয়:

প্রমাণীকরণ হলো কোনো ব্যবহারকারী বা সিস্টেমের পরিচয় যাচাইয়ের প্রক্রিয়া।
অনুমোদন হলো প্রমাণীকৃত ব্যবহারকারী বা সিস্টেম কোন সম্পদ বা কাজে প্রবেশ করতে পারবে তা নির্ধারণের প্রক্রিয়া।

এখন আপনার উল্লেখ করা নির্দিষ্ট প্রোটোকল ও প্রযুক্তিগুলোতে যাওয়া যাক, যেগুলো আধুনিক ওয়েব অ্যাপ্লিকেশনে প্রমাণীকরণ ও অনুমোদন পরিচালনার জন্য সাধারণত ব্যবহৃত হয়।

1. OAuth (Open Authorization)

OAuth অনুমোদনের জন্য একটি উন্মুক্ত মান। এটি ব্যবহারকারীকে তাঁর পরিচয়পত্র শেয়ার না করেই কোনো তৃতীয় পক্ষের অ্যাপ্লিকেশনকে তাঁর সম্পদে সীমিত প্রবেশাধিকার দিতে দেয়। মূল ধারণা হলো প্রতিনিধিত্বমূলক প্রবেশাধিকার (delegated access)। যেসব পরিস্থিতিতে ব্যবহারকারীরা তৃতীয় পক্ষকে সরাসরি তাঁদের ব্যবহারকারীর নাম ও পাসওয়ার্ড না দিয়েই কোনো তৃতীয় পক্ষের সেবায় লগ ইন করতে পারেন (যেমন Google দিয়ে সাইন ইন), সেখানে OAuth প্রায়ই ব্যবহৃত হয়।

প্রবাহ: OAuth সাধারণত টোকেন-ভিত্তিক প্রবাহ অনুসরণ করে, যেখানে একটি অনুমোদন সার্ভার তৃতীয় পক্ষের অ্যাপ্লিকেশনকে একটি অ্যাক্সেস টোকেন ইস্যু করে। এই টোকেন ব্যবহারকারীর অনুমতি প্রতিনিধিত্ব করে, এবং অ্যাপ্লিকেশন এটি দিয়ে একটি API থেকে ব্যবহারকারীর ডেটা বা সম্পদে প্রবেশ করে।
উদাহরণ: একজন ব্যবহারকারী তাঁর Google অ্যাকাউন্ট ব্যবহার করে একটি তৃতীয় পক্ষের অ্যাপে সাইন ইন করেন। Google ব্যবহারকারীর পরিচয় যাচাই করে একটি টোকেন দেয়, যা তৃতীয় পক্ষের অ্যাপকে কিছু Google ডেটায় (যেমন Google Calendar) প্রবেশ করতে দেয়।

OAuth সরাসরি প্রমাণীকরণ সামলায় না; এটি প্রবেশাধিকার প্রদান নিয়ে। প্রমাণীকরণের জন্য OAuth প্রায়ই OpenID Connect-এর মতো অন্যান্য প্রোটোকলের সঙ্গে জোড়া হয়।

2. OpenID Connect (OIDC)

OpenID Connect (OIDC) হলো OAuth 2.0-এর ওপর নির্মিত একটি পরিচয় স্তর, যা OAuth-এর অনুমোদন সক্ষমতার সঙ্গে প্রমাণীকরণ যোগ করে। মূলত OpenID Connect ব্যবহারকারী প্রমাণীকরণ সামলাতে OAuth-কে সম্প্রসারিত করে এবং অ্যাপ্লিকেশনগুলোর জন্য ব্যবহারকারীর পরিচয় যাচাইয়ের একটি প্রমিত উপায় দেয়।

প্রবাহ: কোনো ব্যবহারকারী OpenID Connect ব্যবহার করে লগ ইন করলে তৃতীয় পক্ষের অ্যাপ্লিকেশন (OAuth অ্যাক্সেস টোকেনের পাশাপাশি) একটি ID টোকেন অনুরোধ করে। ID টোকেনে ব্যবহারকারী সম্পর্কে তথ্য (যেমন ব্যবহারকারীর নাম, ইমেইল এবং অন্যান্য ক্লেইম) থাকে। এর ফলে অ্যাপ্লিকেশন জানতে পারে ব্যবহারকারী কে এবং তিনি প্রমাণীকৃত কি না।
উদাহরণ: আপনার Google অ্যাকাউন্ট ব্যবহার করে Slack-এর মতো সেবায় লগ ইন করার মধ্যে (Google এখানে OpenID Connect প্রদানকারী) OpenID Connect-এর মাধ্যমে প্রমাণীকরণ জড়িত, আর OAuth আপনার Google সম্পদে প্রবেশাধিকার পরিচালনা করে।

OIDC তৃতীয় পক্ষের অ্যাপগুলোর জন্য ব্যবহারকারী প্রমাণীকরণ সহজ করে, একই সঙ্গে সেই অ্যাপগুলো কোন সম্পদে প্রবেশ করতে পারবে তার ওপর সূক্ষ্ম নিয়ন্ত্রণ বজায় রাখে।

3. SAML (Security Assertion Markup Language)

SAML পক্ষগুলোর মধ্যে প্রমাণীকরণ ও অনুমোদন ডেটা আদান-প্রদানে ব্যবহৃত একটি পুরোনো, XML-ভিত্তিক মান, বিশেষ করে সিঙ্গেল সাইন-অন (SSO) দৃশ্যকল্পে। এটি প্রধানত এন্টারপ্রাইজ পরিবেশে ব্যবহৃত হয়, যাতে ব্যবহারকারীরা একবার প্রমাণীকৃত হয়ে পরিচয়পত্র আবার না দিয়ে একাধিক অ্যাপ্লিকেশনে প্রবেশ করতে পারেন।

প্রবাহ: ব্যবহারকারী প্রথমে একটি পরিচয় প্রদানকারীর (IdP) কাছে প্রমাণীকৃত হন। IdP একটি স্বাক্ষরিত SAML অ্যাসারশন তৈরি করে, যাতে ব্যবহারকারীর পরিচয় ও সংশ্লিষ্ট বৈশিষ্ট্য থাকে। অ্যাসারশনটি সেবা প্রদানকারীর (SP) কাছে পাঠানো হয়, যা অ্যাপ্লিকেশনে প্রবেশ অনুমোদনে এটি ব্যবহার করে।
উদাহরণ: একজন কর্মচারী তাঁর কর্পোরেট পোর্টালে (IdP) লগ ইন করেন এবং পরিচয়পত্র আবার না দিয়েই স্বয়ংক্রিয়ভাবে ইমেইল, CRM ইত্যাদি অন্যান্য সিস্টেমে লগ ইন হয়ে যান। প্রমাণীকরণ প্রক্রিয়া IdP-র পাঠানো SAML অ্যাসারশনের ওপর ভিত্তি করে।

SAML সাধারণত এন্টারপ্রাইজ SSO সমাধানে ব্যবহৃত হয় এবং কর্পোরেট পরিবেশের ওয়েব অ্যাপ্লিকেশনের জন্য ভালো কাজ করে, তবে OAuth/OIDC-এর তুলনায় এটি মোবাইল-বান্ধব কম।

4. WS-Federation (Web Services Federation)

WS-Federation সিঙ্গেল সাইন-অন (SSO)-এর জন্য ব্যবহৃত আরেকটি প্রোটোকল, বিশেষ করে মাইক্রোসফট-ভিত্তিক এন্টারপ্রাইজ পরিবেশে। এটি WS- (Web Services)* নির্দিষ্টকরণ পরিবারের অংশ এবং বিভিন্ন নিরাপত্তা ডোমেইনে (যেমন বিভিন্ন সংগঠন বা বিভিন্ন সেবার মধ্যে) পরিচয় ফেডারেশনের সুযোগ দেয়।

প্রবাহ: WS-Federation একটি বিশ্বস্ত পরিচয় প্রদানকারীকে (IdP) ব্যবহারকারীদের প্রমাণীকরণ করতে এবং এমন টোকেন ইস্যু করতে দেয়, যা সেবা প্রদানকারী অনুমোদনের জন্য ব্যবহার করতে পারে। এটি SAML-এর মতো, তবে প্রায়ই মাইক্রোসফট প্রযুক্তির ওপর ব্যাপকভাবে নির্ভরশীল দৃশ্যকল্পে ব্যবহৃত হয়।
উদাহরণ: একজন ব্যবহারকারী Microsoft Azure Active Directory (AD)-তে হোস্ট করা একটি এন্টারপ্রাইজ অ্যাপ্লিকেশনে লগ ইন করেন, এবং তাঁর পরিচয় তৃতীয় পক্ষের বিক্রেতাদের হোস্ট করা অ্যাপ্লিকেশনসহ অন্যান্য ফেডারেটেড সেবায় প্রবেশে ব্যবহার করা যেতে পারে।

যদিও অনেক আধুনিক ওয়েব পরিবেশে WS-Federation মূলত OAuth 2.0 ও OpenID Connect-এর মতো নতুন প্রোটোকল দ্বারা প্রতিস্থাপিত হয়েছে, এটি এখনও লিগ্যাসি সিস্টেমে, বিশেষ করে মাইক্রোসফট-কেন্দ্রিক এন্টারপ্রাইজে ব্যবহৃত হয়।

5. LDAP (Lightweight Directory Access Protocol)

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

প্রমাণীকরণ: LDAP কোনো অ্যাপ্লিকেশনকে পরিচয়পত্রের (যেমন পাসওয়ার্ড) জন্য ডিরেক্টরি সেবায় কোয়েরি করে ব্যবহারকারীদের প্রমাণীকরণ করতে দেয়।
অনুমোদন: এটি ব্যবহারকারীর ভূমিকা ও অনুমতিও পরিচালনা করে, যা নির্দিষ্ট সম্পদে ব্যবহারকারীর প্রবেশাধিকার আছে কি না তা নির্ধারণে সাহায্য করে।
উদাহরণ: অনেক এন্টারপ্রাইজ, বিশেষ করে Windows পরিবেশে, প্রমাণীকরণ ও অনুমোদনের জন্য LDAP-ভিত্তিক ডিরেক্টরি (যেমন Active Directory) ব্যবহার করে।

অভ্যন্তরীণ সিস্টেমে ব্যবহারকারীর প্রবেশাধিকার পরিচালনায় এন্টারপ্রাইজের জন্য LDAP অপরিহার্য, কিন্তু আধুনিক ওয়েব প্রেক্ষাপটে আরও সম্পূর্ণ পরিচয় ব্যবস্থাপনার জন্য LDAP প্রায়ই SAML বা OAuth-এর মতো অন্যান্য প্রোটোকলের সঙ্গে সমন্বিত হয়।

6. সোশ্যাল SSO প্রদানকারী

Facebook, Google, Twitter, GitHub ও অন্যান্য সোশ্যাল সিঙ্গেল সাইন-অন (SSO) প্রদানকারী ব্যবহারকারীদের তাঁদের সোশ্যাল মিডিয়া পরিচয়পত্র ব্যবহার করে তৃতীয় পক্ষের অ্যাপ্লিকেশনে প্রমাণীকৃত হতে দেয়। এটি এক ধরনের OAuth-ভিত্তিক প্রমাণীকরণ, যেখানে তৃতীয় পক্ষের সেবা (যেমন Google) পরিচয় প্রদানকারী।

প্রবাহ: ব্যবহারকারী (যেমন) "Log in with Google" ক্লিক করেন। অ্যাপ Google-এ রিডাইরেক্ট করে, যেখানে ব্যবহারকারী লগ ইন করেন (আগে লগ ইন না থাকলে)। এরপর Google তৃতীয় পক্ষের অ্যাপকে একটি অ্যাক্সেস টোকেন বা ID টোকেন দেয়, যা ব্যবহারকারীকে প্রমাণীকৃত করতে এবং সম্ভবত তাঁর ডেটায় প্রবেশ করতে ব্যবহার করা যায়।
উদাহরণ: অনেক অ্যাপ্লিকেশন আপনাকে আপনার Google বা Facebook পরিচয়পত্র ব্যবহার করে লগ ইন করতে দেয়। অ্যাপটি পর্দার আড়ালে আপনার পরিচয় যাচাই করতে এবং কিছু ক্ষেত্রে নির্দিষ্ট সোশ্যাল মিডিয়া ডেটায় প্রবেশ করতে OAuth বা OpenID Connect ব্যবহার করবে।

সোশ্যাল SSO প্রমাণীকরণের একটি সুবিধাজনক ও ব্যাপকভাবে গৃহীত পদ্ধতি, কারণ এটি সেই ব্যবহারকারীদের জন্য ঘর্ষণ কমায়, যাঁরা আরও একটি ব্যবহারকারীর নাম ও পাসওয়ার্ড তৈরি করতে চান না।

পার্থক্যের সারসংক্ষেপ:

OAuth: অনুমোদনের জন্য ব্যবহৃত, তৃতীয় পক্ষের অ্যাপকে পরিচয়পত্র প্রকাশ না করেই ব্যবহারকারীর ডেটায় প্রবেশ করতে দেয়।
OpenID Connect: প্রমাণীকরণ দিতে OAuth সম্প্রসারণ করে, অ্যাপকে ব্যবহারকারীর পরিচয় যাচাই করতে সক্ষম করে।
SAML: SSO-র জন্য ব্যবহৃত XML-ভিত্তিক প্রোটোকল, প্রায়ই এন্টারপ্রাইজ পরিবেশে।
WS-Federation: পরিচয় ফেডারেশনের জন্য মাইক্রোসফট-নির্দিষ্ট প্রোটোকল, লিগ্যাসি সিস্টেমে ব্যবহৃত।
LDAP: ব্যবহারকারী প্রমাণীকরণ ও অনুমোদন পরিচালনার জন্য ডিরেক্টরি সেবায় কোয়েরি করার প্রোটোকল।
সোশ্যাল SSO প্রদানকারী: OAuth-ভিত্তিক সিস্টেম (যেমন Google, Facebook), যা তৃতীয় পক্ষের অ্যাপকে সোশ্যাল মিডিয়া পরিচয়পত্র ব্যবহার করে ব্যবহারকারীদের প্রমাণীকৃত করতে দেয়।

এই প্রযুক্তিগুলোর প্রত্যেকটির নিজস্ব শক্তি ও ব্যবহারক্ষেত্র আছে, এবং আধুনিক অ্যাপ্লিকেশনে নিরাপত্তার বিভিন্ন দিকের জন্য এগুলোর সমন্বিত ব্যবহার দেখতে পারেন (যেমন API প্রবেশের জন্য OAuth/OIDC, এন্টারপ্রাইজ SSO-র জন্য SAML)।