OAuth 2.0, OIDC ও SSO: বাইরের identity ব্যবহার
OAuth 2.0, OIDC, and SSO
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- OAuth authorization ও OIDC identity আলাদা করা
- Authorization code flow-এর trust boundary বোঝা
- External identity securely link করা
সমস্যা দিয়ে শুরু
দোকানে Google login যোগ করতে গিয়ে developer access token-কে user identity ধরে নিয়েছেন। একই email এলেই পুরোনো account link করছেন। OAuth provider ব্যবহার করলেই identity ও account ownership-এর সব প্রশ্ন মিটে যায় না। Callback কোথা থেকে এলো, কোন client-এর জন্য token, verified issuer কে এবং account linking কার অনুমতিতে হচ্ছে—এই boundary ভুল হলে account takeover হতে পারে।
সহজ করে বুঝি
OAuth delegated authorization-এর protocol family; OIDC তার উপর identity layer যোগ করে। Authorization code flow-তে browser redirect শেষে server code exchange করে। OIDC ID token-এর issuer, audience, signature, expiry এবং সংশ্লিষ্ট nonce validate করতে হয়। State login request ও callback সম্পর্কিত করতে সাহায্য করে; PKCE code interception risk কমায়। নিজে token parsing লিখে validation বাদ দেবেন না।
পরিচিত একটি উপমা
কেউ আপনার হয়ে নির্দিষ্ট বই library থেকে তুলতে পারে—এটি delegated permission। Library যদি যাচাইযোগ্য পরিচয়পত্রও দেয়, সেটি identity assertion-এর মতো। বই তোলার permission slip-কে নাগরিক পরিচয়পত্র ধরে নেওয়া ঠিক নয়।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart LR B[Browser] --> A[Laravel login start] A --> I[Identity provider] I --> C[Callback with code] C --> E[Server token exchange] E --> V[Validate provider identity] V --> S[Local session]
Browser provider-এ যায়, provider user interaction শেষে code ফেরত পাঠায়। Laravel server documented client flow দিয়ে token exchange করে। Validated provider subject local identity record-এর সঙ্গে মেলে। তারপর local session তৈরি হয়। Browser থেকে পাঠানো arbitrary email বা decoded token payload এই trust chain-এর বিকল্প নয়।
PHP ও Laravel-এ প্রয়োগ
routes/web.php-তে Laravel Socialite installed এবং supported provider credentials configured ধরে নেওয়া হয়েছে। এটি OAuth login integration, arbitrary OIDC provider validation-এর পূর্ণ implementation নয়। User linking ইচ্ছাকৃতভাবে দেখানো হয়নি; callback-এ validated provider ID unique mapping দিয়ে account policy প্রয়োগ করুন।
use Illuminate\Support\Facades\Route;
use Laravel\Socialite\Facades\Socialite;
Route::get('/login/provider', function () {
return Socialite::driver('github')->redirect();
});
Route::get('/login/provider/callback', function () {
$identity = Socialite::driver('github')->user();
return response()->json(['provider_id' => $identity->getId()]);
});সুবিধা, সীমাবদ্ধতা ও trade-off
Federated login password management কমাতে পারে এবং enterprise SSO সহজ করে। বিনিময়ে provider availability, configuration, account linking এবং incident dependency আসে। Access token যত permission দরকার তত scope নিন। Identity provider login সফল হলেও local user suspended থাকলে session তৈরি করবেন না। Development convenience-এর জন্য state verification বন্ধ রাখা production-এ বিপজ্জনক।
সাধারণ ভুল
- OAuth access token-কে যাচাই ছাড়া identity proof ধরা।
- Email মিললেই existing account নিঃশর্ত link করা।
- Callback state validation বন্ধ করে রাখা।
আরও একটু গভীরে
Stable identity key সাধারণত provider/issuer এবং subject-এর জোড়া। Email mutable এবং provider policy ভিন্ন হতে পারে। Linking sensitive action; existing account reauthentication বা explicit confirmation উপযুক্ত। Logout local session শেষ করতে পারে, upstream provider session আলাদা থাকে। Token encrypted storage, rotation ও least scope policy ঠিক করুন; refresh token application logs-এ যেন না যায়।
মনে রাখুন
Federation-এ protocol validation এবং local account policy আলাদা; provider subject-কে controlled mapping দিয়ে session-এ আনুন।
নিজে চেষ্টা করুন
SSO callback-এর threat model আঁকুন। Invalid state, wrong audience, disabled local account এবং duplicate provider subject-এর expected behavior লিখুন। Provider outage হলে existing local session ও নতুন login কীভাবে আলাদা আচরণ করবে নির্ধারণ করুন।
নিজের বোঝা যাচাই করুন
1. OAuth কি login protocol?
OAuth মূলত delegated authorization। OIDC identity layer দেয়; provider-specific login integration তার documented contract মানে।
2. ID token পেলেই বিশ্বাস?
না। Trusted issuer, audience, signature, expiry ও flow-specific checks করতে হয়। শুধু decode করা validation নয়।
3. Email দিয়ে link বিপদ কেন?
Email mutable বা provider assurance ভিন্ন হতে পারে। Existing account owner-এর explicit linking policy দরকার।
4. State কী করে?
শুরু করা authorization flow ও callback সম্পর্কিত করতে সাহায্য করে। Library state handling নিষ্ক্রিয় করলে গুরুত্বপূর্ণ defense হারায়।
5. Local logout মানে provider logout?
অবশ্যই নয়। দুটি session-এর lifecycle আলাদা; product behavior এবং federation support অনুযায়ী logout design করতে হয়।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।