OAuth 2.0 আর OpenID Connect — delegated access, PKCE আর সাধারণ ভুল

১ · Password ধার দেওয়ার সমস্যা আর চারটি ভূমিকা

ধরুন একটি ক্যালেন্ডার সাজানোর app আপনার email থেকে মিটিংয়ের দাওয়াত পড়তে চায়। পুরোনো দিনে এমন app সরাসরি বলত: “আপনার email-এর password দিন।” ভেবে দেখুন এতে কী কী হয়:

• App পুরো account পায়, শুধু দাওয়াত পড়ার অধিকার নয়। সে mail মুছতে, পাঠাতে, password বদলাতেও পারে।
• App-কে password সেভ করে রাখতে হয়। App-এর database ফাঁস হলে আপনার password-ও ফাঁস।
• একটি app-এর অধিকার তোলার একমাত্র উপায় password বদলানো, আর তাতে অন্য সব app-ও একসাথে বন্ধ হয়।
• MFA চালু থাকলে এই পথ চলেই না, আবার MFA বন্ধ করলে account দুর্বল হয়।

এই ধারণার নাম delegated access: আপনি নিজের অধিকারের একটি ছোট অংশ, নিজের password না দিয়ে, অন্য একটি app-কে ধার দেন। এর চারটি ভূমিকা মুখস্থ না করে ছবিতে দেখুন।

২ · Authorization আর authentication — কেন OAuth একা login নয়

পর্ব ১৫-র ভাষায় authentication মানে “আপনি কে” আর authorization মানে “আপনি কী করতে পারেন”। এই পার্থক্যটিই OAuth নিয়ে সবচেয়ে বড় ভুলের উৎস। OAuth 2.0 তৈরি হয়েছে authorization-এর জন্য। এর token বলে: “এই token-এর ধারক এই API-তে এই কাজগুলো করতে পারে।” Token হাতে থাকা client জানে না মানুষটি কে, এমনকি মানুষটি এই মুহূর্তে উপস্থিত কি না, সেটিও জানে না।

তাহলে “Login with …” বোতামটি কীভাবে চলে? OpenID Connect (OIDC) OAuth 2.0-র ওপরে একটি পরিচয়ের স্তর যোগ করে। একই flow, শুধু client একটি বাড়তি জিনিস পায়: ID token, যা বিশেষভাবে এই client-এর জন্য issuer-এর স্বাক্ষর করা একটি বিবৃতি: “এই মানুষটি এইমাত্র আমার কাছে login করেছেন।”

৩ · Authorization code flow আর PKCE — ধাপে ধাপে

আজকের ডিফল্ট পথ authorization code flow. মূল চালাকি হলো: ব্রাউজারের পথে token নয়, পাঠানো হয় একটি ছোট, এক-বার-ব্যবহারের কোড। আসল token আসে আলাদা, সরাসরি একটি অনুরোধে। ব্রাউজারের ঠিকানা-বার, history আর redirect পথে তাই token পড়ে থাকে না।

কিন্তু কোডটিও তো ব্রাউজারের পথে যায়। কেউ সেটি মাঝপথে পেলে কী হবে? মোবাইল app আর ব্রাউজার app-এ তো গোপন client_secret রাখা যায় না, কারণ কোড ব্যবহারকারীর যন্ত্রে থাকে। এ ধরনের app-কে বলে public client, আর server-এ গোপন রাখতে পারে এমন app-কে confidential client. এখানেই আসে PKCE (RFC 7636, ২০১৫, উচ্চারণ “পিক্সি”).

নিচের উদাহরণে verifier আর challenge RFC 7636-এর প্রকাশিত test vector, বাকি নাম আর ঠিকানা কাল্পনিক।

code_verifier  = dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
code_challenge = BASE64URL(SHA256(code_verifier))
               = E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
state          = state-a1
nonce          = n-7f3a

https://auth.example.com/authorize
  ?response_type=code
  &client_id=toy-app
  &redirect_uri=https://app.example.com/callback
  &scope=openid calendar.read
  &state=state-a1
  &nonce=n-7f3a
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256
(বোঝার সুবিধায় লাইন ভাঙা আর URL-encoding ছাড়া দেখানো)

toy-app চায়:
  ✓ আপনার পরিচয়  (openid)
  ✓ ক্যালেন্ডার পড়া  (calendar.read)
[ অনুমতি দিন ]   [ বাতিল ]
সার্ভারে জমা: code → client_id, redirect_uri,
scope, user, code_challenge

Location: https://app.example.com/callback
  ?code=example-code-123
  &state=state-a1

session-এ জমা state : state-a1
URL-এ আসা state     : state-a1
ফল                  : মিলেছে, জমা মান মুছে ফেলা হলো

POST /token
grant_type=authorization_code
code=example-code-123
redirect_uri=https://app.example.com/callback
client_id=toy-app
code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

BASE64URL(SHA256(verifier))
  = E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM  মিলেছে

{ "access_token":  "example-access-token",
  "token_type":    "Bearer",
  "expires_in":    600,
  "refresh_token": "example-refresh-token",
  "id_token":      "example-id-token" }

GET /v1/events
Host: api.example.com
Authorization: Bearer example-access-token

API যাচাই করে: মেয়াদ, aud = এই API, scope = calendar.read

এবার S256 হিসাবটি সত্যিকারের hashlib দিয়ে করে RFC-র প্রকাশিত মানের সাথে মিলিয়ে নিন।

import base64, hashlib, hmac, secrets

def b64url(raw):
    # base64url, শেষের '=' বাদ (RFC 7636 অনুযায়ী)
    return base64.urlsafe_b64encode(raw).rstrip(b"=").decode("ascii")

def s256(verifier):
    return b64url(hashlib.sha256(verifier.encode("ascii")).digest())

# RFC 7636 Appendix B-র প্রকাশিত test vector, কোনো গোপন মান নয়
octets = [116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125,
          216, 173, 187, 186, 22, 212, 37, 77, 105, 214, 191, 240,
          91, 88, 5, 88, 83, 132, 141, 121]
verifier = b64url(bytes(octets))
expected = "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM"
challenge = s256(verifier)

print("verifier :", verifier)
print("length   :", len(verifier))
print("challenge:", challenge)
print("RFC match:", challenge == expected)

# Token endpoint যা করে: verifier থেকে হিসাব করে তুলনা
def server_check(stored, sent):
    return hmac.compare_digest(stored, s256(sent))

wrong = "x" * 43
print("right verifier accepted:", server_check(challenge, verifier))
print("wrong verifier accepted:", server_check(challenge, wrong))

# বাস্তবে verifier প্রতিবার নতুন আর অনিশ্চিত হয়
fresh = secrets.token_urlsafe(32)
print("fresh verifier length  :", len(fresh))

৪ · Scope, consent আর token-এর জীবনচক্র

Scope হলো client-এর চাওয়া অধিকারের তালিকা, যেমন calendar.read. Consent হলো ব্যবহারকারী বা admin-এর সেই তালিকায় সম্মতি। মনে রাখার মতো একটি সূত্র আছে:

অর্থাৎ scope ব্যবহারকারীর অধিকার বাড়ায় না, শুধু কমায়। সাধারণ কর্মীর token-এ admin.write scope থাকলেও API-কে আলাদাভাবে দেখতে হবে কর্মীটি admin কি না। এটিই least privilege-এর OAuth রূপ (পর্ব ৩, নিরাপত্তার মূলনীতি).

Scope-এর খেলনা হিসাব আর একটি প্রতিষ্ঠানের consent নীতি একসাথে চালিয়ে দেখুন। Scope-এর নাম, ঝুঁকির মাত্রা আর app-গুলো কাল্পনিক।

// খেলনা সিমুলেটর: token কী পারবে, আর consent কোথায় আটকাবে
const risk = { "profile.read": "low", "calendar.read": "low",
  "mail.read": "high", "mail.send": "high",
  "files.readwrite.all": "high", "offline_access": "medium" };

const policy = { userMayGrant: ["low"], verifiedOnly: true };

// কার্যকর অনুমতি = app চেয়েছে ∩ user অনুমোদন করেছে ∩ user নিজে পারেন
const effective = (asked, granted, userCan) =>
  asked.filter(s => granted.includes(s) && userCan.includes(s));

function consent(app) {
  const high = app.scopes.filter(s => risk[s] !== "low");
  if (policy.verifiedOnly && !app.verified)
    return "BLOCK: unverified publisher";
  if (high.length) return "ADMIN REVIEW: " + high.join(", ");
  return "USER MAY CONSENT";
}

const apps = [
  { name: "MeetingPlanner", verified: true,
    scopes: ["profile.read", "calendar.read"] },
  { name: "PDF-Helper", verified: false,
    scopes: ["profile.read", "mail.read", "offline_access"] },
  { name: "ExpenseSync", verified: true,
    scopes: ["profile.read", "files.readwrite.all"] },
];
for (const a of apps) console.log(a.name.padEnd(15), consent(a));

const userCan = ["profile.read", "calendar.read"];
const eff = effective(["profile.read", "calendar.read", "mail.send"],
                      ["profile.read", "mail.send"], userCan);
console.log("effective:", eff.join(", "));
console.log("mail.send allowed:", eff.includes("mail.send"));

Access token আর refresh token

সাধারণ access token একটি bearer token: যার হাতে আছে, সে-ই ব্যবহার করতে পারে, ঠিক নগদ টাকার মতো। তাই RFC 9700 বলে public client-এর refresh token হয় sender-constrained হবে, নয়তো refresh token rotation থাকবে। Rotation-এ প্রতিবার ব্যবহারে নতুন refresh token আসে, আর পুরোনোটি বাতিল হয়। কেউ পুরোনোটি আবার ব্যবহার করলে server বুঝে যায় দুই পক্ষের হাতে একই token আছে, আর পুরো পরিবার বাতিল করতে পারে। এই reuse ঘটনাটি একটি শক্তিশালী detection সংকেত।

৫ · state, nonce আর redirect URI — তিন পাহারাদার

তিনটি মান দেখতে ছোট, কিন্তু প্রতিটি আলাদা ঝুঁকি ঠেকায়। এদের গুলিয়ে ফেলা খুব সাধারণ ভুল।

RFC 9700-এর স্পষ্ট নিয়ম: authorization server হুবহু string মিলিয়ে redirect URI যাচাই করবে। ব্যতিক্রম শুধু native app-এর localhost ঠিকানার port নম্বর। শুরুটা মেলা, wildcard বা “একই domain হলেই চলবে” ধরনের নিয়ম চলবে না, কারণ একই domain-এর কোনো open redirect পাতা বা ভুলে যাওয়া subdomain-ও তখন ফেরার ঠিকানা হয়ে যায়।

নিচের খেলনা server দুই ধরনের যাচাই পাশাপাশি দেখায়, আর client-এর দিকে state একবারই ব্যবহার হওয়া দেখায়। URL-গুলো কাল্পনিক example domain-এর।

// খেলনা authorization server, in-memory ডেটা, কোনো network নেই
const client = { id: "toy-app",
  redirects: ["https://app.example.com/callback"] };
function naivePrefix(uri) {            // অনিরাপদ ধরন
  return uri.startsWith("https://app.example.com");
}
function exactMatch(uri) {             // RFC 9700: exact string match
  return client.redirects.includes(uri);
}
const tests = [
  "https://app.example.com/callback",
  "https://app.example.com/callback/",
  "https://app.example.com.lookalike.example/cb",
  "http://app.example.com/callback",
];
console.log("exact prefix  redirect_uri");
for (const u of tests) {
  const e = exactMatch(u) ? "OK " : "NO ";
  const p = naivePrefix(u) ? "OK " : "NO ";
  console.log(e + "   " + p + "    " + u);
}
// Client-এর দিক: state একবারই মেলে
const pending = { "sess-1": "state-a1", "sess-2": "state-b2" };
function callback(sess, state) {
  const saved = pending[sess];
  if (!saved) return "REJECT: no pending login";
  if (saved !== state) return "REJECT: state mismatch";
  delete pending[sess];                // একবার ব্যবহারের পরে মুছে দিন
  return "ACCEPT: exchange code";
}
console.log("---");
[["sess-1", "state-a1"], ["sess-1", "state-a1"],
 ["sess-2", "state-a1"], ["sess-9", "state-a1"]]
  .forEach(([s, v], i) => console.log(i + 1, callback(s, v)));

৬ · কোন flow কখন — বাদ পড়া পথ আর আজকের পথ

কেন বাদ? Implicit grant-এ access token সরাসরি ব্রাউজারের redirect-এ আসত, ফলে ঠিকানা, history আর referrer-এ পড়ে থাকার ঝুঁকি ছিল, আর token অন্য কেউ বসিয়ে দিলেও client ধরতে পারত না। Password grant-এ তো client আবার password দেখে, যে সমস্যা মেটাতেই OAuth; সাথে MFA বা passkey-র মতো phishing-প্রতিরোধী login-ও এই পথে চলে না (পর্ব ১৬, MFA আর passkey).

RFC 9700 (Best Current Practice for OAuth 2.0 Security, BCP 240, জানুয়ারি ২০২৫) এই নিয়মগুলো লিখিত করেছে: public client-এ PKCE বাধ্যতামূলক, confidential client-এও সুপারিশকৃত, আর authorization server-কে PKCE সমর্থন করতেই হবে। OAuth 2.1 এসব ভালো অভ্যাস একত্র করার একটি খসড়া। অক্টোবর ২০২৬-এর শেষে datatracker-এ এর সর্বশেষ সংস্করণ -17, আর সেটি এখনো Internet-Draft, RFC নয়। এই অবস্থা বদলাতে পারে, তাই IETF datatracker দেখে নিন, আর “OAuth 2.1 standard” কথাটি দেখলে সাবধান হোন।

Client credentials — যেখানে মানুষ নেই

রাতের হিসাব মেলানোর একটি service পেমেন্ট API ডাকছে। এখানে resource owner হিসেবে কোনো মানুষ নেই; client নিজের পরিচয়েই token নেয়। সবচেয়ে বড় ঝুঁকি গোপন মানটি কোডে বা log-এ ফেলে রাখা। ভালো অভ্যাস: secret vault, নিয়মিত key rotation, সম্ভব হলে mTLS বা signed assertion, আর প্রতিটি service-এর আলাদা client ও ছোট scope. বিস্তারিত দেখুন Cloud & DevOps · Secrets আর KMS পর্বে।

Device flow — টিভিতে login

টিভি একটি user_code আর একটি ছোট ঠিকানা দেখায়, যেমন WDJB-MJHT. আপনি ফোনে সেই ঠিকানায় গিয়ে কোডটি দিয়ে login করেন, আর টিভি নির্দিষ্ট বিরতিতে token endpoint-কে জিজ্ঞেস করতে থাকে। উত্তর authorization_pending হলে অপেক্ষা, slow_down হলে বিরতি ৫ সেকেন্ড বাড়ানো।

একটি হিসাব: RFC 8628-এর উদাহরণে ২০টি অক্ষরের ভান্ডার থেকে ৮ অক্ষরের কোড। সম্ভাব্য কোড ২০^৮ = ২৫৬০ কোটি (২.৫৬ × ১০^১০), অর্থাৎ log₂(২০^৮) = ৮ × ৪.৩২ ≈ ৩৪.৬ bit. একটি কোডে মাত্র ৫ বার চেষ্টার সীমা থাকলে এলোমেলো অনুমানে সফল হওয়ার সম্ভাবনা ৫ ÷ (২.৫৬ × ১০^১০) ≈ ১.৯৫ × ১০^−১০, প্রায় ২^−৩২. ছোট কোডের সুরক্ষা তাই rate limit-এর ওপর নির্ভর করে। আসল ঝুঁকি অনুমান নয়: কেউ যদি ব্যবহারকারীকে কোডটি নিজে বসাতে রাজি করায়, তাহলে অন্যের যন্ত্রে login হয়ে যায়। তাই পাতায় স্পষ্ট লেখা থাকা উচিত “আপনি একটি যন্ত্রকে অনুমতি দিচ্ছেন, যন্ত্রটি কি আপনার সামনেই আছে?”

৭ · OpenID Connect — ID token, UserInfo, discovery আর SSO

OIDC-তে client scope-এ openid যোগ করে। বিনিময়ে পায় তিনটি জিনিস:

• ID token: একটি স্বাক্ষরিত JWT (পর্ব ১৭, Session আর token), যার ভেতরে login-এর তথ্য বা claim: কে দিল (iss), কার জন্য (aud), কে login করলেন (sub), কখন (iat), কখন মেয়াদ শেষ (exp). Core spec-এ এই পাঁচটি সব ID token-এ বাধ্যতামূলক।
• UserInfo endpoint: Access token দিয়ে নাম, email ইত্যাদি আনার API. উত্তরের sub ID token-এর sub-এর সাথে হুবহু মিলতে হবে, নইলে সেই তথ্য ব্যবহার করা যাবে না।
• Discovery: Issuer-এর একটি পরিচিত ঠিকানায় থাকা JSON, যা বলে দেয় কোন endpoint কোথায় আর স্বাক্ষরের key কোথায়।

উদাহরণ: discovery document-এর ছোট অংশ (কাল্পনিক issuer, নিজের সিস্টেম কনফিগার করার সময় এমন ফাইল পড়বেন)

{
  "issuer": "https://id.example.com",
  "authorization_endpoint": "https://id.example.com/authorize",
  "token_endpoint": "https://id.example.com/token",
  "userinfo_endpoint": "https://id.example.com/userinfo",
  "jwks_uri": "https://id.example.com/jwks.json",
  "response_types_supported": ["code"],
  "code_challenge_methods_supported": ["S256"],
  "subject_types_supported": ["public"],
  "id_token_signing_alg_values_supported": ["RS256"]
}

এই ফাইল থাকে /.well-known/openid-configuration পথে। jwks_uri-তে থাকে issuer-এর public key-গুলো, যাকে বলে JWKS. Digital signature কীভাবে যাচাই হয় তা পর্ব ১১-তে দেখেছেন (Digital signature আর PKI). এবার একটি ID token ধাপে ধাপে যাচাই করি। মানগুলো খেলনা, ঘড়ি স্থির করা আছে now = 1800000000, প্রত্যাশিত client_id হলো toy-app.

1{"alg":"RS256","kid":"key-a"}2"iss": "https://id.example.com"3"aud": "toy-app"4"sub": "u-1001"5"iat": 17999997006"exp": 18000003007"nonce": "n-7f3a"8"email": "user@example.com"

// খেলনা checker: claim আগে থেকেই decode করা; signature ধরে নেওয়া ফল
const expect = { iss: "https://id.example.com", aud: "toy-app",
                 nonce: "n-7f3a", now: 1800000000, skew: 60 };

function check(t) {
  if (!t.sigOk) return "FAIL signature";
  if (t.iss !== expect.iss) return "FAIL iss";
  const aud = [].concat(t.aud);
  if (!aud.includes(expect.aud)) return "FAIL aud";
  if (aud.length > 1 && t.azp !== expect.aud) return "FAIL azp";
  if (t.exp <= expect.now - expect.skew) return "FAIL exp";
  if (t.iat > expect.now + expect.skew) return "FAIL iat (future)";
  if (t.nonce !== expect.nonce) return "FAIL nonce";
  return "PASS user=" + t.iss + "#" + t.sub;
}

const base = { sigOk: true, iss: expect.iss, aud: "toy-app",
  sub: "u-1001", iat: 1799999700, exp: 1800000300, nonce: "n-7f3a" };

const cases = [
  ["valid token", {}],
  ["bad signature", { sigOk: false }],
  ["other issuer", { iss: "https://id.other.example" }],
  ["made for other app", { aud: "other-app" }],
  ["expired", { exp: 1799999000 }],
  ["replayed nonce", { nonce: "n-old" }],
  ["two audiences", { aud: ["toy-app", "other-app"] }],
  ["two aud + azp", { aud: ["toy-app", "other-app"], azp: "toy-app" }],
];
for (const [name, change] of cases) {
  console.log(name.padEnd(20), check({ ...base, ...change }));
}

SSO, federation আর SAML

SSO (single sign-on) মানে একবার login করে অনেক app-এ ঢোকা। আপনার identity provider (IdP) পরিচয় যাচাই করে, আর app-গুলো তাকে বিশ্বাস করে। Federation মানে সেই বিশ্বাস দুই প্রতিষ্ঠানের সীমানা পার হওয়া, যেমন একটি ব্যাংকের কর্মী নিজের অফিসের login দিয়ে অংশীদার সেবায় ঢোকেন। লাভ অনেক: কম password, এক জায়গায় MFA, কর্মী চলে গেলে এক জায়গায় বন্ধ। দাম হলো blast radius: IdP ভাঙলে সব app-এর দরজা একসাথে খোলা। তাই IdP-র admin account সবচেয়ে কড়া পাহারায় রাখতে হয় (পর্ব ২০, Privileged access), আর phishing-প্রতিরোধী MFA সেখানেই আগে দরকার।

৮ · ডেভেলপারের সাধারণ ভুল আর তার সমাধান

OAuth-এর বেশিরভাগ বাস্তব সমস্যা protocol-এর নয়, ব্যবহারের। নিচের তালিকাটি code review-এর জন্য চেকলিস্ট হিসেবেও কাজে লাগবে।

কীভাবে ধরবেন — detection

Audit log-এ এই ঘটনাগুলো দেখুন, আর SIEM-এ পাঠান: নতুন consent grant, ঝুঁকিপূর্ণ scope, নতুন client নিবন্ধন, redirect URI বদল, refresh token reuse, অচেনা network থেকে token ব্যবহার, আর একটি client-এর হঠাৎ অনেক বেশি ডেটা নামানো। নিচের Sigma-ধাঁচের নিয়মটি ধারণা দেখায়। Log-এর field-এর নাম কাল্পনিক, আপনার IdP-র log অনুযায়ী বদলাতে হবে।

# উদাহরণ: Sigma-ধাঁচের detection, নিজের IdP log-এর জন্য
title: High-risk OAuth scope granted by a non-admin
status: experimental
logsource:
  product: example_idp
  category: oauth_consent
detection:
  selection:
    event_type: consent.granted
    scope|contains:
      - mail.read
      - files.readwrite.all
  filter_admin:
    actor_role: admin
  condition: selection and not filter_admin
falsepositives:
  - Approved app rollout during a change window
level: high

৯ · Consent phishing — password ছাড়াই যখন ক্ষতি

সাধারণ phishing password চায়। Consent phishing অন্য পথে যায়: মানুষকে একটি ক্ষতিকর বা ভুয়া নামের third-party app-কে আসল login পাতাতেই অনুমতি দিতে রাজি করানো হয়। পাতাটি আসল, domain আসল, MFA-ও ঠিকঠাক হয়। ক্ষতিটি আসে স্বয়ং দেওয়া অনুমতি থেকে। ফলে তিনটি সাধারণ প্রতিরক্ষা এখানে সরাসরি কাজ করে না:

• MFA: মানুষ নিজেই login করেছেন, তাই MFA পাস।
• URL দেখা: Consent পাতার ঠিকানা আসলই।
• Password বদলানো: App-এর হাতে আলাদা token আছে। Password বদলালে সেই grant বাতিল হবে কি না, তা provider-ভেদে আলাদা, তাই grant আলাদাভাবে তুলতে হয়।

প্রকাশিত উদাহরণ: মে ২০১৭-তে “Google Docs” নামের একটি ভুয়া তৃতীয় পক্ষের app-এর দাওয়াত email-এ ছড়ায়। সংবাদ ও গবেষকদের প্রতিবেদন অনুযায়ী সেটি password চায়নি, mail আর contact-এর অনুমতি চেয়েছিল। Google app ও account বন্ধ করে, আর পরে app নিবন্ধনে নিয়ম কড়া করে। শিক্ষা: নাম মিলিয়ে নকল ঠেকানো আর প্রকাশক যাচাই দরকার।

নিচে একজন নিরাপত্তা-কর্মীর চোখে একটি app-এর consent পর্যালোচনা। প্রতিষ্ঠান আর app কাল্পনিক। লক্ষ্য হলো পর্যালোচনার অভ্যাস।

App       : PDF-Helper
প্রকাশক    : যাচাই করা নয়
Redirect  : https://pdf-helper.example/cb
বলা কাজ   : PDF জোড়া লাগানো
চাওয়া scope:
  profile.read
  mail.read
  files.readwrite.all
  offline_access

প্রতিরক্ষার তালিকা

• Admin consent নীতি: ব্যবহারকারী শুধু যাচাইকৃত প্রকাশকের কম-ঝুঁকির scope-এ সম্মতি দিতে পারবেন, বাকিটা admin-এর পর্যালোচনায়।
• App allowlist আর নিয়মিত grant পর্যালোচনা: কোন app-এর কাছে কী অনুমতি আছে, তার একটি তালিকা রাখুন। অব্যবহৃত grant তুলে দিন।
• সচেতনতা: “অনুমতি” পাতাও সিদ্ধান্তের জায়গা, শুধু একটি “Next” বোতাম নয় (পর্ব ৫৩, Phishing প্রতিরক্ষা).
• সাড়া দেওয়ার ধাপ: App বন্ধ করা, grant ও token বাতিল, log-এ যা পড়া হয়েছে তা দেখা, ক্ষতিগ্রস্তদের জানানো, ডেটা ফাঁস হলে আইনি বাধ্যবাধকতা দেখা।

Third-party-র হাতে থাকা token নিজেও ঝুঁকি। এপ্রিল ২০২২-এ GitHub জানায়, Heroku আর Travis CI-কে দেওয়া OAuth user token চুরি করে কয়েক ডজন প্রতিষ্ঠানের private repository-র ডেটা নামানো হয়েছে। প্রকাশিত প্রতিবেদন অনুযায়ী GitHub নিজে সরাসরি ভাঙেনি, আঘাত এসেছিল integration-এর পথে। শিক্ষা: ছোট scope, ছোট মেয়াদ, token এনক্রিপ্ট করে রাখা, ব্যবহারের অস্বাভাবিকতায় নজর, আর দ্রুত বাতিলের প্রস্তুতি। এ নিয়ে পর্ব ৭১-এ (Vendor আর third-party ঝুঁকি) আবার আসবে।

১০ · AI-এর যুগে OAuth

AI “Login with …” কোড মিনিটে লিখে দেয়, আর সেটি চলেও। সমস্যা হলো, এখানে “চলা” আর “নিরাপদ হওয়া” এক জিনিস নয়। ভুল যাচাই ছাড়া সব happy-path পরীক্ষা পাস করে। AI-এর পরিচিত ভুলগুলো হলো:

AI-এর লেখা OAuth কোড — যাচাইয়ের চেকলিস্ট

• Flow authorization code + PKCE S256, implicit বা password grant নেই
• Decode নয়, verify হচ্ছে; বদলানো token-এর test ব্যর্থ হয়
• verify=False বা যাচাই বন্ধের কোনো লাইন নেই
• Prompt-এ কোনো আসল secret, token বা ব্যক্তিগত ডেটা দিইনি
• উল্লেখ করা প্রতিটি RFC আর ধারা নিজে খুলে মিলিয়েছি
• Consent বা অনুমতি নিয়ে সিদ্ধান্তে একজন মানুষ থেকেছেন, AI-এর কথায় app অনুমোদন করিনি