OAuth কি? OAuth কিভাবে কাজ করে?

OAuth কি?

OAuth যা Open-standard authorization এর একটি সংক্ষিপ্ত রূপ। এটি একটি protocol বা framework যা এক এপ্লিকেশন থেকে অন্য এপ্লিকেশনে “সিকিউরিটি বজায় রেখে” প্রবেশের সুযোগ প্রদান করে। উদাহরণস্বরূপ, আপনি facebook কে বলতে পারেন যে ESPN.com কে আপনার পাসওয়ার্ড না দিয়েই যেন আপনার প্রোফাইল এবং টাইমলাইনে প্রবেশের অনুমতি প্রধান করে। অর্থাৎ ফেসবুকের মাধ্যমে espn.com এ ফেসবুক ব্যবহারকারীর পাসওয়ার্ড না দিয়েই লগিনের সুযোগ। আর এই পদ্ধতিতে আমরা আমাদের লগিনের তথ্য গুলোর বেহাত হওয়ার ঝুঁকি হ্রাস করতে পারি। এমনকি কখনো যদি ESPN.com নিজেই হ্যাক হয়ে যায় , তবুও আপনার ফেসবুকের পাসওয়ার্ডটি নিরাপদ থাকবে।

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

বর্তমানে আপনি Oauth ব্যবহার করে একইসাথে Web application, Desktop Application এবং Mobile ডিভাইস এর authorization এর কাজ করতে পারেন।

বর্তমানে OAuth এর ভার্সন ২ অর্থাৎ OAuth 2 বিদ্যমান। OAuth 2 নিয়ে কাজ করতে হলে আপনাকে OAuth 2 roles, authorization grant types, use cases, এবং flow গুলো সম্পর্কে বিস্তারিত জানতে হবে।

তাহলে চলুন প্রথমে OAuth Roles দিয়ে শুরু করা যাক!

OAuth2 তে চারটি roles রয়েছে :

• Resource Owner
• Client
• Resource Server
• Authorization Server

নিচে আমরা সবগুলো roles নিয়ে বিস্তারিত আলোচনা করব।

Resource Owner: User

Resource owner হলেন এমন ব্যবহারকারী যিনি কোনও application কে তার নিজের একাউন্টে অ্যাক্সেস করার অনুমতি দেন। ইউজার অ্যাকাউন্টে অ্যাপ্লিকেশনটির অ্যাক্সেস অনুমোদিত অনুমোদনের “সুযোগ” সীমাবদ্ধ করা। (e.g. read অথবা write access) এর অনুমোদন দেওয়া।

Resource / Authorization Server: API

রিসোর্স সার্ভারটি protected user account গুলিকে হোস্ট করে এবং authorization server ইউজারের পরিচয় যাচাই করে, তারপরে অ্যাপ্লিকেশনটিতে অ্যাক্সেস টোকেনগুলি সরবরাহ করে।

application developer দের দৃষ্টিকোণ থেকে, একটি service API একই সাথে resource এবং authorization server প্রয়োজনীয়তা পূরণ করে। আমরা Service বা API ভূমিকা হিসাবে সম্মিলিত এই উভয় ভূমিকা উল্লেখ করব।

Client: Application

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

Abstract Protocol Flow

এতক্ষনে OAuth এর roles কী তা সম্পর্কে আপনার ধারণা হয়েছে, তাহলে চলুন দেখা যাক, কিভাবে OAuth এর মাধ্যমে কীভাবে তারা একে অপরের সাথে ইন্টারঅ্যাক্ট করে তার একটি চিত্র দেখি:

যদিও উপরোক্ত ফ্লো টি একটি জেনারেল আইডিয়া , তাই authorization grant type এর উপর ভিত্তি করে এই প্রসেস এর আসল ফ্লো ভিন্ন হতে পারে। পরবতীতে আমরা বিভিন্ন grant type গুলো নিয়ে আলোচনা করব।

Application Registration

আপনার application এ OAuth ব্যবহারের পূর্বে , আপনাকে অবশ্যই প্রথমে আপনার application কে OAuth service টির সাথে রেজিস্ট্রেশন করতে হবে। আর আপনাকে এই কাজ টি আপনি যেখান থেকে সার্ভিস টি নিবেন (যেমন গুগল অথবা ফেইসবুক) এর “developer” অথবা “API” অংশে রেজিস্ট্রেশন করতে হবে। এবং সেখানে আপনার বিস্তারিত তথ্য দিতে হবে। আর এইটা সাধারণত নিম্নোক্ত তথ্য দিয়ে করতে হয়।

1. Application Name
2. Application Website
3. Redirect URI or Callback URL

আর এখানে তিন নম্বর অর্থাৎ Redirect URI or Callback URL মানে হচ্ছে আপনি authorization সাকসেস হলে কোথায় রিডাইরেক্ট করবেন এবং authorization ফেল হলে কথা কোথায় রিডাইরেক্ট হবে তার লিংক দিবেন।

Client ID এবং Client Secret

আপনার এপ্লিকেশন যখন একবার registered হয়ে যাবে, তখন সার্ভিসটি ফর্মে client identifier এবং client secret হিসেবে “client credentials” গুলো ইসু করবে। আর এখানে Client ID টি একটি পাবলিক স্ট্রিং , যা একটা application কে সনাক্ত করার জন্য service API এর মাধ্যমে ব্যবহৃত হয়। এবং ইউজার কে দেওয়ার জন্য একটা authorization URL তৈরির জন্য ব্যবহৃত হয়। অন্যদিকে Client Secret টি যখন application request গুলো ইউজারদের একাউন্ট এ একসেস করে, তখন service API তে application এর আইডেন্টিটি কে অথেন্টিকেট করার জন্য ব্যবহৃত হয়।

Authorization Grant

উপরের Abstract Protocol Flow তে লক্ষ্য করবেন , প্রথম চারটি স্টেপ authorization grant এবং access token পাওয়ার জন্য ব্যবহৃত হয়ে হয়েছে। authorization grant type গুলো application এ ব্যবহৃত authorization request এর মেথডের উপর ডিপেন্ড করে। আর grant type গুলো API দ্বারা সাপোর্টেড। OAuth 2 চার ধরণের grant type support করে। এবং প্রত্যেকটি ভিন্ন ভিন্ন কেস এ খুবই দরকারি।

• Authorization Code: এটি সার্ভার সাইড এর এপ্লিকেশন এর জন্য ব্যবহৃত হয়।
• Implicit: এটি সাধারণত ব্যবহার কারীর ডিভাইসে ব্যবহৃত Mobile Apps অথবা Web Applications এর জন্য ব্যবহৃত হয়।
• Resource Owner Password Credentials: এটি সাধারণত ব্যবহারকারীর নিজস্ব এপ্লিকেশন এর জন্য ব্যবহৃত হয়।
• Client Credentials: এটি Applications API access এর জন্য ব্যবহৃত হয়।

Grant Type: Authorization Code

authorization code grant type সবচাইতে বেশি ব্যবহৃত হয়। কারণ এটি server-side application গুলোর জন্য optimized . যেখানে source code গুলো পাবলিক করা থাকেনা এবং ক্লায়েন্ট এর সিক্রেট গোপনীয়তা বজায় রাখে।

এটি একটি redirection-based flow বা পুনর্নির্দেশ-ভিত্তিক flow, যার অর্থ এই যে অ্যাপ্লিকেশনটি অবশ্যই user-agent এর সাথে (অর্থাৎব্যবহারকারীর ওয়েব ব্রাউজার) ইন্টারঅ্যাক্ট করতে এবং user-agent এর মাধ্যমে API authorization কোডগুলি গ্রহণ করতে সক্ষম হতে পারে।

নিচে Authorization Code এর flow লক্ষ্য করুন।

স্টেপ -১: Authorization Code Link

প্রথমত, ইউজার কে একটি authorization code লিঙ্ক দেওয়া হয় যা দেখতে ঠিক নিচের মতো:

https://example.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

নিম্নে লিঙ্ক component গুলির ব্যাখ্যা দেওয়া হলো:

• https://example.com/v1/oauth/authorize: এটি API authorization এর endpoint
• client_id=client_id: এটি হচ্ছে এপ্লিকেশন এর ক্লায়েন্ট আইডি ( অর্থাৎ, কিভাবে API টি application এ আইডেন্টিফাই হবে।)
• redirect_uri=CALLBACK_URL: অর্থাৎ , যখন authorization code টি গ্র্যান্টেড হবে , তখন user-agent বা ব্রাউজার কোথায় রিডাইরেক্ট হবে , সেই URL
• response_type=code: অর্থাৎ , আপনার অ্যাপ্লিকেশন একটি authorization code grant অনুরোধ করছে
• scope=read: অর্থাৎ , অ্যাপ্লিকেশন যে অনুরোধ করছে তার একটি level of access বা অ্যাক্সেসের স্তর নির্দিষ্ট করে

স্টেপ ২: User Authorizes Application

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



স্টেপ ৩: Application Receives Authorization Code

যদি ইউজার “Authorize Application” এ ক্লিক করে , তখন সার্ভিসটি user-agent বা ব্রাউজারে application redirect URI তে রিডাইরেক্ট করবে, যেটি client registration এর সময় authorization code সহ সেট করে দেওয়া হয়েছিল। আর রিডাইরেক্ট টা অনেকটা নিচের মতো হবে।

https://example.com/callback?code=AUTHORIZATION_CODE

স্টেপ ৪: Application Requests Access Token

Application Requests Access Token টি তে authorization code সাথে authentication details এবং client secret সহ API এর সব কিছু থাকে। নিচের উদাহরণটি দেখা যাক :

https://example.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

স্টেপ ৫: Application Receives Access Token

যদি authorization টি ভ্যালিড হয় , তখন API নিচের মতো করে একটা রেসপন্স টোকেন পাঠাবে।

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Mr Demo","email":"demo@example.com"}}

এখন যদি application টি authorize হয়ে যাবে! তাহলে টোকেনটির expire না হওয়া বা প্রত্যাহার না করা পর্যন্ত Service API এর মাধ্যমে ইউজারদের অ্যাকাউন্টে অ্যাক্সেসের জন্য এটি টোকন ব্যবহার করতে পারে। যদি একটি রিফ্রেশ টোকেন ইসু করা হয়, তখন মূল টোকেনটির মেয়াদ শেষ হয়ে গেলে এটি নতুন অ্যাক্সেস টোকেনগুলির জন্য অনুরোধ করতে ব্যবহৃত হতে পারে।

Grant Type: Implicit

implicit grant type টি mobile apps এবং web application গুলোর জন্য ব্যবহৃত হয়। যেখানে ক্লায়েন্টের গোপনীয়তার কোনো নিশ্চয়তা নেই। implicit grant type ও একটি redirection-based flow, কিন্তু এপ্লিকেশন ফরওয়ার্ড করার জন্য একসেস টোকেনটি দেওয়া হবে user-agent বা সংশ্লিষ্ট ব্রাউজার কে। সুতরাং এটি ইউজারের কাছে প্রকাশিত হবে এবং ইউজারদের ডিভাইস এর অন্যান্য এপ্লিকেশন এ। এবং এই ফ্লো টি এপ্লিকেশন এর আইডেন্টিটি অথেনটিকেট করেনা। এবং এই ধরণের পারপাস সার্ভ করার জন্য redirect URI এর উপর ভরসা করে।

implicit grant type refresh token সমূহ সাপোর্ট করেনা।

implicit grant flow সাধারণতঃ অনেকটা এই রকম একটা পদ্ধতি ফলো করে , অর্থাৎ একজন ইউজার যখন একটা application কে authorize করার জন্য জিজ্ঞেস করে , তখন authorization server টি অ্যাক্সেস টোকেনটি ব্যবহারকারী-এজেন্টকে ফেরত দেয়। নিচের ছবিটি লক্ষ্য করুন :



স্টেপ ১: Implicit Authorization Link

implicit grant type দিয়ে ইউজারকে একটা authorization link দিয়ে প্রেজেন্ট করে। যা API থেকে টোকেন কে রিকোয়েস্ট করে। এটা অনেকটা authorization code link এর মতো। এ ছাড়া এটি কোডের পরিবর্তে একটা টোকেনকে রিকোয়েস্ট করে।

https://example.com/v1/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

স্টেপ ২: User Authorizes Application

যখন একজন ইউজার লিংকে ক্লিক করে , তার জন্য তাকে তার আইডেন্টিটি অথেন্টিকেট করার জন্য প্রথমে সার্ভিসে লগইন করতে হয়। তখন তাদেরকে সার্ভিস তার একাউন্ট এ অথোরাইজ অথবা ডিনাই করার জন্য প্রশ্ন করে। অনেকটা নিচের মতো :



স্টেপ ৩: User-agent একটি Redirect URI সহ Access Token রেসিভ করবে।

যদি ইউজার “Authorize Application” এ ক্লিক করে, সার্ভিস টি user-agen থেকে application এ access token সহ রিডাইরেক্ট করবে। এটা অনেকটা এই রকম:

https://yourapps.com/callback#token=ACCESS_TOKEN

স্টেপ ৪: User-agent, Redirect URI কে ফলো করবে।

User-agent, Redirect URI কে ফলো করবে তবে access token কে ধরে রাখবে।

স্টেপ ৫: এপ্লিকেশন Access Token Extraction Script কে পাঠায়

এপ্লিকেশন টি একটা ওয়েবপেজ কে রিটার্ন করে , যা একটি স্ক্রিপ্ট ধরে রাখে , তারপর access token যেটি ধরে রেখেছিলো , সেটি full redirect URI থেকে access token কে extract করে।

স্টেপ ৬: Application এ Access Token Pass

এই পর্যায়ে user-agent কে দেওয়া script কে সে এক্সেকিউট করে। এবং extracted access token কে এপ্লিকেশন এ পাঠায়।

এবার application টি authorize হয়ে যাবে। তবে এটি টোকেনটির মেয়াদ শেষ না হওয়া বা প্রত্যাহার না করা পর্যন্ত সার্ভিস এ পি এই এর মাধ্যমে ইউজার একাউন্ট এ এক্সেস এর জন্য টোকেন ব্যবহার করতে পারে।

Grant Type: Resource Owner Password Credentials

resource owner password credentials grant type এ ইউজার সে নিজের username এবং password সহ তার service credential গুলো সরাসরি application কে provide করে। যা এই ক্রেডেনটিয়ালস গুলো ব্যবহার করে সার্ভিসে এক্সেস করার একটা টোকেন দিয়ে থাকে। আর তাই যদি অন্যান্য ফ্লো গুলো টেকসই না হয় , তাহলে grant type শুধু মাত্র authorization server এর জন্যই এনাবল থাকা উচিত। এছাড়াও এটি ইউজার নিজে বা একান্ত পরিচিত কেও শুধু ব্যবহার করা উচিত।

Password Credentials Flow

যখন ইউজার তার ক্রেডেনটিয়ালস গুলো এপ্লিকেশন এ দেয় , তখন এপ্লিকেশন authorization server.থেকে একটা এক্সেস টোকেন রিকোয়েস্ট করে। আর POST রিকোয়েস্ট টি অনেকটা এই রকম।

https://example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

যদি application credential গুলো যাচাই হয়ে যায় , তখন authorization সার্ভার application এ একটা এক্সেস টোকেন রিটার্ন করে। আর তখন application নিজের একাউন্ট ব্যবহারের অনুমোদিত হয়।

Grant Type: Client Credentials

client credentials grant type, application এ এমন এক পদ্ধতি দেয় , যেন সে নিজের service account এ এক্সেস করতে পারে। উদাহরণ স্বরূপ বলা ,যায় আপনার নিজের এপ্লিকেশন এ api এর মাধ্যমে বিভিন্ন ডাটা পরিবর্তন করতে পারেন।

Client Credentials Flow

যখন application নিজের credential গুলো অর্থাৎ client ID এবং client secret গুলো সহ authorization server এ পাঠানোর মাধ্যমে access token কে রিকোয়েস্ট করে , অর্থাৎ অনেকটা এই রকম।

https://example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

যদি application credential গুলো যাচাই হয়ে যায় , তখন authorization সার্ভার application এ একটা এক্সেস টোকেন রিটার্ন করে। আর তখন application নিজের একাউন্ট ব্যবহারের অনুমোদিত হয়।

Masud Alam



আমি মাসুদ আলম, বাংলাদেশের ৩৬ তম Zend Certified Engineer । ২০০৯ সালে কম্পিউটার সাইন্স থেকে বেচেলর ডিগ্রী অর্জন করি। দীর্ঘ ১৫ বছর আমি Winux Soft, SSL Wireless, IBCS-PRIMAX, Max Group, Canadian International Development Agency (CIDA), Care Bangladesh, World Vision, Hellen Keller, Amarbebsha Ltd সহ বিভিন্ন দেশি বিদেশী কোম্পানিতে ডেটা সাইন্স, মেশিন লার্নিং, বিগ ডেটা, ওয়েব ডেভেলপমেন্ট এবং সফটওয়্যার ডেভেলপমেন্ট এর উপর বিভিন্ন লিডিং পজিশন এ চাকরি এবং প্রজেক্ট লিড করি। এছাড়াও বাংলাদেশের ১৮৫ জন জেন্ড সার্টিফাইড ইঞ্জিনিয়ার এর মধ্যে ১২০ এরও অধিক ছাত্র আমার হাতে জেন্ড সার্টিফাইড ইঞ্জিনিয়ার হয়েছেন। বর্তমানে w3programmers ট্রেনিং ইনস্টিটিউট এ PHP এর উপর Professional এবং Advance Zend Certified PHP -8.2 Engineering, Laravel Mastering Course with ReactJS, Python Beginning To Advance with Blockchain, Machine Learning and Data Science, Professional WordPress Plugin Development Beginning to Advance কোর্স করাই। আর অবসর সময়ে w3programmers.com এ ওয়েব টেকনোলজি নিয়ে লেখালেখি করি।