OAuth Security: নিরাপদ অথরাইজেশন নিশ্চিত করতে OAuth 2.0 এর সঠিক কনফিগারেশন!

OAuth 2.0 এর secure implementation এর foundation হলো proper grant type selection। RFC 9700 এ এখন শুধুমাত্র দুটি grant types recommend করা হয়: Authorization Code Flow with PKCE এবং Client Credentials Flow। Implicit Flow সম্পূর্ণভাবে deprecated, এবং Resource Owner Password Credentials Flow চরম legacy scenarios ছাড়া ব্যবহার করা উচিত নয়।

Authorization Code Flow এর secure implementation এ multiple security mechanisms থাকে। PKCE (Proof Key for Code Exchange, RFC 7636) এখন সব types এর clients এর জন্য mandatory। Client একটি cryptographically random code_verifier generate করে এবং তার SHA-256 hash কে code_challenge হিসেবে authorization request এ পাঠায়। Token exchange এর সময় code_verifier পাঠাতে হয়, যা code_challenge এর সাথে match করতে হয়।

State Parameter CSRF protection এর জন্য essential। এটি একটি unique, non-guessable value যা client request এ পাঠায় এবং callback এ verify করে। Modern implementation এ state কে session এর সাথে cryptographically bind করা হয়।

Nonce Parameter OpenID Connect এ ID token replay protection এর জন্য ব্যবহৃত হয়। Client একটি random nonce পাঠায় authorization request এ, এবং returned ID token এ সেই nonce included থাকে।

Token Types এর সঠিক বোঝাপড়া critical। Access Tokens সংক্ষিপ্ত জীবনকাল (15 minutes থেকে 1 hour)। Refresh Tokens দীর্ঘ জীবনকাল কিন্তু rotation এর সাথে। ID Tokens (OIDC) JWT format এ user authentication এর proof।

JWT-based Access Tokens সুরক্ষার জন্য RFC 9068 (JWT Profile for OAuth Access Tokens) গুরুত্বপূর্ণ। এই specification এ standard claims define করে: iss, exp, aud, sub, client_id, iat, jti, scope, এবং auth_time।

Sender-Constrained Tokens আধুনিক security architecture এর একটি গুরুত্বপূর্ণ উপাদান। Traditional bearer tokens চুরি হলে যেকেউ ব্যবহার করতে পারে। DPoP (Demonstrating Proof-of-Possession, RFC 9449) এবং mTLS-bound tokens (RFC 8705) এই সমস্যার সমাধান দেয়।

DPoP এ client প্রতিটি request এর সাথে একটি signed JWT পাঠায় যা proves করে তার private key আছে। Server token এ থাকা public key thumbprint check করে verify করে যে request এর sender legitimate।

mTLS-bound Tokens এ TLS client certificate এর সাথে token bind করা হয়। যদি token চুরি হয়, attacker certificate এর private key ছাড়া ব্যবহার করতে পারবে না।

Pushed Authorization Requests (PAR, RFC 9126) আরেকটি modern enhancement। Traditional flow এ authorization request parameters URL এ visible থাকে। PAR এ client first authorization parameters backend channel এ POST করে এবং একটি request_uri পায়, যা front-channel এ ব্যবহার করে।

JWT Secured Authorization Request (JAR, RFC 9101) এ authorization request নিজেই একটি signed JWT হিসেবে পাঠানো হয়, যা integrity এবং authenticity ensure করে।

Resource Indicators (RFC 8707) এ client specify করতে পারে কোন resource server এর জন্য token চাইছে। এতে token misuse reduce হয় কারণ tokens specific audience এর জন্য issued হয়।

OAuth এর secure implementation এর কয়েকটি practical scenario বিবেচনা করা যাক। প্রথমে একটি modern SPA (Single Page Application) এর জন্য secure OAuth setup দেখা যাক।

Frontend application JavaScript এ চালু হয়, যা একটি public client হিসেবে register করা। Backend-for-Frontend (BFF) pattern অনুসরণ করে, frontend শুধু একটি cookie-based session maintain করে নিজস্ব backend এর সাথে, এবং backend OAuth tokens handle করে।

User "Login" button click করে। Frontend backend এ একটি request পাঠায়। Backend একটি secure random state এবং PKCE code_verifier generate করে, session এ store করে। তারপর authorization URL তৈরি করে redirect পাঠায়।

Authorization URL এ থাকে: response_type=code, client_id=spa-bff-client, redirect_uri=https://api.example.com/auth/callback, scope=openid+profile+email, state=random_state, code_challenge=BASE64URL(SHA256(verifier)), code_challenge_method=S256, এবং possibly nonce parameter।

User identity provider এ login করে, consent দেয়, এবং redirect_uri তে redirect হয় authorization code সহ। Backend callback এ state verify করে session এর সাথে, তারপর token endpoint এ POST request পাঠায় code এবং code_verifier সহ।

Token endpoint থেকে access_token, refresh_token, এবং id_token পেয়ে backend সেগুলো server-side storage এ save করে এবং user এর session ID দিয়ে associate করে। Frontend শুধু একটি httpOnly secure cookie পায়। API calls এর সময় backend session থেকে access_token retrieve করে API তে forward করে।

এই architecture এ tokens browser এ কখনো expose হয় না, XSS এর impact সীমিত হয়, এবং token refresh server-side handled হয়।

Mobile application এর জন্য secure implementation আরেকটু ভিন্ন। RFC 8252 (OAuth 2.0 for Native Apps) এ মূল principles বর্ণিত। Mobile apps public client হিসেবে treat করতে হবে এবং PKCE বাধ্যতামূলক।

System browser ব্যবহার করতে হবে authorization এর জন্য, embedded WebView নয়। iOS এ ASWebAuthenticationSession, Android এ Chrome Custom Tabs। Embedded WebView এ phishing risk এবং credential theft সম্ভব।

App-claimed URLs (iOS Universal Links, Android App Links) ব্যবহার করতে হবে redirect_uri হিসেবে। Custom URL schemes (myapp://) hijacking এর শিকার হতে পারে।

Tokens secure storage এ রাখতে হবে - iOS Keychain, Android Keystore। Refresh token rotation enable করতে হবে যাতে প্রতিটি use এ নতুন refresh token issue হয়।

একটি enterprise scenario বিবেচনা করা যাক যেখানে একটি বহুজাতিক কোম্পানি Azure AD ব্যবহার করছে SSO এর জন্য। তাদের internal applications, SaaS services, এবং partner applications সবাই Azure AD দিয়ে authenticate করে।

Azure AD এ application registration এর সময় কিছু critical settings configure করতে হবে। Redirect URIs exact specify করতে হবে। Implicit grant এবং hybrid flows disable করতে হবে। Token configuration এ unnecessary claims remove করতে হবে।

Conditional Access Policies setup করতে হবে। Device compliance, location, risk level এর basis এ access control করা যায়। Multi-factor authentication mandatory করা যায় sensitive applications এর জন্য।

API Permissions principle of least privilege অনুসরণ করতে হবে। Admin consent required for high-privilege scopes। User consent এর জন্য prompt clear এবং understandable হতে হবে।

বাংলাদেশের প্রেক্ষাপটে একটি e-commerce platform এর OAuth implementation বিবেচনা করা যাক। তারা customers দের জন্য "Login with Facebook" এবং "Login with Google" offer করে। Merchant accounts এর জন্য একটি separate OAuth server চালায়।

Customer OAuth flow এ তারা strict redirect_uri validation enforce করে। Production এবং staging environments এর জন্য আলাদা OAuth clients registered। PKCE mandatory করেছে সব mobile apps এর জন্য।

Merchant API access এর জন্য Client Credentials Flow ব্যবহার করে। Each merchant একটি unique client_id এবং client_secret পায়। Secrets vault এ store করা থাকে। API gateway level এ token validation এবং rate limiting enforced।

একটি real-world successful OAuth security implementation এর উদাহরণ Slack। তাদের OAuth implementation security industry এর একটি benchmark। তারা: granular scopes provide করে যেমন chat:write, channels:read; user vs bot tokens আলাদা করেছে; token rotation support করে; admin-level revocation tools provide করে; এবং detailed audit logs maintain করে।

GitHub এর fine-grained personal access tokens এবং OAuth Apps এর granular permissions আরেকটি best practice example। Resource-level permissions, expiration dates, এবং repository-level scoping।

Workload Identity Federation আধুনিক একটি pattern যেখানে static credentials এর পরিবর্তে short-lived tokens ব্যবহার করা হয়। AWS, Azure, GCP সবাই এই concept support করে। OIDC tokens থেকে cloud credentials exchange করা যায়, যা CI/CD pipelines এর জন্য বিশেষভাবে useful।

OAuth 2.0 সুরক্ষিতভাবে deploy করার জন্য একটি comprehensive checklist প্রয়োজন। প্রথমেই Authorization Server (AS) এর hardening। Production AS এর জন্য enterprise-grade Identity Provider যেমন Okta, Auth0, Keycloak, Microsoft Entra ID, বা Google Cloud Identity ব্যবহার করা recommended। নিজস্ব AS লেখা পরিহার করতে হবে যদি absolutely প্রয়োজন না হয়।

Client Registration process এ thorough validation থাকতে হবে। Each client এর জন্য redirect URIs strict whitelist করতে হবে। Client metadata যেমন application name, logo URL, terms of service URL verify করতে হবে। RFC 7591 (Dynamic Client Registration) ব্যবহার করলে registration access tokens দিয়ে protect করতে হবে।

Cryptographic Standards এ modern algorithms ব্যবহার করতে হবে। JWT signing এর জন্য RS256, ES256, বা EdDSA। HS256 শুধুমাত্র যখন client এবং AS shared secret share করতে পারে। Symmetric algorithms এর সাথে public clients এর জন্য কখনো ব্যবহার করা যাবে না।

Key Rotation policy implement করতে হবে। Signing keys regular intervals এ rotate হতে হবে (যেমন প্রতি 90 দিনে)। Multiple active keys simultaneously support করতে হবে smooth rotation এর জন্য। JWKS (JSON Web Key Set) endpoint properly cache করতে হবে কিন্তু stale data avoid করতে হবে।

Token Introspection (RFC 7662) endpoint configure করতে হবে যাতে Resource Servers tokens validate করতে পারে। Token Revocation (RFC 7009) endpoint ও provide করতে হবে।

Refresh Token Security এ rotation mandatory করতে হবে। Each refresh এ নতুন refresh token issue হবে এবং পুরোনোটা invalidate হবে। Refresh token reuse detection enable করতে হবে - যদি পুরোনো refresh token ব্যবহার হয়, পুরো token family revoke করতে হবে (potential theft indicator)।

Scope Design careful planning প্রয়োজন। Granular scopes design করতে হবে - "read", "write", "admin" এর মতো coarse-grained scopes পরিহার করতে হবে। Resource-specific scopes preferred (যেমন "files:read", "calendar:write")।

Consent Screens user-friendly এবং transparent হতে হবে। কোন application কী data access চাইছে তা স্পষ্টভাবে বলতে হবে। Generic descriptions এর পরিবর্তে specific actions list করতে হবে। User কে individual scopes accept/reject করার option দিতে হবে যেখানে possible।

Rate Limiting এবং Brute Force Protection critical। Authorization endpoint এ user-level এবং IP-level limits। Token endpoint এ client-level limits। Failed authentication attempts track করে CAPTCHA challenge বা temporary lockout implement করতে হবে।

Audit Logging comprehensive হতে হবে। Authorization requests, token issuance, token usage, token revocation, consent changes, client modifications সব log করতে হবে। Logs immutable storage এ রাখতে হবে। SIEM integration এর মাধ্যমে real-time analysis।

Monitoring এবং Alerting এ anomaly detection critical। Unusual geographic locations, impossible travel, abnormal scope requests, mass token issuance এর জন্য alerts। Machine learning-based behavioral analytics modern AS গুলোতে available।

Token Storage Best Practices আলাদা ধরনের clients এর জন্য আলাদা: Confidential server-side clients এ secrets HSM বা vault এ; SPAs এ tokens browser memory only, BFF pattern preferred; Native apps এ platform-specific secure storage; CLI tools এ encrypted file storage with proper file permissions।

Token Binding mechanisms ব্যবহার করতে হবে যেখানে support আছে। DPoP modern web এ growing adoption পাচ্ছে। mTLS-bound tokens high-security scenarios এ।

Cross-Origin Resource Sharing (CORS) কঠোরভাবে configure করতে হবে। OAuth endpoints এ origin whitelist থাকতে হবে। Wildcard origins পরিহার করতে হবে।

Software Lifecycle Management এ dependency security critical। OAuth libraries নিয়মিত update করতে হবে। CVE monitoring এবং rapid patching। Software Bill of Materials (SBOM) maintain করতে হবে।

Disaster Recovery Plan এ OAuth-specific scenarios include করতে হবে। Signing key compromise, AS outage, mass token revocation এর procedures pre-defined থাকতে হবে।

Compliance এবং Regulatory Considerations গুরুত্বপূর্ণ। GDPR এর data minimization, right to erasure এর সাথে OAuth scopes align করতে হবে। Financial services এ PSD2, Open Banking এর specific OAuth profiles আছে (FAPI - Financial-grade API)।

FAPI (Financial-grade API) profile high-security scenarios এর জন্য designed। Read-Only এবং Read-Write profiles আছে। Strong client authentication (private_key_jwt, mTLS), PAR mandatory, JAR mandatory, এবং sender-constrained tokens required।

Security Testing programs এ OAuth-specific scenarios include করতে হবে। Bug bounty programs এ OAuth attacks scope এ থাকতে হবে। Regular penetration tests এ OAuth implementation evaluate হতে হবে।

Developer Education ongoing process। OAuth এর rapid evolution এর সাথে keep up করতে training programs প্রয়োজন। Internal workshops, conference attendance, এবং hands-on labs effective।

Documentation comprehensive এবং up-to-date রাখতে হবে। API documentation এ authentication requirements clearly specify করতে হবে। Sample code এবং SDKs provide করতে হবে।