OAuth 2.0 ও OpenID Connect সহজ ভাষায় এবং নিরাপদ বাস্তবায়ন

OAuth 2.0 হলো ডেলিগেটেড authorization-এর framework: এটি ব্যবহারকারীকে পাসওয়ার্ড শেয়ার না করে অন্য সেবায় তার resource-এ অ্যাপকে সীমিত access দিতে দেয়। OpenID Connect (OIDC) হলো OAuth 2.0-এর ওপর পাতলা স্তর যা authentication যোগ করে: এটি আপনার অ্যাপকে জানায় ব্যবহারকারী কে। "Sign in with Google" বাস্তবে OIDC।

এই লেখা মৌলিক ও প্রধান নিরাপদ-বাস্তবায়ন নিয়ম ব্যাখ্যা করে। আসল সিস্টেমে নিজে প্রবাহ লেখার বদলে ভালো রক্ষণাবেক্ষিত library বা identity provider পছন্দ করুন।

মূল পার্থক্য

• Authorization (OAuth 2.0): "এই অ্যাপ আমার ক্যালেন্ডার পড়তে পারবে।" ফল একটি access token।
• Authentication (OIDC): "এই ব্যবহারকারী Alice।" ফল একটি ID token (subject, email ও issuer-এর মতো পরিচয় claim-সহ স্বাক্ষরিত token)।

সাধারণ OAuth access token-কে login-এর প্রমাণ হিসেবে ব্যবহার ক্লাসিক ভুল। ব্যবহারকারী কে জানতে চাইলে OIDC ব্যবহার করুন এবং ID token যাচাই করুন।

ভূমিকা

• Resource owner: ব্যবহারকারী।
• Client: আপনার অ্যাপ্লিকেশন।
• Authorization server (identity provider): ব্যবহারকারী authenticate করে ও token দেয় (যেমন Google, Microsoft, Keycloak, Auth0)।
• Resource server: যে API access token গ্রহণ করে।

সুপারিশ করা প্রবাহ: PKCE-সহ authorization code

ওয়েব অ্যাপ, মোবাইল অ্যাপ ও single-page অ্যাপের জন্য বর্তমান সেরা চর্চা হলো PKCE (Proof Key for Code Exchange)-সহ authorization code flow।

১. আপনার অ্যাপ একটি এলোমেলো code verifier বানায়, তা থেকে code challenge এবং একটি এলোমেলো state মান তৈরি করে ও সংরক্ষণ করে। ২. ব্যবহারকারীর browser-কে authorization server-এ redirect করে: client_id, redirect_uri, response_type=code, scope, state ও code_challenge সহ। ৩. ব্যবহারকারী authorization server-এ (আপনার অ্যাপে কখনো নয়) login করে এবং চাওয়া অনুমতি অনুমোদন করে। ৪. Server স্বল্পস্থায়ী authorization code ও state নিয়ে আপনার redirect_uri-তে ফেরত পাঠায়। ৫. আপনার অ্যাপ state মিলছে দেখে, তারপর code ও code verifier (confidential client হলে client credential-সহ) back end থেকে token endpoint-এ পাঠায়। ৬. এটি access token, প্রায়ই refresh token এবং OIDC-তে ID token পায়। ৭. আপনার অ্যাপ ID token যাচাই করে নিজের session বানায়।

PKCE এমন আক্রমণকারীর কাছে চুরি যাওয়া authorization code অকেজো করে যার verifier নেই। এটি সব client-এর জন্য সুপারিশ করা, server-side-গুলোসহ।

এড়ানোর প্রবাহ

• Implicit flow (URL-এ ফেরত আসা token) নিরুৎসাহিত এবং বর্তমান নির্দেশনায় বাদ।
• Resource owner password credentials প্রবাহ (অ্যাপ নিজে ব্যবহারকারীর পাসওয়ার্ড নেয়) OAuth-এর উদ্দেশ্য নষ্ট করে। এড়ান।

Token ও scope

• Scope কোন access চাওয়া হচ্ছে ঠিক করে (যেমন openid email profile বা calendar.read)। ন্যূনতম চান।
• Access token: স্বল্পস্থায়ী। Authorization: Bearer header-এ API-কে পাঠান। এটিকে secret ধরুন।
• Refresh token: দীর্ঘস্থায়ী, নতুন access token পেতে ব্যবহৃত। অত্যন্ত যত্নে সংরক্ষণ করুন, সমর্থিত হলে rotate করুন এবং logout বা আপসে revoke করুন।
• ID token (OIDC): আপনার client-এর জন্য স্বাক্ষরিত JWT। এটিকে access token হিসেবে API-কে পাঠাবেন না।

সবকিছু যাচাই করুন

ID token পেলে অন্তত যাচাই করুন:

• Provider-এর প্রকাশিত key (JWKS) দিয়ে signature এবং প্রত্যাশিত algorithm।
• iss (issuer) আপনার provider-এর সাথে মেলে।
• aud (audience)-এ আপনার client ID আছে।
• exp পার হয়নি এবং nbf/iat যুক্তিসঙ্গত।
• nonce আপনার পাঠানোটির সাথে মেলে (replay ঠেকায়)।
• ব্যবহারকারী শনাক্ত করতে স্থিতিশীল subject (sub) ও issuer ব্যবহার করুন, শুধু email নয়, কারণ email বদলাতে পারে বা অযাচাই থাকতে পারে।

Access token গ্রহণকারী API-কে token (signature বা introspection), audience, scope ও মেয়াদ যাচাই করতে হবে।

সাধারণ বাস্তবায়ন ভুল (এবং কীভাবে কাজে লাগানো হয়)

state অনুপস্থিত বা অযাচাই। এটি ছাড়া আক্রমণকারী শিকারকে এমন login সম্পূর্ণ করাতে পারে যা আক্রমণকারীর অ্যাকাউন্টে যুক্ত হয়, বা callback জাল করতে পারে (login প্রবাহে CSRF)। সবসময় এলোমেলো state বানান, ব্যবহারকারীর session-এ বাঁধুন এবং যাচাই করুন।

শিথিল redirect_uri যাচাই। Authorization server wildcard বা আংশিক মেলা redirect URI গ্রহণ করলে আক্রমণকারী authorization code বা token নিজের সাইটে redirect করে চুরি করতে পারে। হুবহু redirect URI নিবন্ধন করুন এবং হুবহু মেলান। নিজের ডোমেইনে open redirect অনুমতি দেবেন না।

Public client-এ PKCE না ব্যবহার, যা code ছিনতাইয়ের সুযোগ দেয়।

অযাচাই email বিশ্বাস। email_verified ও issuer যাচাই না করে email claim দিয়ে ব্যবহারকারী যুক্ত বা login করালে অ্যাকাউন্ট দখল হতে পারে। বিভিন্ন provider জুড়ে অ্যাকাউন্ট মেলাতে সাবধান থাকুন।

ID token যাচাই এড়ানো, বা alg: none বা ভুল algorithm গ্রহণ।

URL বা log-এ token রাখা, বা localStorage-এ যেখানে XSS পড়তে পারে। Session সামলাতে HttpOnly, Secure, SameSite cookie এবং বাস্তবসম্মত হলে SPA-তে backend-for-frontend ধরন পছন্দ করুন।

অতি বিস্তৃত scope ও দীর্ঘস্থায়ী token।

OIDC-র বদলে access token-কে পরিচয় প্রমাণ হিসেবে ব্যবহার।

দুর্বল client secret সামলানো। মোবাইল অ্যাপ বা browser কোডে কখনো client secret রাখবেন না। এগুলো public client এবং PKCE-র ওপর নির্ভর করতে হবে।

Logout ও revocation না সামলানো, ফলে session ও refresh token বেঁচে থাকে।

নিরাপত্তা checklist

১. বিশ্বস্ত library বা identity provider-সহ authorization code + PKCE ব্যবহার করুন। ২. হুবহু redirect URI নিবন্ধন করুন, HTTPS ব্যবহার করুন। ৩. state ও nonce বানান ও যাচাই করুন। ৪. ID token যাচাই করুন (signature, issuer, audience, মেয়াদ, nonce)। ৫. ন্যূনতম scope চান, token স্বল্পস্থায়ী রাখুন, refresh token সুরক্ষিত রাখুন। ৬. ব্যবহারকারী শনাক্ত করুন issuer + sub দিয়ে, এবং বিশ্বাসের আগে email যাচাই করুন। ৭. Secret শুধু server-side রাখুন, token নিরাপদে সংরক্ষণ করুন, কখনো log করবেন না। ৮. আপনার API-তে audience ও scope যাচাই করুন। ৯. Revocation ও logout সমর্থন করুন এবং অস্বাভাবিকতা নজরে রাখুন। ১০. Library ও provider configuration হালনাগাদ রাখুন এবং IETF OAuth security best current practice-এর মতো বর্তমান নির্দেশনা অনুসরণ করুন।

কখন কী ব্যবহার করবেন

• সামাজিক বা enterprise login: বিশ্বস্ত provider-সহ OIDC।
• আপনার নিজের অ্যাপ দিয়ে আপনার API access: নিজের authorization server বা managed সেবা সহ OAuth।
• Machine-to-machine: client credentials flow, secret নিরাপদে সংরক্ষিত।
• বাধ্য না হলে নিজের authorization server বানাবেন না। ঠিকভাবে করা কঠিন।

মূল কথা: OAuth 2.0 সীমিত access দেয় আর OIDC পরিচয় প্রমাণ করে। PKCE-সহ authorization code flow ব্যবহার করুন, state, nonce ও ID token যাচাই করুন, হুবহু redirect URI নিবন্ধন করুন, ন্যূনতম scope চান এবং বিস্তারিত বিশ্বস্ত library-কে সামলাতে দিন।

---

ওয়েব নিরাপত্তা সিরিজ, পর্ব ৩ (অ্যাকাউন্ট ও প্রতিরক্ষা): 2 নম্বর (মোট 5)। আগের লেখা: নিরাপদে পাসওয়ার্ড সংরক্ষণ: hashing, salt, bcrypt ও Argon2.