Social login — OAuth flow বাস্তবে আর auth library

১ · Provider পরিচয় জানায়, session আপনার

বাজারঘরে এখন password দিয়ে login চলে (পর্ব ৪৫, Session-ভিত্তিক login). কিন্তু ক্রেতারা বলছেন, “আরেকটি password মনে রাখতে পারব না, Google দিয়ে ঢুকতে দিন।” এটিই social login: একটি বাইরের সেবা, যাকে বলে identity provider বা শুধু provider, মানুষটিকে চিনিয়ে দেয়, আর আপনি password রাখা থেকে বেঁচে যান।

তত্ত্ব এখানে আবার শেখাব না। OAuth 2.0-র চার ভূমিকা, কেন OAuth একা login নয়, PKCE-র ধারণা, আর consent phishing পড়ুন Cybersecurity কোর্সের OAuth আর OpenID Connect পর্বে। দুই লাইনে মনে করিয়ে দিই: OAuth অধিকার দেয়, আর OpenID Connect (OIDC) তার ওপরে বলে “মানুষটি কে”। এই পর্বে আমরা সেই flow নিজের অ্যাপে বানাব।

এই গল্পের সবচেয়ে দরকারি বাক্য: login-এর শেষ ধাপে আপনার অ্যাপ নিজের session বানায়। তারপর পর্ব ৪৫-এর সব নিয়মই চলে: cookie, store, logout. তাই ছবিতে দুটি আলাদা session আছে, আর দুটি আলাদা পথ।

কেন নিজে session বানাবেন, provider-এর token রেখে দিলে হয় না? কারণ তিনটি। Access token আপনার অ্যাপের জন্য বানানো নয়, provider-এর API-র জন্য। ID token-এর মেয়াদ provider ঠিক করে, আপনি নন। আর logout, role, “সব ডিভাইস থেকে বের করুন”, এগুলো আপনার নিজের নিয়ম। Provider একবার পরিচয় জানায়, বাকি জীবন আপনার।

২ · Lab: আসল provider, নকল মানুষ

এই পর্বে Google-এর কোনো আসল account ব্যবহার হয়নি, আর আসল Google-এ login করা এখানে দেখানোও হয়নি। তার বদলে আমরা নিজের মেশিনে একটি সত্যিকারের OIDC server চালিয়েছি: npm-এর oidc-provider. এটি কোনো খেলনা নয়, মান মেনে চলা একটি সম্পূর্ণ implementation. ব্যবহারকারীরা নকল, password-ও নকল, আর সব চলেছে 127.0.0.1-এ। Edge-কে Playwright চালিয়েছে, তাই redirect-গুলো আসল ব্রাউজারে আসল HTTP-তেই ঘটেছে।

কোডটি (log আর মেয়াদের লাইন বাদে):

// শুধু শেখার lab: নকল ব্যবহারকারী, 127.0.0.1
import Provider from 'oidc-provider';

const users = {
  'idp-1001': { email: 'rahim@bazarghar.test', email_verified: true,  name: 'Rahim Test' },
  'idp-1002': { email: 'karim@bazarghar.test', email_verified: false, name: 'Karim Test' },
  'idp-1003': { email: 'salma@bazarghar.test', email_verified: true,  name: 'Salma Test' },
  'idp-1004': { email: 'nadia@bazarghar.test', email_verified: true,  name: 'Nadia Test' },
};

const provider = new Provider('http://localhost:47401', {
  clients: [{
    client_id: 'bazarghar-local',
    client_secret: 'example-client-secret-not-real',
    redirect_uris: ['http://localhost:47402/auth/callback'], // পরে আরও একটি
    grant_types: ['authorization_code'],
    response_types: ['code'],
  }],
  claims: { openid: ['sub'], email: ['email', 'email_verified'], profile: ['name'] },
  findAccount: async (ctx, id) => {
    const u = users[id];
    if (!u) return undefined;
    return { accountId: id, claims: async () => ({ ...u }) };
  },
  cookies: { keys: ['example-cookie-key-not-real'] },
});
provider.listen(47401, '127.0.0.1');

চালু করতেই সে নিজে তিনটি সতর্কবার্তা দিল (সত্যিকারের run, হুবহু). এগুলো পড়ে রাখুন, কারণ production-এ কী কী বদলাতে হয়, তার তালিকা এটিই:

oidc-provider WARNING: a quick start development-only in-memory adapter is used, you MUST change it …
oidc-provider WARNING: quick start development-only signing keys are used, you are expected to provide your own …
oidc-provider WARNING: a quick start development-only feature devInteractions is enabled, you are expected to disable these …

Discovery আর JWKS: হাতে URL লিখতে হয় না

Discovery মানে provider-এর ঠিকানার পরে /.well-known/openid-configuration বসালে একটি JSON পাওয়া যায়, যাতে সব endpoint লেখা। Library এটি একবার পড়ে নেয়, তাই আপনি শুধু issuer-এর ঠিকানা দেন। আমাদের server-এর আসল উত্তর (ট্রিম করা):

{
 "issuer": "http://localhost:47401",
 "authorization_endpoint": "http://localhost:47401/auth",
 "token_endpoint": "http://localhost:47401/token",
 "userinfo_endpoint": "http://localhost:47401/me",
 "jwks_uri": "http://localhost:47401/jwks",
 "code_challenge_methods_supported": ["S256"],
 "id_token_signing_alg_values_supported": ["RS256"],
 "authorization_response_iss_parameter_supported": true,
 …
}

দেখুন, token endpoint এখানে /token, কিন্তু UserInfo /me, আর authorize /auth. অন্য provider-এ নাম অন্য হবে। হাতে URL লিখলে provider বদলালেই কোড ভাঙে, discovery থাকলে ভাঙে না।

jwks_uri-তে থাকে provider-এর public key. ID token একটি স্বাক্ষর করা JWT, যার ভেতরের তথ্যকে বলে claim. এর header-এ লেখা থাকে কোন key দিয়ে স্বাক্ষর হয়েছে (kid), আর library সেই key এনে স্বাক্ষর মেলায়। Provider key বদলালেও আপনার অ্যাপ বদলাতে হয় না, এটিই JWKS-এর সুবিধা। আসল run:

jwks             [{"kty":"RSA","kid":"keystore-CHANGE-ME","alg":"RS256","use":"sig","n":"xwQ72P9z9OYs..."}]
id_token header  {"alg":"RS256","kid":"keystore-CHANGE-ME"}

৩ · একটি login-এর পুরো পথ

কোড লেখার আগে ছবিটি মাথায় বসিয়ে নিই। এই flow-র নাম Authorization Code flow, কারণ ব্রাউজারের পথে আসে একটি ছোট কোড, token নয়। Login শুরুর সময় অ্যাপ তিনটি এলোমেলো মান বানায়। প্রতিটির কাজ আলাদা, আর তিনটিই থাকে এই ব্রাউজারের session-এ।

এবার PKCE-র হিসাবটি নিজে চালান। এটি আসল SHA-256. প্রথম লাইনে আমরা RFC 7636-এর প্রকাশিত নমুনা দিয়ে নিজের কোড মিলিয়ে নিয়েছি, যা একটি ভালো অভ্যাস।

const { createHash, randomBytes } = require('node:crypto');

// S256: BASE64URL(SHA-256(verifier))
function challengeOf(verifier) {
  const digest = createHash('sha256').update(verifier, 'ascii').digest();
  return digest.toString('base64url');
}

// RFC 7636-এর প্রকাশিত নমুনা দিয়ে নিজের কোড যাচাই
const rfcV = 'dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk';
const rfcC = 'E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM';
console.log('rfc vector ok :', challengeOf(rfcV) === rfcC);

// প্রতি login-এ নতুন verifier: ৩২ byte এলোমেলো
const verifier = randomBytes(32).toString('base64url');
const challenge = challengeOf(verifier);
console.log('verifier len  :', verifier.length);
console.log('challenge len :', challenge.length);
console.log('allowed chars :', /^[A-Za-z0-9._~-]{43,128}$/.test(verifier));

// শেষ অক্ষর বদলালে কী হয়
const last = verifier.at(-1) === 'A' ? 'B' : 'A';
const wrong = verifier.slice(0, -1) + last;
console.log('wrong matches :', challengeOf(wrong) === challenge);
console.log('right matches :', challengeOf(verifier) === challenge);

এবার পুরো পথটি ধাপে ধাপে দেখুন। মানগুলো ছোট করে দেখানো, কিন্তু ধাপ, পথ আর status আমাদের আসল Edge run-এর।

req.session.oidc = {
  codeVerifier: "Xk2…(৪৩ অক্ষর)",
  state:        "aT9…",
  nonce:        "mQ4…"
}

GET localhost:47401/auth
  ?client_id=bazarghar-local
  &response_type=code
  &redirect_uri=…/auth/callback
  &scope=openid email profile
  &code_challenge=…&code_challenge_method=S256
  &state=aT9…  &nonce=mQ4…

Login: idp-1001
Password: ••••••••  (নকল, lab-এর)
বাজারঘর এই পাতা দেখে না, password-ও পায় না

bazarghar-local চায়:
  ✓ openid  ✓ email  ✓ profile
[ Continue ]

GET localhost:47402/auth/callback
  ?code=…&state=aT9…&iss=http://localhost:47401

state মিলেছে ✓  তারপর:
POST /token
Authorization: Basic (client_id:client_secret)
grant_type=authorization_code
code=…  redirect_uri=…
code_verifier=Xk2…

BASE64URL(SHA256(verifier)) == জমা challenge ✓
কোড মুছে ফেলা হলো, দ্বিতীয়বার চলবে না
200 → access_token, expires_in, id_token,
      scope, token_type

{"sub":"idp-1001","nonce":"…",
 "aud":"bazarghar-local",
 "exp":1793561689,"iat":1793558089,
 "iss":"http://localhost:47401"}
স্বাক্ষর (JWKS) ✓ iss ✓ aud ✓ exp ✓ nonce ✓
email এখানে নেই, UserInfo থেকে আনতে হলো

findOrLinkUser("local-idp", claims) → user 4
req.session.regenerate(…)   নতুন session id
req.session.userId = 4
Set-Cookie: bg.sid=…; HttpOnly; SameSite=Lax
{"userId":4,"how":"new-user"}

এই পথের মূল শিক্ষা যদি একটি মডেলে হাতে ধরে দেখতে চান, নিচের block চালান। এটি node:http-এ বানানো ছোট একটি শেখার মডেল, আসল provider নয়। এখানে login পাতা নেই, স্বাক্ষর নেই। শুধু দুটি নিয়ম আছে: redirect URI হুবহু মিলতে হবে, আর কোড ভাঙাতে সঠিক verifier লাগবে।

// শেখার মডেল: login পাতা, signature, JWKS কিছুই নেই
const http = require('node:http');
const { createHash, randomBytes } = require('node:crypto');
const sha = (s) => createHash('sha256').update(s).digest('base64url');
const REDIRECT = 'http://app.test/callback';
const codes = new Map();
let n = 0;
const idp = http.createServer(async (req, res) => {
  const u = new URL(req.url, 'http://idp.test'), q = u.searchParams;
  if (u.pathname === '/authorize') {
    if (q.get('redirect_uri') !== REDIRECT) { res.writeHead(400); return res.end(); }
    codes.set('code-' + ++n, q.get('code_challenge'));
    res.writeHead(302, { location: `${REDIRECT}?code=code-${n}` });
    return res.end();
  }
  let body = ''; for await (const c of req) body += c;
  const f = new URLSearchParams(body), saved = codes.get(f.get('code'));
  codes.delete(f.get('code')); // কোড এক বারই চলে
  const ok = saved && sha(f.get('code_verifier')) === saved;
  res.writeHead(ok ? 200 : 400);
  res.end(ok ? '{"id_token":"example"}' : '{"error":"invalid_grant"}');
});
idp.listen(0, '127.0.0.1', async () => {
  const base = `http://127.0.0.1:${idp.address().port}`;
  const v = randomBytes(32).toString('base64url');
  const start = (uri) => fetch(`${base}/authorize?` + new URLSearchParams({ redirect_uri: uri, code_challenge: sha(v) }), { redirect: 'manual' });
  const codeOf = (r) => new URL(r.headers.get('location')).searchParams.get('code');
  const token = (code, code_verifier) => fetch(`${base}/token`, { method: 'POST', body: new URLSearchParams({ code, code_verifier }) }).then(async (r) => r.status + ' ' + await r.text());
  console.log('bad redirect  :', (await start(REDIRECT + '/')).status);
  const c1 = codeOf(await start(REDIRECT));
  console.log('right verifier:', await token(c1, v));
  console.log('replay        :', await token(c1, v));
  console.log('wrong verifier:', await token(codeOf(await start(REDIRECT)), 'x'.repeat(43)));
  idp.closeAllConnections(); idp.close();
});

৪ · Express 5-এ openid-client

Protocol হাতে লিখবেন না। openid-client Node-জগতে বহু বছরের পরিচিত OIDC client library, আর এর বর্তমান major version হলো ৬ (আমাদের run-এ 6.8.8). Version 6-এর API আগের চেয়ে পুরো আলাদা: এখন আর Issuer বা generators class নেই, সব সাধারণ function. AI আর পুরোনো টিউটোরিয়াল প্রায়ই আগের ধরন লেখে, সেটি মিলিয়ে নেবেন। Library-টি ESM, আর Node 20 থেকে চলে।

প্রথমে শুরুতে একবার discovery. allowInsecureRequests শুধু এই local http lab-এর জন্য, production-এ এই লাইন থাকবে না।

import express from "express";
import session from "express-session";
import * as client from "openid-client";
import { findOrLinkUser, LinkRefused } from "./link.ts";

const BASE = "http://localhost:47402";
const REDIRECT_URI = `${BASE}/auth/callback`;
const config = await client.discovery(
  new URL("http://localhost:47401"),
  "bazarghar-local",
  "example-client-secret-not-real",
  undefined,
  { execute: [client.allowInsecureRequests] }, // শুধু এই local http lab
);

const app = express();
app.use(session({
  name: "bg.sid",
  secret: "example-session-secret",
  resave: false,
  saveUninitialized: false,
  cookie: { httpOnly: true, sameSite: "lax", secure: false, maxAge: 3_600_000 },
}));

Secret এখানে নকল, আর সুবিধার জন্য কোডেই লেখা। বাস্তবে এগুলো environment variable থেকে আসবে (পর্ব ৭৮, Environment আর secret). sameSite: "lax" ইচ্ছা করেই দেওয়া, "strict" নয়। Provider থেকে ফেরা একটি cross-site redirect, আর Strict হলে ব্রাউজার সেই অনুরোধে আপনার cookie পাঠাবে না, ফলে callback নিজের session-ই পাবে না। আমাদের lab-এ দুই পক্ষই localhost, অর্থাৎ same-site, তাই এই বিষয়টি এখানে চালিয়ে দেখানো যায়নি। এটি cookie-র নিয়ম থেকে বলা (দেখুন CSRF আর cookie পর্ব).

এবার login শুরুর route:

app.get("/auth/login", async (req, res) => {
  const codeVerifier = client.randomPKCECodeVerifier();
  const codeChallenge = await client.calculatePKCECodeChallenge(codeVerifier);
  const state = client.randomState();
  const nonce = client.randomNonce();
  req.session.oidc = { codeVerifier, state, nonce };

  const url = client.buildAuthorizationUrl(config, {
    redirect_uri: REDIRECT_URI,
    scope: "openid email profile",
    code_challenge: codeChallenge,
    code_challenge_method: "S256",
    state,
    nonce,
  });
  req.session.save(() => res.redirect(url.href));
});

শেষ লাইনে session.save খেয়াল করুন। Redirect পাঠানোর আগে session store-এ পৌঁছানো নিশ্চিত করা হলো। না হলে ব্যবহারকারী callback-এ ফিরে এসে দেখতে পারেন, মানগুলো তখনো জমা হয়নি। এবার callback, যেখানে আসল কাজ:

app.get("/auth/callback", async (req, res) => {
  const oidc = req.session.oidc;
  if (!oidc) return res.status(400).json({ error: "no_login_in_progress" });
  delete req.session.oidc; // এক login, এক ব্যবহার
  try {
    const tokens = await client.authorizationCodeGrant(
      config,
      new URL(req.originalUrl, BASE),
      {
        pkceCodeVerifier: oidc.codeVerifier,
        expectedState: oidc.state,
        expectedNonce: oidc.nonce,
        idTokenExpected: true,
      },
    );
    const claims = tokens.claims()!;
    const info = await client.fetchUserInfo(config, tokens.access_token, claims.sub);
    const { user, how } = await findOrLinkUser("local-idp", {
      sub: claims.sub,
      email: info.email,
      email_verified: info.email_verified,
      name: info.name,
    });
    req.session.regenerate((err) => {
      if (err) return res.status(500).json({ error: "session_error" });
      req.session.userId = user.id;
      req.session.save(() => res.redirect(`/me?how=${how}`));
    });
  } catch (e: any) {
    if (e instanceof LinkRefused) return res.status(409).json({ error: e.message });
    console.log("[app] callback rejected:", e.code, e.cause?.message);
    res.status(400).json({ error: "login_failed", code: e.code });
  }
});

তিনটি লাইন আলাদা করে দেখুন। fetchUserInfo-এর তৃতীয় argument হলো claims.sub: UserInfo-র sub ID token-এর সাথে না মিললে library থামবে। regenerate login-এর আগের session id বাতিল করে, যা session fixation ঠেকায়। আর error-এর বিস্তারিত log-এ যায়, ব্যবহারকারীর কাছে যায় শুধু একটি ছোট কোড (পর্ব ২৮-এর নিরাপদ বার্তা).

আসল run. (src/app.ts-এর উপরের তিনটি অংশে log-এর দুটি লাইন বাদ দেওয়া, যা নিচের শেষ লাইনটি লেখে.) Playwright Edge খুলল, নকল ব্যবহারকারী idp-1001 দিয়ে login করল। প্রতিটি navigation-এর status আর URL (সত্যিকারের run; মান লুকিয়ে শুধু parameter-এর নাম, আর interaction id ছোট করা):

$ node pw.mjs
browser 156.0.4314.58

== first login (new user): user=idp-1001
302 GET  http://localhost:47402/auth/login
303 GET  http://localhost:47401/auth?redirect_uri&scope&code_challenge&code_challenge_method&state&nonce&client_id&response_type
200 GET  http://localhost:47401/interaction/hcWX…     (login পাতা)
303 POST http://localhost:47401/interaction/hcWX…
303 GET  http://localhost:47401/auth/hcWX…
200 GET  http://localhost:47401/interaction/CHw0…     (consent পাতা)
303 POST http://localhost:47401/interaction/CHw0…
303 GET  http://localhost:47401/auth/CHw0…
302 GET  http://localhost:47402/auth/callback?code&state&iss
200 GET  http://localhost:47402/me?how
body {"userId":4,"how":"new-user"}

[app] token_response keys access_token,expires_in,id_token,scope,token_type

Callback-এর লাইনে দেখুন, code আর state-এর পাশে iss ফিরে এসেছে। এই parameter (RFC 9207) জানায় উত্তরটি কোন provider-এর। একাধিক provider থাকলে এটি এক provider-এর উত্তর অন্যটির বলে চালানো ঠেকায়।

৫ · state আর অন্য পাহারা ভাঙলে কী হয়

“কাজ করছে” দেখলেই যাচাই শেষ নয়। নিরাপত্তার কোডে দেখতে হয়, ভুল অনুরোধ থামছে কি না। আমরা নিজের lab-এ প্রতিটি পাহারা ইচ্ছা করে ভেঙে দেখেছি। নিচের table আসল run-এর, আসল বার্তায়।

একটি সূক্ষ্ম কথা। Provider-এর ওই ব্যাখ্যা আসে তার নিজের log-এ। Client-এর হাতে আসে শুধু {"error":"invalid_grant","error_description":"grant request is invalid"}. অর্থাৎ বাইরের কাউকে সে কারণ জানায় না। Debug করার সময় তাই দুই পাশের log-ই দেখতে হয়।

আরেকটি আসল পর্যবেক্ষণ: আমাদের lab-এর provider secret-সহ client-এর ক্ষেত্রে PKCE ছাড়া অনুরোধও login পাতায় নিয়ে গেছে। তাই provider থামাবে, এই ভরসায় থাকবেন না। PKCE পাঠানোর দায়িত্ব আপনার অ্যাপের।

CSRF: state কী ঠেকায়

কল্পনা করুন, কেউ নিজের account-এ login শুরু করে শেষের callback URL-টি নিজের কাছে রেখে দিল। সে এখন সেই URL নাদিয়ার ব্রাউজারে খোলাতে পারলে কী হবে? state না থাকলে নাদিয়া অজান্তে অন্যের account-এ login হয়ে যাবেন, আর সেখানে নিজের ঠিকানা বা কার্ডের তথ্য রাখবেন। Login CSRF-এর এই ধরনের কথা আগে CSRF পর্বে পড়েছেন। আমাদের run-এ ঠিক এই পরিস্থিতিই দুটি আলাদা ব্রাউজার context-এ চালানো হয়েছে।

/auth/callback?code=C-A&state=st-A&iss=…
st-A জমা আছে শুধু ব্রাউজার A-র session-এ

GET /auth/callback?code=C-A&state=st-A
400 {"error":"no_login_in_progress"}
সত্যিকারের run-এর উত্তর

session.oidc.state = st-B
provider-এর পাতা খোলা, এখনো শেষ করেননি

GET /auth/callback?code=C-A&state=st-A
জমা   : st-B
এসেছে : st-A   → মেলেনি

400 {"error":"login_failed",
     "code":"OAUTH_INVALID_RESPONSE"}
log: unexpected "state" response parameter value
Token অনুরোধ যায়ইনি, কোড অব্যবহৃত

code=C-A ভাঙানো হতো
session.userId = অন্যের account
নাদিয়া ভাবতেন এটি নিজের account

openid-client এই তুলনা নিজে করে। তবু নিয়মটি হাতের কোডে একবার দেখলে পরিষ্কার হয়। নিচের block একটি শেখার মডেল, যেখানে Map হলো নকল session store. খেয়াল করুন, মান মেলার আগেই সেটি মুছে ফেলা হয়, যাতে দ্বিতীয় চেষ্টা না থাকে।

const { randomBytes, timingSafeEqual } = require('node:crypto');

// প্রতি ব্রাউজারের session (Map = শেখার জন্য নকল store)
const sessions = new Map();

function startLogin(sid) {
  const state = randomBytes(16).toString('base64url');
  sessions.set(sid, { state });
  return state;
}

function sameText(a, b) {
  const x = Buffer.from(a), y = Buffer.from(b);
  return x.length === y.length && timingSafeEqual(x, y);
}

function callback(sid, query) {
  const pending = sessions.get(sid);
  if (!pending) return 'rejected: no_login_in_progress';
  sessions.delete(sid); // মান একবারই চলে, মিলুক বা না মিলুক
  if (!sameText(pending.state, query.state)) return 'rejected: state_mismatch';
  return 'accepted: exchange code ' + query.code;
}

const mine = startLogin('sid-nadia');
console.log('own callback   :', callback('sid-nadia', { state: mine, code: 'C1' }));
console.log('same URL again :', callback('sid-nadia', { state: mine, code: 'C1' }));

// অন্য ব্রাউজারের flow-র কোড নাদিয়ার ব্রাউজারে পৌঁছাল
const other = startLogin('sid-other');
console.log('no login begun :', callback('sid-nadia', { state: other, code: 'C2' }));
startLogin('sid-nadia');
console.log('own login open :', callback('sid-nadia', { state: other, code: 'C2' }));

৬ · Redirect URI, dev আর production, Google আর মোবাইল

Redirect URI হলো সেই ঠিকানা, যেখানে provider কোড পৌঁছে দেয়। তাই provider আগে থেকে নিবন্ধিত তালিকার সাথে হুবহু মেলায়। কেন এত কড়া, তা OAuth পর্বে আছে: কোড ভুল ঠিকানায় গেলেই খেলা শেষ। আমাদের provider-এ নিবন্ধিত ছিল শুধু http://localhost:47402/auth/callback. তিনটি প্রায়-একই ঠিকানা পাঠালাম (সত্যিকারের run, ছোট করে সাজানো):

== redirect_uri http://localhost:47402/auth/callback/  400
== redirect_uri http://127.0.0.1:47402/auth/callback   400
== redirect_uri http://localhost:9999/auth/callback    400
error: invalid_redirect_uri
error_description: redirect_uri did not match any of the client's registered redirect_uris

দ্বিতীয়টি বিশেষ করে মনে রাখুন। localhost আর 127.0.0.1 একই মেশিন, কিন্তু string আলাদা, তাই provider-এর কাছে আলাদা ঠিকানা। আর ব্রাউজারের কাছেও আলাদা সাইট, তাই cookie-ও মিলবে না।

Library বদলালে path-ও বদলায়, এটি আমরা নিজেরাই ঠেকে শিখেছি। Better Auth-এর lab-এ প্রথমে একটি পুরোনো ধরনের path (/api/auth/oauth2/callback/local-idp) নিবন্ধন করেছিলাম। 1.7.15 আসলে পাঠাল /api/auth/callback/local-idp, আর provider সোজা 400 দিল। সমাধান হলো অনুমান না করে, যে URL আসলে গেল সেটি দেখা।

Dev, staging আর production

তিনটি অভ্যাস কাজে দেয়। প্রতিটি পরিবেশের জন্য আলাদা client id ও secret রাখুন, যাতে dev-এর secret ফাঁস হলে production নিরাপদ থাকে। ঠিকানা APP_BASE_URL ধরনের environment variable থেকে নিন, অনুরোধের Host header থেকে বানাবেন না, কারণ সেটি বাইরে থেকে পাঠানো মান। আর reverse proxy-র পেছনে চললে Express-এ trust proxy ঠিক করুন এবং cookie-তে secure: true দিন।

Google-এর setup কথায়

পরিষ্কার করে বলি: এই পর্বে আসল Google account দিয়ে কিছু চালানো হয়নি, আর এই কোর্স দাবি করে না যে এখানে তা করা যাবে। Google Cloud-এর console-এর নাম ও মেনু প্রায়ই বদলায়, তাই নিচের ধাপগুলো সাধারণ ধারণা। আসল ধাপ দেখবেন Google-এর “OpenID Connect” docs-এ।

1. Google Cloud console-এ একটি project বানান।
2. Consent screen-এর branding পূরণ করুন: অ্যাপের নাম, support email ইত্যাদি। লেখার সময়ে docs-এ এর নাম Branding পাতা।
3. Clients পাতায় “Web application” ধরনের একটি OAuth client বানান। Client id আর secret পাবেন।
4. Authorized redirect URI-তে নিজের callback হুবহু বসান। Google-এর docs বলে scheme, অক্ষরের ছোট-বড় আর শেষের /, সব মিলতে হবে। না মিললে error-এর নাম redirect_uri_mismatch.
5. কোডে issuer বসান https://accounts.google.com, আর allowInsecureRequests বাদ দিন। Discovery ঠিকানা https://accounts.google.com/.well-known/openid-configuration, বাকিটা একই কোডে চলার কথা।

Google-এর docs আরও দুটি কথা বলে, যা পরের অংশে কাজে লাগবে। ব্যবহারকারীর স্থায়ী চাবি হিসেবে sub ব্যবহার করতে হবে, email নয়, কারণ email বদলাতে পারে। আর docs-এর নমুনা token-এ email_verified string "true" হিসেবে দেখা যায়, যদিও table-এ boolean লেখা। তাই আসল provider-এর payload একবার দেখে নিন। আমাদের === true শর্তে string এলে login আটকাবে, কিন্তু ভুল করে কাউকে ঢোকাবে না।

মোবাইল: secret নেই, তাই PKCE অপরিহার্য

মোবাইল app হলো public client: secret রাখলেও যে কেউ app খুলে বের করতে পারে। তাই সেখানে PKCE-ই মূল ভরসা। Web server-এর মতো একটি secret-সহ confidential client সেখানে হয় না। RFC 8252 (২০১৭) বলে, login চলবে সিস্টেমের ব্রাউজারে, app-এর ভেতরের embedded web view-তে নয়, যাতে app password দেখতে না পায়। ফেরার পথ তিন রকম: custom URL scheme (যেমন bazarghar://callback), claimed HTTPS link, আর desktop app-এর জন্য loopback ঠিকানা। Custom scheme অন্য app-ও দাবি করতে পারে, তাই সম্ভব হলে claimed link ভালো, আর PKCE সব ক্ষেত্রেই থাকবে। মোবাইলে ফেরার পরে সাধারণত app নিজের backend-এ কোড বা ID token পাঠিয়ে backend-এর session বা token নেয়।

৭ · Prisma Account table আর নিরাপদ linking

একজন মানুষের password আর Google, দুটোই থাকতে পারে। তাই login-এর পথকে User-এর ঘরে না রেখে আলাদা table-এ রাখুন। একটি user-এর অনেক account (পর্ব ৪১-এর one-to-many).

model User {
  id            Int       @id @default(autoincrement())
  email         String    @unique
  emailVerified Boolean   @default(false)
  passwordHash  String?   // social-only হলে null
  name          String?
  accounts      Account[]
  createdAt     DateTime  @default(now())

  @@map("users")
}

model Account {
  id                Int      @id @default(autoincrement())
  userId            Int
  user              User     @relation(fields: [userId], references: [id], onDelete: Cascade)
  provider          String
  providerAccountId String
  createdAt         DateTime @default(now())

  @@unique([provider, providerAccountId])
  @@index([userId])
  @@map("accounts")
}

providerAccountId হলো provider-এর sub. OIDC Core-এর কথা স্পষ্ট: iss আর sub একসাথেই ব্যবহারকারীর একমাত্র স্থায়ী পরিচয়। এখানে provider ঘরটি iss-এর কাজ করছে, কারণ এক provider-এর sub আরেকজনের সাথে মিলে যেতে পারে। সেজন্য unique হলো দুটি ঘর মিলে, sub একা নয়। Email এখানে পরিচয়ের চাবি নয়, শুধু “কোন user-এর সাথে জোড়া যেতে পারে” তার একটি সূত্র।

Linking-এর নিয়ম

কঠিন প্রশ্নটি হলো: সালমা আগে email আর password দিয়ে account খুলেছিলেন। আজ একই email-এর Google দিয়ে এলেন। জোড়া দেবেন, নাকি নতুন user? জোড়া দিলে সুবিধা, কিন্তু ভুল জোড়ায় একজনের account আরেকজনের হাতে যায়। নিয়মটি ছবিতে:

চতুর্থ প্রশ্নটি কেন? কারণ এখানেই pre-hijacking-এর ফাঁদ। ধরুন নাদিয়া বাজারঘরে কখনো আসেননি। অন্য কেউ নাদিয়ার email দিয়ে একটি password account খুলে রাখল, যা যাচাই হয়নি। পরে নাদিয়া Google দিয়ে এলেন। Provider-এর দিকে email_verified সত্য, তাই অসতর্ক অ্যাপ জোড়া দিল। এখন নাদিয়া ভাবছেন account তাঁর, অথচ আগের password-ও চলছে। মালিকের আগেই account-টি দখল হয়ে ছিল, তাই নাম “pre”-hijacking. Sudhodanan আর Paverd-এর ২০২২ সালের গবেষণা (USENIX Security) ৭৫টি জনপ্রিয় সেবা পরীক্ষা করে অন্তত ৩৫টিতে এই ধরনের কোনো না কোনো ফাঁক পেয়েছিল। তাদের একটি পরামর্শও ঠিক এই নিয়মটিই: জোড়া দেওয়ার আগে নিশ্চিত হতে হবে, মানুষটি এই মুহূর্তে দুই দিকই নিয়ন্ত্রণ করছেন।

export async function findOrLinkUser(provider: string, c: Claims) {
  // ১. আগে (provider, sub) দিয়ে খোঁজা, email দিয়ে নয়
  const known = await prisma.account.findUnique({
    where: { provider_providerAccountId: { provider, providerAccountId: c.sub } },
    include: { user: true },
  });
  if (known) return { user: known.user, how: "existing-account" };

  const local = c.email
    ? await prisma.user.findUnique({ where: { email: c.email } })
    : null;

  // ২. একই email-এর কেউ নেই: নতুন user
  if (!local) {
    const user = await prisma.user.create({
      data: {
        email: c.email ?? `${provider}-${c.sub}@no-email.invalid`,
        emailVerified: c.email_verified === true,
        name: c.name,
        accounts: { create: { provider, providerAccountId: c.sub } },
      },
    });
    return { user, how: "new-user" };
  }

  // ৩. একই email: দুই দিক verified না হলে নিজে থেকে জোড়া নয়
  if (c.email_verified !== true) throw new LinkRefused("provider_email_not_verified");
  if (!local.emailVerified) throw new LinkRefused("local_email_not_verified");

  await prisma.account.create({
    data: { userId: local.id, provider, providerAccountId: c.sub },
  });
  return { user: local, how: "linked-verified-email" };
}

Edge-এ চার রকম মানুষ চালালাম। আগে থেকে table-এ ছিলেন: সালমা (id 1, যাচাই করা), নাদিয়া (id 2, যাচাই হয়নি, password আছে), করিম (id 3, যাচাই করা, কিন্তু provider-এ তাঁর email যাচাই হয়নি)। আসল ফল, পাশাপাশি সাজিয়ে:

== second login: user=idp-1001             {"userId":4,"how":"existing-account"}
== verified both sides: user=idp-1003      {"userId":1,"how":"linked-verified-email"}
== local email unverified: user=idp-1004   {"error":"local_email_not_verified"}
== provider email unverified: user=idp-1002 {"error":"provider_email_not_verified"}

accounts table:
 id │ userId │ provider  │ providerAccountId
  1 │      4 │ local-idp │ idp-1001
  2 │      1 │ local-idp │ idp-1003

দুটি প্রত্যাখ্যান হওয়া login-এর জন্য accounts-এ কোনো সারি নেই, ঠিক যেমন চাওয়া হয়েছিল। এবার সালমার সফল জোড়াটি কোডের সাথে মিলিয়ে দেখুন।

1const known = findAccount(provider, c.sub);2if (known) return known.user;3const local = findUser(c.email);4if (!local) return createUser(c);5if (c.email_verified !== true) refuse();6if (!local.emailVerified) refuse();7createAccount(local.id, provider, c.sub);8return local;

যাঁর login আটকাল, তাঁর জন্য পথ কী? Error দেখিয়ে ফেলে রাখবেন না। বলুন: “এই email-এ আগে থেকে account আছে। আগে সেই পথে login করে Settings থেকে Google জুড়ুন।” Login করা অবস্থায় জোড়া দিলে মানুষটির নিয়ন্ত্রণ প্রমাণিত হয়। আর নিজের দিকের email যদি যাচাই না হয়ে থাকে, তাহলে যাচাই করা, আগের password বাতিল করা, বা ফেলে রাখা অযাচাই account মুছে ফেলার নিয়ম ঠিক করুন (পর্ব ৪৯, Account-এর কাজ).

নিচের শেখার মডেলে একই নিয়ম in-memory table-এ চলছে, এবং একটি বাড়তি ঘটনা আছে: একজনের provider-এর email বদলেছে, কিন্তু sub একই।

// শেখার মডেল: দুই table, Map দিয়ে
const users = [
  { id: 1, email: 'salma@bazarghar.test', verified: true },
  { id: 2, email: 'nadia@bazarghar.test', verified: false },
  { id: 3, email: 'karim@bazarghar.test', verified: true },
];
const accounts = new Map(); // 'provider:sub' -> userId

function login(c) {
  const key = 'google:' + c.sub;
  if (accounts.has(key)) return `user ${accounts.get(key)} (known sub)`;
  const local = users.find((u) => u.email === c.email);
  if (!local) {
    const id = users.push({ id: users.length + 1, email: c.email,
      verified: c.email_verified === true });
    accounts.set(key, id);
    return `user ${id} (new)`;
  }
  if (c.email_verified !== true) return 'refused: provider email not verified';
  if (!local.verified) return 'refused: local email not verified';
  accounts.set(key, local.id);
  return `user ${local.id} (linked)`;
}

const t = (sub, email, ok) => console.log(sub.padEnd(6), email.padEnd(25),
  login({ sub, email, email_verified: ok }));

t('g-1', 'salma@bazarghar.test', true);
t('g-2', 'nadia@bazarghar.test', true);
t('g-3', 'karim@bazarghar.test', false);
t('g-4', 'rahim@bazarghar.test', true);
t('g-4', 'new-rahim@bazarghar.test', true); // একই sub, email বদলেছে
console.log('accounts:', [...accounts.keys()].join(' '));

৮ · Auth library: কে কোথায় আছে

এতক্ষণ যা বানালাম, তা শেখার জন্য দারুণ। কিন্তু একটি পূর্ণ auth-এ আরও আছে: email যাচাই, password reset, একাধিক provider, MFA, session তালিকা, rate limit. তাই library-র কথা আসে। এই জগৎ গত দুই বছরে অনেক বদলেছে, আর AI-এর জ্ঞান প্রায়ই পুরোনো। লেখার সময়ের অবস্থা (npm আর প্রকল্পের নিজের ঘোষণা দেখে):

এখানে কোনো একটি নামের প্রচার করছি না। Hosted সেবার নামগুলো শুধু উদাহরণ, দাম আর শর্ত নিজে দেখে নিন। Hosted auth-এ আপনি একটি lock-in কেনেন, আর open-source library-তে একটি রক্ষণের ঝুঁকি, যা Lucia আর Auth.js-এর গল্পে দেখা গেল।

Better Auth-এর আসল setup

আমরা Better Auth বেছে নিয়েছি, কারণ এটি সক্রিয়, Express-এ চলে, আর Prisma-য় নিজের database-এ থাকে। একই local provider-এর সাথে জুড়লাম। আসল Google-এর জন্য এর নিজের socialProviders option আছে, কিন্তু আমরা OIDC-র generic plugin ব্যবহার করেছি, কারণ provider আমাদের নিজের।

import { betterAuth } from "better-auth";
import { prismaAdapter } from "better-auth/adapters/prisma";
import { genericOAuth } from "better-auth/plugins";
import { PrismaPg } from "@prisma/adapter-pg";
import { PrismaClient } from "../generated/prisma/client.ts";

const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL });
export const prisma = new PrismaClient({ adapter });

export const auth = betterAuth({
  database: prismaAdapter(prisma, { provider: "postgresql" }),
  emailAndPassword: { enabled: true },
  plugins: [
    genericOAuth({
      config: [{
        providerId: "local-idp",
        clientId: "bazarghar-local",
        clientSecret: "example-client-secret-not-real",
        discoveryUrl: "http://localhost:47401/.well-known/openid-configuration",
        scopes: ["openid", "email", "profile"],
        pkce: true,
      }],
    }),
  ],
});

import express from "express";
import { toNodeHandler, fromNodeHeaders } from "better-auth/node";
import { auth } from "./auth.ts";

const app = express();
app.all("/api/auth/*splat", toNodeHandler(auth)); // express.json-এর আগে
app.use(express.json());

app.get("/me", async (req, res) => {
  const s = await auth.api.getSession({ headers: fromNodeHeaders(req.headers) });
  if (!s) return res.status(401).json({ error: "not_signed_in" });
  res.json({ user: { id: s.user.id, email: s.user.email, emailVerified: s.user.emailVerified } });
});

Express 5-এ wildcard-এর নাম লাগে, তাই *splat; এটি Express 4-এর * থেকে আলাদা (পর্ব ২৫-এ Express route). আর auth handler বসে express.json()-এর আগে। Schema বানাল এর CLI, যেটি এখন npm-এ auth নামে। পুরোনো @better-auth/cli নামটি পিছিয়ে আছে (1.4.21). সত্যিকারের run:

$ npx auth@1.7.15 generate --config src/auth.ts --yes
…
🚀 Schema was overwritten successfully!

$ grep -n "model " prisma/schema.prisma
11:model User {
26:model Session {
42:model Account {
62:model Verification {

“overwritten” শব্দটি খেয়াল করুন: এই কমান্ড schema ফাইলে হাত দেয়, তাই আগে নিরাপদ জায়গায় রেখে চালান আর diff পড়ুন। তারপর prisma db push আর generate. Edge-এ login (আসল run, ছোট করা):

303 GET  http://localhost:47401/auth?response_type&client_id&state&scope&redirect_uri&nonce&code_challenge_method&code_challenge
…
302 GET  http://localhost:47403/api/auth/callback/local-idp?code&state&iss
200 GET  http://localhost:47403/me
body {"user":{"id":"z0onC69L…","email":"rahim@bazarghar.test","emailVerified":true}}
cookies  better-auth.session_token httpOnly=true sameSite=Lax

Library আমাদের হাতের কোডের মতোই PKCE, state আর nonce পাঠিয়েছে, আর login শেষে নিজের session cookie বসিয়েছে। Linking-এর পরীক্ষাটিই আসল কৌতূহল। আগে একটি অযাচাই password account, তারপর একই email-এ provider দিয়ে login (আসল run, ছোট করা, শেষের table-এর ঘর বাছাই করা):

signup nadia@bazarghar.test 200
== idp-1004
url  http://localhost:47403/api/auth/error?error
body ERROR Something went wrong CODE: account_not_linked …

signup salma@bazarghar.test 200
salma local marked verified
== idp-1003
url  http://localhost:47403/me
body {"user":{…,"email":"salma@bazarghar.test","emailVerified":true}}

 email                │ providerId  │ has_pw │ has_at │ has_idt
 nadia@bazarghar.test │ credential  │ true   │ false  │ false
 salma@bazarghar.test │ credential  │ true   │ false  │ false
 salma@bazarghar.test │ local-idp   │ false  │ true   │ true

আমরা কিছু না বলতেই Better Auth আমাদের হাতে লেখা নিয়মই মেনেছে: নাদিয়া আটকেছেন, সালমা জুড়েছেন। 1.7.15-এর source-এ দেখা গেল, requireLocalEmailVerified-এর ডিফল্ট true. তবে docs অনুযায়ী trustedProviders-এ কোনো provider যোগ করলে তার email যাচাই না হলেও জোড়া হতে পারে, তাই এই option সাবধানে দেবেন।

আরও দুটি জিনিস চোখে পড়ল। সারিতে has_at আর has_idt true, অর্থাৎ library provider-এর token database-এ রেখেছে। Source-এ দেখা গেল, এগুলো account.encryptOAuthTokens চালু করলে তবেই encrypt হয়, ডিফল্টে নয়। আপনার যদি এই token-এর পরে দরকার না থাকে, তাহলে কী রাখছেন, ভেবে দেখুন। আর generate করা Account model-এ accountId ও providerId-র ওপর unique নেই, শুধু userId-র index. ডুপ্লিকেট আটকায় library-র কোড। Database-এর স্তরেও চাইলে নিজে constraint যোগ করতে হবে, তবে পরের generate সেটি মুছে দিতে পারে কি না দেখে নেবেন।

৯ · নিজে বানাবেন, library, নাকি কিনবেন

এই সিদ্ধান্তের একটি সরল উত্তর নেই, কিন্তু একটি পরিষ্কার সীমারেখা আছে: ক্রিপ্টোগ্রাফি আর protocol নিজে লিখবেন না। “নিজে বানানো” মানেও অন্তত openid-client ব্যবহার করা। আমাদের হাতের মডেলে স্বাক্ষর যাচাই একেবারেই নেই, আর সেটিই সবচেয়ে সহজে ভুল হয়।

চারটি প্রশ্ন করুন। কে রাতে নিরাপত্তা patch দেবে? ডেটা বের করে অন্য কোথাও নেওয়া কতটা সহজ? Password hash রপ্তানি করা যায় তো? Library যদি বন্ধ হয়, আপনার table কি তবু পড়া যাবে? মনে রাখবেন, library নিলেও পাহারার দায় যায় না। Option-গুলো আপনাকেই পড়তে হবে, আর আপনাকেই ভুল অনুরোধ চালিয়ে দেখতে হবে। এখানে মত ভিন্ন আছে: অনেক অভিজ্ঞ দল সরল অ্যাপে নিজের ছোট কোড পছন্দ করে, আবার অনেকে বলে auth-এ নিজের কোড মানেই নিজের ঝুঁকি। দুটি মতেরই যুক্তি আছে।

১০ · AI-এর যুগে social login

এই বিষয়ে AI-এর কোড সবচেয়ে বিপজ্জনক ধরনের: চলে, login হয়, কিন্তু যাচাই অনুপস্থিত থাকে। আর API এত দ্রুত বদলেছে যে পুরোনো কোডও আত্মবিশ্বাসে আসে। নিচের সারিগুলো আমরা আমাদের version-এ চালিয়ে বা docs-এ মিলিয়ে দেখেছি।

AI-এর লেখা login কোড মেলানোর চেকলিস্ট

• npm view <package> version দেখেছি, প্যাকেজটি আছে আর deprecated নয়
• ভুল state, ভুল nonce, পুরোনো কোড, তিনটিই চালিয়ে থামতে দেখেছি
• অযাচাই local account-এর ওপর একই email-এ login চালিয়ে দেখেছি
• Login-এর আগে ও পরে session id আলাদা
• allowInsecureRequests বা secure: false production-এর কোডে নেই
• Secret environment-এ, কোডে বা browser bundle-এ নেই, আর AI-কে পাঠাইনি