OAuth 2.0 ও OpenID Connect
- ●OAuth 2.0 হলো delegated authorization— password না দিয়ে এক অ্যাপকে অন্য অ্যাপের সীমিত অ্যাক্সেস দেওয়া।
- ●Authorization Code + PKCE হলো ওয়েব ও মোবাইলের জন্য সবচেয়ে নিরাপদ grant type।
- ●OpenID Connect হলো OAuth-এর উপর বসানো একটি identity layer যা ID token দিয়ে 'কে লগইন করল' তা জানায়।
সমস্যাটা কী?
ধরো একটা নতুন ফটো-প্রিন্টিং অ্যাপ তোমাকে বলল— "তোমার Google Drive-এর ছবিগুলো নিয়ে আসি, প্রিন্ট করে দিই।" এখন তুমি কি তাদের তোমার Google password দিয়ে দেবে? কখনোই না! কারণ password দিলে তারা তোমার Gmail, contacts, সব কিছুতেই ঢুকতে পারবে, এমনকি password বদলেও দিতে পারবে।
তোমার দরকার এমন একটা ব্যবস্থা যেখানে তুমি বলতে পারো— "এই অ্যাপকে শুধু আমার Drive-এর ছবি পড়ার অনুমতি দাও, আর কিছু না, এবং চাইলে যেকোনো সময় এই অনুমতি বাতিল করতে পারি।" ঠিক এই সমস্যাই সমাধান করে OAuth 2.0।
মূল ধারণা
OAuth 2.0 হলো একটি authorization framework যা ব্যবহারকারীকে তার password শেয়ার না করেই এক অ্যাপকে অন্য অ্যাপের সীমিত রিসোর্স অ্যাক্সেসের অনুমতি দেয়— একে বলে delegated authorization।
OAuth-এ চারটি প্রধান চরিত্র থাকে: Resource Owner (তুমি, ইউজার), Client (যে অ্যাপ অ্যাক্সেস চায়, যেমন ফটো-প্রিন্ট অ্যাপ), Authorization Server (যে অনুমতি দেয়, যেমন Google-এর লগইন সার্ভার), এবং Resource Server (যেখানে ডেটা আছে, যেমন Google Drive API)।
গুরুত্বপূর্ণ কথা: OAuth নিজে কিন্তু "লগইন" বা পরিচয়ের জন্য তৈরি হয়নি, এটি authorization-এর জন্য। পরিচয়ের কাজটা করে এর উপরে বসানো OpenID Connect।
কীভাবে কাজ করে
Authorization Code flow
এটিই সবচেয়ে প্রচলিত flow। ধাপগুলো:
- ইউজার client অ্যাপে "Login with Google" চাপে।
- অ্যাপ ইউজারকে Google-এর authorization server-এ পাঠায়, সাথে বলে দেয় কী কী scope চায়।
- Google ইউজারকে লগইন করায় এবং consent screen দেখায়— "এই অ্যাপ তোমার ছবি পড়তে চায়, অনুমতি দেবে?"।
- ইউজার রাজি হলে Google client অ্যাপকে একটা স্বল্পমেয়াদি authorization code দেয়।
- অ্যাপ ব্যাকএন্ড থেকে ওই code আর নিজের client secret দিয়ে Google-এর কাছে access token চায়।
- এই access token দিয়ে অ্যাপ Google Drive API থেকে ছবি নিয়ে আসে।
কেন সরাসরি token না দিয়ে আগে code দেওয়া হয়? কারণ code আসে browser-এর মাধ্যমে (যা কিছুটা অরক্ষিত), কিন্তু token-এর জন্য আসল আদান-প্রদান হয় server-to-server, যেখানে client secret লাগে।
PKCE
মোবাইল ও single-page অ্যাপে client secret গোপন রাখা যায় না। তাই যোগ হয়েছে PKCE (Proof Key for Code Exchange)। অ্যাপ শুরুতে একটা random "code verifier" বানায়, তার hash ("code challenge") পাঠায়। পরে token নেওয়ার সময় আসল verifier দেখাতে হয়। ফলে কেউ code চুরি করলেও verifier ছাড়া token পাবে না।
Token-এর প্রকার
| Token | কাজ | মেয়াদ |
|---|---|---|
| Access Token | API কল করার অনুমতিপত্র | স্বল্প (মিনিট/ঘণ্টা) |
| Refresh Token | নতুন access token আনা | দীর্ঘ (দিন/সপ্তাহ) |
| ID Token (OIDC) | ইউজার কে তা জানানো | লগইন সেশনের জন্য |
OAuth অনেকটা হোটেলের রুম কার্ডের মতো। তুমি reception-এ পরিচয় দিয়ে (Google login) একটা কার্ড নাও। এই কার্ড দিয়ে শুধু তোমার রুম আর জিম খোলে— ম্যানেজারের অফিস নয় (scope)। কার্ডটা কয়েক দিন পর কাজ করা বন্ধ করে দেয় (token expiry), তখন reception থেকে নতুন কার্ড নিতে হয় (refresh token)। আর তুমি কখনো হোটেলকে তোমার বাড়ির চাবি দাও না (password)।
কৌশল
Grant types
- Authorization Code: সার্ভার-সাইড ওয়েব অ্যাপের জন্য আদর্শ। সবচেয়ে নিরাপদ।
- Authorization Code + PKCE: মোবাইল ও SPA-এর জন্য বর্তমান recommended পদ্ধতি।
- Client Credentials: কোনো ইউজার ছাড়াই দুই machine/service-এর মধ্যে যোগাযোগের জন্য।
- Implicit ও Password grant: পুরোনো ও অনিরাপদ, এখন ব্যবহার নিরুৎসাহিত।
Scope
Scope দিয়ে ঠিক করা হয় access token দিয়ে কী কী করা যাবে— যেমন drive.readonly, email, profile। সবসময় যতটুকু দরকার ঠিক ততটুকুই scope চাও (least privilege)।
OpenID Connect (OIDC)
OpenID Connect হলো OAuth 2.0-এর উপর বসানো একটি পাতলা identity layer। OAuth তোমাকে access token দেয় (কী করতে পারবে), কিন্তু ইউজার আসলে কে তা নিশ্চিতভাবে বলে না। OIDC একটি বাড়তি ID Token দেয়— এটি একটি JWT, যাতে ইউজারের ID, email, নাম ইত্যাদি সাইন করা থাকে। তাই "Login with Google" আসলে OIDC ব্যবহার করে, খালি OAuth নয়।
কখন ব্যবহার করবে / করবে না
তৃতীয় পক্ষের সাথে নিরাপদে অ্যাক্সেস শেয়ার করতে বা "social login" দিতে হলে OAuth/OIDC ব্যবহার করো। নিজের একক অ্যাপে শুধু ইউজার লগইনের জন্য পুরো OAuth জটিল মনে হতে পারে, তবে চেনা provider (Auth0, Google) ব্যবহার করলে নিরাপত্তা ও সুবিধা দুটোই মেলে।
নিজে নিজে OAuth সার্ভার implement করতে যেও না। token validation, PKCE, refresh rotation, redirect URI যাচাই— এসবে ছোট ভুলেও বড় নিরাপত্তা ফাঁক তৈরি হয়। পরীক্ষিত library বা provider ব্যবহার করো। আর কখনো access token URL-এ বা log-এ রেখো না।
বাস্তব উদাহরণ
Spotify ব্যবহার করো? অনেকে Spotify-তে "Login with Facebook/Google" দিয়ে ঢোকে— এটি OIDC। আবার Spotify তোমাকে third-party অ্যাপের (যেমন একটা playlist analyzer) সাথে যুক্ত হতে দেয় OAuth দিয়ে: ওই অ্যাপ তোমার playlist পড়ার access token পায়, কিন্তু তোমার password বা card তথ্য পায় না। তুমি যেকোনো সময় Spotify-র settings থেকে সেই access বাতিল করতে পারো— এটাই delegated authorization-এর সৌন্দর্য।
ইন্টারভিউতে OAuth আর OIDC গুলিয়ে ফেলো না— এটি একটি ক্লাসিক ফাঁদ। মনে রাখো: "OAuth = authorization (অ্যাক্সেস), OIDC = authentication (পরিচয়), আর OIDC বসে OAuth-এর উপরে।" Authorization Code + PKCE কেন আজকের standard— সেটা ব্যাখ্যা করতে পারলে তুমি এগিয়ে থাকবে।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. OAuth 2.0 মূলত কী সমাধান করে?
2. Refresh token-এর কাজ কী?
3. OIDC, OAuth-এর তুলনায় বাড়তি কী যোগ করে?