OAuth
OAuth হলো একটি ওপেন অথরাইজেশন প্রোটোকল, যা তৃতীয় পক্ষের অ্যাপ্লিকেশনকে অন্য সার্ভিসে ব্যবহারকারীর সুরক্ষিত রিসোর্সে সীমিত অ্যাক্সেস পেতে দেয়। এটি লগইন ও পাসওয়ার্ড পাঠানোর প্রয়োজন দূর করে, ব্যক্তিগত ডেটাকে সুরক্ষিত রাখে।
সূচিপত্র
সহজ ভাষায় OAuth কী
OAuth (Open Authorization) হলো একটি অথরাইজেশন প্রোটোকল, যা একটি অ্যাপ্লিকেশনকে আপনার লগইন ও পাসওয়ার্ড ছাড়াই অন্য সার্ভিসে থাকা আপনার ডেটায় অ্যাক্সেস পেতে সহায়তা করে। পাসওয়ার্ডের বদলে অ্যাপ্লিকেশনটি একটি বিশেষ সাময়িক অ্যাক্সেস কী (টোকেন) পায়।
সহজ ভাষায়, OAuth হলো এমন একটি ডিজিটাল পাস, যা আপনি একজন অতিথিকে দিচ্ছেন—যাতে সে আপনার বাড়িতে ঢুকতে পারে, তবে কেবল প্রবেশকক্ষে, সব ঘরে নয়। আপনি তাকে সব দরজার চাবি (আপনার পাসওয়ার্ড) দেন না; বরং সীমিত ক্ষমতাসম্পন্ন একটি বিশেষ এককালীন পাস দেন।
ধ্রুপদী উদাহরণ—যেকোনো ওয়েবসাইটে «Google দিয়ে লগইন» বা «VKontakte দিয়ে লগইন» বোতাম। আপনি বোতামে ক্লিক করলে আপনাকে Google-এর পৃষ্ঠায় নিয়ে যাওয়া হয়, যেখানে আপনি পাসওয়ার্ড লেখেন (তৃতীয় পক্ষের সাইটে নয়!), অ্যাক্সেস নিশ্চিত করেন, আর সাইটটি কেবল সেটাই পায়, যা আপনি অনুমতি দিয়েছেন—যেমন আপনার নাম ও email। আপনার পাসওয়ার্ড গোপনই থাকে।
OAuth পুরনো সিস্টেমের মূল সমস্যাটির সমাধান করে—আগে অ্যাপ্লিকেশনগুলো অন্য সার্ভিসের লগইন ও পাসওয়ার্ড চাইত, যা ছিল অত্যন্ত ঝুঁকিপূর্ণ। অ্যাপ্লিকেশনটি প্রতারণামূলক প্রমাণিত হলে আপনি পুরো অ্যাকাউন্টের অ্যাক্সেস হারাতেন। OAuth নির্দিষ্ট সময়ের জন্য নির্দিষ্ট ডেটায় কেবল সীমিত অ্যাক্সেস দেয়। Okta-র তথ্যমতে, 80%-এরও বেশি কর্পোরেট অ্যাপ্লিকেশন অথরাইজেশনের জন্য OAuth ব্যবহার করে, আর প্রতিদিন ইস্যু হওয়া OAuth টোকেনের সংখ্যা বিলিয়নে হিসাব করা হয়।
ওয়েব অ্যাপ্লিকেশনের নিরাপত্তার সঙ্গে OAuth কীভাবে সম্পর্কিত, তা জানতে তথ্য নিরাপত্তা নিবন্ধটি পড়ুন।
OAuth কীভাবে কাজ করে
OAuth প্রক্রিয়াটিকে একটি ডিজিটাল পাস পাওয়ার মতো ভাবা যায়। এতে চারটি পক্ষ জড়িত:
- রিসোর্সের মালিক (Resource Owner): এটি আপনি—ব্যবহারকারী, যিনি ডেটার মালিক এবং অনুমতি দেন।
- ক্লায়েন্ট (Client): তৃতীয় পক্ষের অ্যাপ্লিকেশন, যা আপনার ডেটায় অ্যাক্সেস চায় (যেমন মোবাইল অ্যাপ্লিকেশন বা ওয়েবসাইট)।
- অথরাইজেশন সার্ভার (Authorization Server): সার্ভার, যা আপনার পরিচয় যাচাই করে টোকেন ইস্যু করে (যেমন Google Accounts, GitHub)।
- রিসোর্স সার্ভার (Resource Server): সার্ভার, যেখানে আপনার ডেটা সংরক্ষিত থাকে (যেমন Google Drive বা VK-এর প্রোফাইল API)।
প্রক্রিয়াটি ধাপে ধাপে এভাবে চলে:
- আপনি তৃতীয় পক্ষের সাইটে «Google দিয়ে লগইন»-এ ক্লিক করেন।
- সাইটটি আপনাকে Google-এর সার্ভারে পাঠায়, যেখানে আপনি পাসওয়ার্ড লেখেন।
- Google জিজ্ঞেস করে: «আপনি কি এই সাইটকে আপনার নাম ও email-এ অ্যাক্সেসের অনুমতি দেবেন?»
- আপনি «অনুমতি দিন»-এ ক্লিক করেন।
- Google সাইটটিকে একটি সাময়িক কোড দেয় এবং আপনাকে ফিরিয়ে পাঠায়।
- সাইটটি কোডের বিনিময়ে অ্যাক্সেস টোকেন (Access Token) গ্রহণ করে।
- সাইটটি Google-এর API থেকে আপনার ডেটা চাইতে টোকেনটি ব্যবহার করে।
টোকেন কীভাবে কাজ করে, তা জানতে টোকেন নিবন্ধটি পড়ুন।
OAuth 2.0-এর গ্রান্ট প্রকারভেদ
OAuth 2.0 কয়েকটি অথরাইজেশন ফ্লো (গ্রান্ট) সমর্থন করে, যা অ্যাপ্লিকেশনের ধরন (ওয়েব, মোবাইল, সার্ভার) এবং বিশ্বাসের স্তরের ওপর নির্ভর করে নির্বাচিত হয়:
- Authorization Code Grant: ওয়েব ও মোবাইল অ্যাপ্লিকেশনের জন্য সবচেয়ে প্রচলিত ও নিরাপদ ফ্লো। ক্লায়েন্ট অথরাইজেশন কোড পায়, যা পরে অ্যাক্সেস টোকেনে রূপান্তরিত হয়। কোডটি ব্যবহারকারীর ব্রাউজারের মধ্য দিয়ে যায়, আর টোকেন যায় ক্লায়েন্ট সার্ভার ও অথরাইজেশন সার্ভারের মধ্যকার সুরক্ষিত চ্যানেল দিয়ে।
- Implicit Grant (অপ্রচলিত): সিঙ্গেল-পেজ অ্যাপ্লিকেশনের (SPA) জন্য সরলীকৃত ফ্লো, যেখানে টোকেন সরাসরি ব্রাউজারে ফেরত আসে। এটি কম নিরাপদ বলে বিবেচিত এবং বর্তমান প্রেক্ষাপটে ব্যবহারের পরামর্শ দেওয়া হয় না।
- Resource Owner Password Credentials Grant: যে ফ্লোতে ব্যবহারকারী তার লগইন ও পাসওয়ার্ড সরাসরি ক্লায়েন্টকে দেয়। কেবল বিশ্বস্ত অ্যাপ্লিকেশনের ক্ষেত্রে ব্যবহৃত হয় (যেমন ব্যাংকের অফিসিয়াল মোবাইল অ্যাপ)। উচ্চ ঝুঁকিপূর্ণ পদ্ধতি।
- Client Credentials Grant: সার্ভার-টু-সার্ভার ইন্টারঅ্যাকশনে ব্যবহৃত হয়, যেখানে ব্যবহারকারী থাকে না। ক্লায়েন্ট নিজস্ব ক্রেডেনশিয়াল (client ID ও client secret) দিয়ে প্রমাণীকরণ করে এবং সুরক্ষিত রিসোর্সে অ্যাক্সেসের টোকেন পায়।
সঠিক গ্রান্ট নির্বাচন অ্যাপ্লিকেশনের নিরাপত্তা ডিজাইনের একটি অত্যন্ত গুরুত্বপূর্ণ ধাপ। ভুল নির্বাচন দুর্বলতা ও ডেটা ফাঁসের ঝুঁকি তৈরি করতে পারে।
OAuth 1.0 বনাম OAuth 2.0
OAuth 2.0 হলো প্রোটোকলের আধুনিক সংস্করণ, যা OAuth 1.0-কে প্রতিস্থাপন করেছে। প্রধান পার্থক্যগুলো:
- সরলতা: ডেভেলপারদের জন্য OAuth 2.0 উল্লেখযোগ্যভাবে সহজ। রিকোয়েস্ট সাইন করার জন্য জটিল ক্রিপ্টোগ্রাফির প্রয়োজন নেই (OAuth 1.0-এ প্রতিটি রিকোয়েস্টের জন্য ডিজিটাল স্বাক্ষর তৈরি করতে হতো)।
- নমনীয়তা: OAuth 2.0 বিভিন্ন ব্যবহার-পরিস্থিতি সমর্থন করে: ওয়েব অ্যাপ্লিকেশন, মোবাইল অ্যাপ্লিকেশন, ব্রাউজারবিহীন ডিভাইস (IoT), সার্ভার-টু-সার্ভার ইন্টারঅ্যাকশন।
- টোকেন: OAuth 2.0 অ্যাক্সেস টোকেন (Access Token) ও রিফ্রেশ টোকেন (Refresh Token) ব্যবহার করে, যাতে ব্যবহারকারীর পুনরায় লগইন ছাড়াই অ্যাক্সেস বহমান রাখা যায়।
- নিরাপত্তা: OAuth 2.0 টোকেন সুরক্ষার জন্য HTTPS-এ প্রেরণ সমর্থন করে এবং নিরাপত্তার জন্য TLS-এর ওপর অধিক নির্ভর করে।
আজ অন্তর্জালে অথরাইজেশনের ডি ফ্যাক্টো মান OAuth 2.0। এটি ব্যবহার করে Google, Facebook, GitHub, Microsoft, Yandex-সহ হাজারো অন্য সার্ভিস। API-এর সঙ্গে OAuth কীভাবে ইন্টিগ্রেট হয়, তা জানতে ইনফ্রাস্ট্রাকচার নিবন্ধটি পড়ুন।
OAuth-এর নিরাপত্তা
OAuth নিরাপদ প্রোটোকল হলেও এর ব্যবহারের সময় বিবেচনায় রাখা জরুরি এমন ঝুঁকিও রয়েছে:
- টোকেন আটকানো: আক্রমণকারী যদি অ্যাক্সেস টোকেন আটকাতে পারে (যেমন অসুরক্ষিত সংযোগ বা Man-in-the-Middle আক্রমণের মাধ্যমে), সে মেয়াদ শেষ হওয়ার আগেই তা ব্যবহার করতে পারে। HTTPS ব্যবহার বাধ্যতামূলক।
- ফিশিং: আক্রমণকারীরা ক্রেডেনশিয়াল চুরির জন্য অথরাইজেশন সার্ভারের অনুকরণে ভুয়া লগইন পৃষ্ঠা তৈরি করতে পারে। পাসওয়ার্ড দেওয়ার আগে সবসময় URL যাচাই করা জরুরি।
- CSRF আক্রমণ (Cross-Site Request Forgery): এমন আক্রমণ, যেখানে আক্রমণকারী ব্যবহারকারীকে তার লগইন করা সাইটে অনাকাঙ্ক্ষিত কাজ করায়। সুরক্ষার জন্য OAuth রিকোয়েস্টে state প্যারামিটার ব্যবহৃত হয়।
- client secret-এর আপস: আক্রমণকারী যদি client secret (অ্যাপ্লিকেশনের গোপন কী) পেয়ে যায়, সে নিজেকে বৈধ অ্যাপ্লিকেশন হিসেবে উপস্থাপন করতে পারে। client secret নিরাপদ জায়গায় রাখুন।
নিরাপত্তা জোরদার করতে অ্যাক্সেস টোকেনের স্বল্প আয়ু (যেমন 1 ঘণ্টা) রাখা এবং পুনরায় পাসওয়ার্ড না দিয়ে সেশন বহমান রাখতে রিফ্রেশ টোকেন ব্যবহারের পরামর্শ দেওয়া হয়। এছাড়া মোবাইল অ্যাপ্লিকেশনে অথরাইজেশন কোড আটকানো থেকে সুরক্ষার জন্য PKCE (Proof Key for Code Exchange) ব্যবহার করাও গুরুত্বপূর্ণ।
Frequently asked questions
সহজ ভাষায় OAuth কী?
OAuth হলো নতুন কোনো লগইন ও পাসওয়ার্ড তৈরি না করেই ওয়েবসাইটে লগইনের একটি উপায়। আপনি «Google দিয়ে লগইন» বা «VKontakte দিয়ে লগইন»-এ ক্লিক করে অনুমতি দিলে সাইটটি কেবল সেটাই পায়, যা আপনি অনুমোদন দিয়েছেন (যেমন নাম ও email)। এ ক্ষেত্রে আপনার পাসওয়ার্ড কখনোই সাইটে পাঠানো হয় না। এটি পুরো বাড়ির চাবি না দিয়ে সীমিত ক্ষমতাসম্পন্ন ডিজিটাল পাস দেওয়ার মতো। ডেটার নিরাপত্তা সম্পর্কে জানতে তথ্য নিরাপত্তা নিবন্ধটি পড়ুন।
OAuth 2.0 কীভাবে কাজ করে?
OAuth 2.0 «ডিজিটাল পাস»-এর নীতিতে কাজ করে: আপনি সার্ভিসকে (যেমন Google) অনুমতি দেন, আর সে অ্যাপ্লিকেশনটিকে আপনার ডেটায় অ্যাক্সেসের জন্য একটি সাময়িক কী (টোকেন) ইস্যু করে। অ্যাপ্লিকেশনটি আপনার পাসওয়ার্ড জানে না এবং আপনার অনুমোদিত নয় এমন কিছুতে অ্যাক্সেস পেতে পারে না। প্রক্রিয়ায় চারটি পক্ষ জড়িত: রিসোর্সের মালিক (আপনি), ক্লায়েন্ট (অ্যাপ্লিকেশন), অথরাইজেশন সার্ভার (Google) ও রিসোর্স সার্ভার (API)। টোকেন সীমিত সময়ের জন্য বৈধ থাকে এবং যেকোনো মুহূর্তে বাতিল করা যায়। টোকেন কীভাবে কাজ করে তা জানতে টোকেন নিবন্ধটি পড়ুন।
OAuth 1.0 ও OAuth 2.0-এর পার্থক্য কী?
OAuth 2.0 হলো প্রোটোকলের আধুনিক সংস্করণ। ডেভেলপারদের জন্য এটি ব্যবহারে সহজ (জটিল রিকোয়েস্ট স্বাক্ষরের প্রয়োজন নেই), বেশি পরিস্থিতি সমর্থন করে (মোবাইল অ্যাপ্লিকেশন, স্মার্ট ডিভাইস, সার্ভার-টু-সার্ভার) এবং পুনরায় লগইন ছাড়াই অ্যাক্সেস বহমান রাখতে রিফ্রেশ টোকেন ব্যবহার করে। OAuth 2.0 নিরাপত্তার জন্য HTTPS-এর ওপরও বেশি নির্ভর করে। বর্তমানে OAuth 2.0 সর্বত্র ব্যবহৃত হয়, আর OAuth 1.0 অপ্রচলিত বলে বিবেচিত।
কেবল পাসওয়ার্ড পাঠানোর বদলে OAuth কেন প্রয়োজন?
পাসওয়ার্ড পাঠানোর তুলনায় OAuth বেশি নিরাপদ। অ্যাপ্লিকেশনটি প্রতারণামূলক হলেও OAuth-এ আপনি তাকে কেবল সীমিত ডেটায় (যেমন শুধু নাম) অ্যাক্সেস দেন, পুরো অ্যাকাউন্টে নয়। আপনি নিজের অ্যাকাউন্টের সেটিংস থেকে যেকোনো মুহূর্তে অ্যাক্সেস বাতিল করতে পারেন। পাসওয়ার্ড দিলে ঝুঁকিতে পড়ে পুরো অ্যাকাউন্ট—আক্রমণকারী আপনার ইমেইল, ডকুমেন্ট ও পেমেন্ট তথ্যসহ সব ডেটায় অ্যাক্সেস পেতে পারে। অ্যাকাউন্ট সুরক্ষা সম্পর্কে জানতে ভেরিফিকেশন নিবন্ধটি পড়ুন।
OAuth কি নিরাপদ এবং এর ঝুঁকিগুলো কী কী?
সঠিকভাবে ব্যবহার করলে OAuth নিরাপদ বলে বিবেচিত। টোকেনগুলো সুরক্ষিত চ্যানেলে (HTTPS) প্রেরিত হয়, এগুলোর আয়ু ও ক্ষমতা সীমিত। তবে ঝুঁকিও আছে: টোকেন আটকানো (MITM আক্রমণ), ফিশিং (ভুয়া লগইন পৃষ্ঠা), CSRF আক্রমণ এবং client secret-এর আপস। সুরক্ষার জন্য HTTPS, টোকেনের স্বল্প আয়ু, CSRF-এর বিরুদ্ধে state প্যারামিটার এবং মোবাইল অ্যাপ্লিকেশনের জন্য PKCE ব্যবহার করুন।
OAuth কোথায় ব্যবহৃত হয় এবং কোন কোম্পানিগুলো এটি ব্যবহার করে?
প্রায় সব আধুনিক ওয়েব ও মোবাইল অ্যাপ্লিকেশনে OAuth ব্যবহৃত হয়। «Google দিয়ে লগইন», «Facebook দিয়ে লগইন», «Yandex দিয়ে লগইন», «VKontakte দিয়ে লগইন» বোতামগুলোই OAuth। এছাড়া সার্ভিসগুলোর মধ্যে ডেটা বিনিময়ের জন্য API-তে (যেমন CRM-এর সঙ্গে ইমেইল সার্ভিসের ইন্টিগ্রেশন), কর্পোরেট সিস্টেমে সিঙ্গেল সাইন-অনের (SSO) জন্য এবং IoT ডিভাইসে OAuth ব্যবহৃত হয়। Google, Facebook, GitHub, Microsoft, Yandex, VKontakte-সহ হাজারো সার্ভিস এটি ব্যবহার করে। API কনফিগারেশন সম্পর্কে জানতে ইনফ্রাস্ট্রাকচার নিবন্ধটি পড়ুন।
OAuth ও সিঙ্গেল সাইন-অনের (SSO) মধ্যে পার্থক্য কী?
OAuth হলো একটি অথরাইজেশন প্রোটোকল (আপনার ডেটা দিয়ে কী করা যাবে), আর SSO (Single Sign-On) হলো প্রমাণীকরণের একটি সমাধান (আপনি কে)। SSO একবার লগইনে সব অ্যাপ্লিকেশনে পুনরায় পাসওয়ার্ড ছাড়া অ্যাক্সেস দেয়। OAuth একটি SSO সমাধানের অংশ হিসেবে ব্যবহৃত হতে পারে, তবে এগুলো আলাদা ধারণা। SSO সাধারণত SAML বা OpenID Connect (যা প্রমাণীকরণের জন্য OAuth 2.0 ব্যবহার করে) প্রোটোকলের ওপর ভিত্তি করে গড়া হয়। OAuth ডেটায় অ্যাক্সেস দেয়, আর SSO একাধিক সিস্টেমে লগইন সহজ করে।
Other terms in «তথ্য নিরাপত্তা»
Was this information helpful?
Protect your network today
Leave a request — our information security specialists will help you select, configure and integrate oauth into your infrastructure. We will protect your data from threats.