اے آئی شناخت: انسانی سائن اِن اور ایجنٹ رسائی

آپ identity borrow کرنا بند کرتے ہیں اور اسے issue کرنا شروع کرتے ہیں · ایک وقت میں ایک spec، agent کو direct کر کے built

تصور کریں آپ کا Digital FTE رات 2 بجے، آپ کے سوتے ہوئے، کام کر رہا ہے۔ وہ expense file کرتا ہے، vendor book کرتا ہے، reply بھیجتا ہے۔ ایک سوال decide کرتا ہے کہ یہ safe ہے یا disaster بننے والا ہے: اس نے کس کی identity استعمال کی؟

Connector-Native Apps اور Plugins for AI Agents courses میں آپ کی app نے صرف اس person کی identity borrow کی جو host چلا رہا تھا۔ جب human chair میں بیٹھا ہو تو یہ ٹھیک ہے۔ لیکن ایسا worker جو اس وقت run کرتا ہے جب کوئی human chair میں نہیں، human کا login borrow نہیں کر سکتا؛ کیونکہ اگر وہ آپ کے طور پر login کرتا ہے تو وہ آپ ہی ہے: وہ سب کچھ کر سکتا ہے جو آپ کر سکتے ہیں، ہمیشہ کے لیے، اور ہر log کہتا ہے کہ آپ نے کیا۔ اسے scope کرنے، time-box کرنے، یا واپس لینے کا کوئی طریقہ نہیں۔

یہ course وہ جگہ ہے جہاں identity borrowed رہنا بند ہوتی ہے۔ آپ اسے دو halves میں build کرتے ہیں۔ پہلے آپ اپنا sign-in own کرتے ہیں: third-party login rent کرنے کے بجائے آپ اپنی production-grade authentication اور OAuth/OIDC server کھڑا کرتے ہیں جو real tokens issue کرتا ہے۔ پھر آپ agent کو اس کی اپنی identity دیتے ہیں: ایسی credential جو scoped، time-boxed، revocable، اور human-approved ہو، تاکہ worker کسی person کی طرف سے real work کر سکے مگر کبھی اس person کی impersonation نہ کرے۔

آخر تک آپ ایک running app ship کر چکے ہوں گے، آپ کی اپنی machine پر real Next.js project، جو ترتیب سے یہ بنے گا:

• آپ کا اپنا email-and-password sign-in، real sessions اور protected dashboard کے ساتھ؛
• ایک OAuth/OIDC issuer جو signed tokens mint کرتا ہے اور اپنی keys (JWKS) publish کرتا ہے تاکہ کوئی بھی verify کر سکے؛
• ایک second، separate app جو آپ کے issuer کے through people کو sign in کراتی ہے جبکہ آپ کی کوئی secret hold نہیں کرتی؛
• ایک resource server جو ان tokens کو offline verify کرتا ہے اور صرف اپنے لیے minted bands accept کرتا ہے؛
• اور ایک beta agent credential: scoped، time-boxed، revocable، human-approved band جو AI worker اپنے نام میں carry کرتا ہے۔

Prerequisite: Spec-Driven Development

یہ build course ہے، اور یہ assume کرتا ہے کہ آپ spec-driven loop already own کرتے ہیں: پہلے what پر agree کریں، پھر agent کو how produce کرنے کے لیے direct کریں۔ SDD course کے برعکس، یہاں main tool claude.ai نہیں ہے۔ یہ course repo-based ہے: آپ real Next.js app میں Claude Code یا OpenCode کے ساتھ کام کرتے ہیں۔ آپ TypeScript ہاتھ سے نہیں لکھیں گے؛ آپ general agent کو direct کرتے ہیں اور وہ code لکھتا ہے، Manufacturing track کے ہر build course والی same move۔ لیکن یہ security course ہے، اس لیے code صرف آدھا کام ہے: جو چیز آپ کے پاس رہتی ہے وہ ہے specify کرنا کہ کیا built ہو، پھر ہر security property کو inspect، test، اور prove کرنا۔ اسی لیے پورے course میں spec-less understand prompts آپ کو token decode کرواتے ہیں، audience tamper کرواتے ہیں، replay کرواتے ہیں، اور server کا refusal دکھاتے ہیں۔

📚 تدریسی مدد

Full Slideshow کھولیں

Full Presentation دیکھیں — AI Identity: Human Sign-In and Agent Access

یہ course جس ایک سوال کا جواب دیتا ہے

اس کے بعد آپ جو بھی system build کریں، اسے ایک test پر اٹھا سکتے ہیں:

یہ identity کس کی ہے، اور authority human سے agent تک کیسے گزرتی ہے؟

یہ سوال spine ہے۔ Specific tools agent-identity standards settle ہونے کے ساتھ بدلتے رہیں گے۔ سوال نہیں بدلے گا۔

ایک تصویر: venue اور wristband

Identity abstract لگتی ہے جب تک آپ اسے night out پر map نہ کریں۔ یہ single picture ذہن میں رکھیں؛ course کا ہر piece اپنی جگہ بیٹھ جائے گا۔

آپ ایک venue پر پہنچتے ہیں۔ Door پر کوئی آپ کا ID ایک بار check کرتا ہے: یہ signing in ہے، یعنی آپ prove کرتے ہیں کہ آپ کون ہیں۔ وہ آپ سے اندر ہر bar پر ID دوبارہ نہیں دکھواتے۔ اس کے بجائے ایک booth آپ کے لیے wristband print کرتا ہے۔ band proof ہے کہ آپ کو اندر آنے کی اجازت ہے؛ venue بند ہونے پر expire ہو جاتا ہے، اور اگر آپ bad behave کریں تو bouncer اسے کاٹ سکتا ہے۔ اندر bartender بس آپ کے band پر نظر ڈالتا ہے اور serve کر دیتا ہے۔ band پر ایسی seal ہوتی ہے جو صرف booth بنا سکتا ہے، اس لیے bartender اسے دیکھتے ہی trust کرتا ہے، booth کو phone کیے بغیر۔

یہ پوری identity stack ہے، scene کے ہر part کے لیے ایک term کے ساتھ:

ہر جگہ استعمال ہونے والا ایک model: door sign-in ہے، booth issuer ہے، band token ہے، bartender validator ہے۔ frontier پر agent آپ کا band borrow کرنا چھوڑتا ہے اور اپنا band لیتا ہے، کبھی tight limits کے تحت کسی person کی طرف سے act کرنے کے لیے stamped۔

وہ part notice کریں جو tokens کو work کراتا ہے: bartender کبھی booth کو call نہیں کرتا۔ band کی seal کافی ہے۔ Real systems میں وہ seal cryptographic signature ہوتی ہے، اور booth وہ key publish کرتا ہے جس سے کوئی بھی signature check کر سکتا ہے، مگر وہ key locked رکھتا ہے جس سے signature بنائی جاتی ہے۔ اسی لیے stranger app آپ کے tokens trust کر سکتی ہے، کبھی آپ کی database یا secrets کو touch کیے بغیر۔

Tokens اور sessions، zero سے

اس course کے باقی حصے میں تین words مسلسل آئیں گے۔ ہر ایک کو plain terms میں، اسی picture پر دیکھیں جو آپ hold کر رہے ہیں۔

Session وہ طریقہ ہے جس سے server یاد رکھتا ہے کہ آپ signed in ہیں۔ Door آپ کا ID check کرنے کے بعد browser میں ایک چھوٹا marker، یعنی cookie، set کرتا ہے اور ہر later request پر اسے read کرتا ہے، تاکہ آپ ہر page پر دوبارہ sign in نہ کریں۔ Session venue کا یہ جاننا ہے کہ آپ آج رات اندر آئے تھے۔

Token wristband خود ہے: ایک signed claim کہ آپ کون ہیں اور کیا کر سکتے ہیں۔ عام kind JWT (JSON Web Token) ہے، dots سے جڑے تین parts: header.payload.signature۔ payload claims carry کرتا ہے؛ signature booth کی seal ہے۔

Course کے باقی حصے کے لیے یہ image hold کریں۔ Booth ایک band کو اپنی wax seal دبا کر sign کرتا ہے۔ وہ stamp جو seal بناتا ہے، booth کی private key، booth کے اندر locked رہتی ہے اور کبھی باہر نہیں جاتی، تاکہ کوئی اور mark copy نہ کر سکے۔ دنیا کو seal check کرنے دینے کے لیے booth door کے پاس wall پر اس کی clear photo tape کر دیتا ہے، یعنی published (public) key۔ کوئی بھی band کو photo کے ساتھ hold کر کے confirm کر سکتا ہے کہ seal genuine ہے، مگر آپ photo سے working stamp carve نہیں کر سکتے۔ یہی پوری trick ہے: photo stranger کو band verify کرنے دیتی ہے، forge کرنے نہیں؛ bartender اسی پر sight پر trust کرتا ہے۔

OAuth (اور اس کے اوپر OIDC جو person کون ہے carry کرتا ہے) وہ agreed protocol ہے جس میں booth کسی دوسری app کے لیے band print کرتا ہے: ایک app person کو sign in کے لیے آپ کے پاس بھیجتی ہے، آپ کا server token واپس دیتا ہے، اور دوسری app اسے read کرتی ہے۔

Try it

کوئی بھی JWT لیں (آپ کی اپنی app چند منٹ میں ایک mint کرے گی، یا example paste کریں) اور اپنے agent سے کہیں: "Decode this JWT. Show me the header and payload as plain JSON, explain what each claim means, and tell me which part anyone can verify with a public key and which part proves it was not tampered with." اس کا جواب پڑھنا اس section کو دوبارہ پڑھنے سے faster gut-check ہے۔

اپنا environment set up کریں (ایک بار)

آپ جو کچھ build کرتے ہیں وہ ایک چھوٹے folder کے اندر ہوتا ہے: course base۔ یہ جان بوجھ کر lean ہے: اس میں constitution، specs، prompts، اور ایک skill ship ہوتی ہے؛ app ابھی نہیں ہوتی۔ آپ کی پہلی move agent کو app build کرنے کے لیے direct کرنا ہے، اور یہی loop کا پہلا rep ہے جو آپ پورے course میں استعمال کریں گے۔

اسے ایک بار download کریں؛ یہی folder پوری course کے لیے serve کرے گا۔

Download ai-identity-base.zip

یا agentfactory-manufacturing repo clone کریں اور اس کا ai-identity folder open کریں۔ دونوں صورتوں میں folder اپنے agent میں open کریں:

cd ai-identity
claude

cd ai-identity
opencode

آپ کو sign-in data کے لیے free Neon Postgres database بھی چاہیے (credit card نہیں؛ base اسے آپ کے لیے wire کرتا ہے)۔ اسے نیچے second prompt سے پہلے set up کریں۔

Lesson 0 دو prompts میں آتا ہے، تاکہ آپ کچھ بھی build ہونے سے پہلے ground proven دیکھیں۔

Step 1، environment prove کریں۔ Paste کریں:

Read specs/00-set-up-the-base/spec.md (Phase 1) and the "Set up the base" section of AGENTS.md. Check my prerequisites (Node, pnpm), install the skills it lists (Better Auth, shadcn, Neon), and confirm the MCP servers in .mcp.json and opencode.json are present and reachable. Don't scaffold anything yet. Just prove the ground and run the Phase 1 acceptance checks.

Watch for: npx skills add quietly skill name drop کر سکتا ہے، اس لیے agent confirm کرتا ہے کہ ہر skill واقعی land ہوئی۔ Done when: Node اور pnpm versions report کریں، better-auth، shadcn، اور neon-postgres skills present ہوں، اور تینوں MCP servers answer کریں۔

What just happened: آپ نے trained staff hire کیا اور phones wire کیے، مگر ابھی کچھ build نہیں کیا۔ Skills booth operator کے manuals ہیں (band issue کیسے کرنا ہے، UI build کیسے کرنی ہے)؛ MCP servers agent کی direct lines ہیں Neon کے control room اور live docs تک۔ Ground proven ہے؛ اس پر ابھی کچھ کھڑا نہیں۔

Step 2، app scaffold کریں۔ پہلے اپنی Neon database provision کریں، پھر paste کریں:

Now do Phase 2 of specs/00-set-up-the-base/spec.md: scaffold the Next.js + Tailwind + shadcn app here, pin the Better Auth 1.7 stack with the kysely override, add the Neon driver, and create .env from the template. Don't build any auth. Start the dev server and show me the landing page is up, then run the Phase 2 acceptance checks.

Watch for: create-next-app non-empty directory میں scaffold کرنے سے refuse کرتا ہے، اس لیے base کی recipe temp dir میں scaffold کر کے result واپس merge کرتی ہے (conflict میں base files win کرتی ہیں)۔ Done when: pnpm dev plain landing page کو http://localhost:3000 پر serve کرے، اور pnpm build اور tsc دونوں clean run ہوں۔

What just happened: اب building exist کرتی ہے۔ Dev server ایک empty venue دکھاتا ہے جس کی lights on ہیں، آپ کی machine پر real app boot ہو رہی ہے، مگر ابھی door، booth، bands کچھ نہیں۔ آپ کے پاس identity system رکھنے کی جگہ آ گئی، یہی Lesson 1 build کرنا شروع کرتا ہے۔

Quick Win: اپنی app میں signed in ہونا

Base ready ہونے کے بعد آپ ایک prompt دور ہیں ایسے sign-in screen سے جو آپ own کرتے ہیں، real database سے backed۔ پہلے succeed کریں، بعد میں سمجھیں۔

Paste کرنے سے پہلے، اسی picture پر وہ چار pieces نام دیں جو یہ build کرتا ہے۔ Email and password sign-in door کا ID check کرنا ہے جو آپ پہلی بار آتے ہوئے set up کرتے ہیں۔ Session venue کا یہ یاد رکھنا ہے کہ آپ آج رات اندر آئے تھے، earlier cookie کے ذریعے، تاکہ ہر page پر ID دوبارہ نہ دکھانا پڑے۔ Protected route back room ہے جہاں صرف signed-in members enter کر سکتے ہیں۔ اور password hash وہ one-way fingerprint ہے جو door آپ کے actual password کے بجائے رکھتا ہے، تاکہ venue بھی اسے واپس read نہ کر سکے۔

Lesson 1، اپنا sign-in own کریں۔ Paste کریں:

Read specs/01-own-your-sign-in/spec.md and the better-auth-best-practices and email-and-password-best-practices skills. Plan the approach against our constitution, show me the plan, then build it in small steps. Run the spec's acceptance checks, including the security ones, before you call it done.

آپ plan review کرتے ہیں، agent build کرتا ہے، اور آپ account create کر کے dashboard پر land کرتے ہیں جو prove کرتا ہے کہ آپ کون ہیں۔ یہ آپ کی win ہے: sign-up، sign-in، sessions، اور protected page، سب آپ کے اپنے server پر running۔

Watch for: Better Auth کے POST endpoints ہر ایسی request reject کرتے ہیں جس کا Origin header trusted نہ ہو، اس لیے base کی config آپ کا dev origin پہلے سے list کرتی ہے۔ Done when: آپ account create کریں اور dashboard پر اپنا name اور email دیکھیں، اور آپ کا password صرف one-way hash کے طور پر stored ہو، جسے نیچے understand prompt prove کرتا ہے۔

اب اسے ایک understand prompt کے ذریعے real بنائیں؛ اس کا کوئی spec نہیں، یہ بس آپ کو دکھاتا ہے کہ آپ نے کیا build کیا:

I just signed up. Show me exactly what got stored in the database for my account, and point out what is NOT there. Where is my password, and why can't you show it to me?

جواب، یعنی آپ کا password صرف one-way hash کے طور پر stored ہے، اس لیے آپ کا own server بھی اسے واپس read نہیں کر سکتا، identity literacy کا پہلا piece ہے جو یہ course build کرتا ہے۔ آپ نے اسے paragraph میں نہیں پڑھا۔ آپ نے اسے اپنے data پر دیکھا۔

Build path: login rent کرنے سے اسے issue کرنے تک

Course سات steps کی spine ہے جو base میں specs پر one-to-one map ہوتی ہے۔ آپ ہر step ایک short prompt paste کر کے build کرتے ہیں؛ spec detail carry کرتا ہے اور skill exact API carry کرتی ہے، اس لیے prose idea پر رہتی ہے۔ یہ پوری arc ہے، اور وہ جگہ بھی جہاں settled ground ختم ہونا شروع ہوتا ہے۔

Seven-step spine، پھر milestone، پھر frontier۔ آپ جتنا right جاتے ہیں، standards اتنے young ہوتے جاتے ہیں؛ mental model پورا راستہ same رہتا ہے۔

0–1. Base set up کریں، پھر اپنا sign-in own کریں

آپ Quick Win میں ان سے مل چکے ہیں۔ Step 0 toolchain scaffold کرتا ہے (Next.js، shadcn، Better Auth 1.7 stack، Neon)۔ Step 1 real server-side sessions اور protected dashboard کے ساتھ email and password sign-in کھڑا کرتا ہے۔ یہ door ہے: آپ کے users ایک بار prove کرتے ہیں کہ وہ کون ہیں۔

2. Issuer بنیں (marquee)

یہ وہ step ہے جس کی طرف پورا track point کر رہا تھا۔ Connector-Native Apps میں آپ bartender تھے: آپ کا gateway tokens validate کرتا تھا جن پر کسی اور نے sign کیا تھا۔ یہاں آپ counter کے پیچھے جاتے ہیں اور booth بن جاتے ہیں۔ جب کوئی دوسری app کسی person کو sign in کے لیے آپ کے پاس بھیجتی ہے، آپ کا server signed token واپس دیتا ہے جسے وہ app مکمل طور پر خود verify کر سکتی ہے، public wall پر لگائی ہوئی آپ کی seal کی photo سے compare کر کے، کبھی password دیکھے یا آپ کی database call کیے بغیر۔

یہ loop close ہونا ہے: جس course میں آپ صرف wristbands check کرتے تھے، وہ اب آپ کو انہیں print کرنا سکھاتا ہے۔

Paste کرنے سے پہلے handshake سمجھیں جو آپ کا booth چلانے والا ہے۔ جب ایک OAuth client (دوسرا venue جو آپ کے wristbands honor کرنے پر agree کرتا ہے) کسی person کو sign in کے لیے بھیجتا ہے، آپ band اس کے browser کے ذریعے واپس نہیں بھیجتے۔ آپ authorization-code flow چلاتے ہیں: person آپ کے booth پر sign in کرتا ہے، آپ app کو short-lived code دیتے ہیں (claim-check stub)، اور app quietly اس stub کو real token سے swap کرتی ہے sight سے باہر، تاکہ band خود browser سے travel نہ کرے۔ PKCE one-line proof ہے کہ جس app نے handshake شروع کیا، وہی اسے finish کر رہی ہے؛ stolen stub کسی اور کے لیے useless ہے۔ اور کوئی band print ہونے سے پہلے person consent screen پر approve کرتا ہے کہ app کیا دیکھ سکتی ہے۔ (آپ کی seal کی wall photo، earlier والی، وہی ہے جو app کو band hold کرنے کے بعد verify کرنے دیتی ہے۔)

یہ Quick Win والا same plan-build-check loop ہے، بس اب کہیں bigger target پر aimed ہے۔ آپ کے کام کرنے کے طریقے میں کچھ نیا نہیں؛ build کرنے والی چیز heftier ہے۔ Ready ہوں تو paste کریں:

Read specs/02-become-the-issuer/spec.md and the agent-identity-issuer skill. Plan it, show me the plan, then build it in small steps. Build the token verifier as a separate script so the checks are real, and run all the acceptance criteria, especially the adversarial ones.

آپ OAuth configuration ہاتھ سے نہیں لکھیں گے۔ Shipped agent-identity-issuer skill verified config carry کرتی ہے، اور spec acceptance checks carry کرتا ہے۔ آپ کا کام build direct کرنا اور confirm کرنا ہے کہ یہ pass ہے، ان security gates سمیت جن پر working-but-insecure version fail ہونا چاہیے۔

آپ نے build کر لیا؛ اب دیکھیں کہ یہ واقعی safe ہے۔ نیچے prompts کا کوئی spec نہیں۔ ہر ایک آپ کے own issuer پر ایک security property visible کرتا ہے، ایک وقت میں ایک۔

سب سے پہلے wall پر photo دیکھیں۔ آپ کا JWKS endpoint وہی wall ہے: آپ کے booth کی seal کی public photo، جس سے کوئی بھی band check کر سکتا ہے۔ Seal press کرنے والا stamp، آپ کی private signing key، booth میں locked رہتا ہے اور اس photo میں کبھی نہیں ہوتا۔

Fetch my JWKS endpoint and show me what's there. Is my private signing key in it? Prove it, and explain why a stranger can verify my tokens but can't forge one.

یہ gap پوری بات ہے: صرف photo post کریں، stamp کبھی نہیں، اور دنیا آپ کے bands verify کر سکتی ہے جبکہ کوئی انہیں forge نہیں کر سکتا۔

اگلا، ابھی print کیا ہوا band read کریں، پھر ایک character سے break کریں:

Take an ID token you just issued, decode it, and walk me through every claim, iss, aud, sub, exp, in plain English. Then change the aud by one character and show me the verifier rejecting it.

آخر میں، band کو closing time سے آگے دھکیلیں:

Issue a token, then move the clock past its expiry and try to use it. Show me the exact rejection.

What just happened: آپ counter کے پیچھے چلے گئے۔ جس course نے آپ کو wristbands پر نظر ڈالنا سکھایا تھا، وہ اب آپ کو انہیں print کرنا سکھا رہا ہے، ایسی seal کے ساتھ کہ stranger app ہر band کو sight پر trust کر سکے، کبھی آپ کے booth کو phone کیے بغیر؛ اور آپ نے seal، audience stamp، اور expiry ہر ایک کو hold کرتے دیکھا۔

3. Scopes اور consent

Token کو exactly کہنا چاہیے کہ وہ کیا کر سکتا ہے، اس سے زیادہ نہیں۔ Step 3 scope add کرتا ہے (band کو کیا کرنے کی اجازت ہے، جیسے colored band جس پر drinks only stamped ہو بمقابلہ drinks and kitchen) اور consent screen جہاں person approve کرنے سے پہلے exact list دیکھتا ہے۔ Least privilege real ہو جاتا ہے: band job کرنے والی narrowest authority carry کرتا ہے، اور bartender ہر order پر اسے check کرتا ہے، صرف door پر ایک بار نہیں۔

آپ یہ loop دو بار چلا چکے ہیں۔ یہ پھر ہے، exactly ایک نئی idea، scope، کے ساتھ، اس issuer پر layered جو آپ already built کر چکے ہیں۔ Paste کریں:

Read specs/03-scopes-and-consent/spec.md and the agent-identity-issuer skill. Plan the approach against our constitution, show me the plan, then build it in small steps. Run the spec's acceptance checks, especially the adversarial ones, before you call it done.

اب prove کریں کہ limit real ہے، decoration نہیں۔ نیچے ہر prompt آپ کو scope hold کرتے دکھاتا ہے:

پہلے، خود کو narrow band دیں اور اس سے overreach کرنے کی کوشش کریں:

Issue me a token that has only notes.read. Now use it to try the write action and show me the exact refusal. Then explain in plain English why a token that signs fine can still be turned away here.

پھر approval screen دیکھیں جو person واقعی دیکھتا ہے:

Walk me through the /consent screen for a client asking for notes.read and notes.write. Where do those two lines come from? Prove the screen can only show what the signed request actually asks for, not whatever it likes.

آخر میں، registered authority سے زیادہ grab کرنے کی کوشش کریں:

Register a client for notes.read only, then have it ask for notes.write anyway. Show me the granted scope in the token it gets back and point out what is missing, and why.

What just happened: آپ کے bands اب colors میں آتے ہیں۔ ہر ایک job کرنے والی narrowest authority carry کرتا ہے، اور person نے ایک band print ہونے سے پہلے exact list دیکھی۔

4. Real app connect کریں

اب prove کریں کہ booth آپ کے علاوہ کسی اور کے لیے بھی کام کرتا ہے۔ Client app الگ venue ہے جو لوگوں کو آپ کے ذریعے sign in کرتا ہے، مگر آپ کے secrets میں سے کچھ share نہیں کرتا۔ اپنے issuer کو AuthCo اور نئی app کو Notes کہیں۔ جب کوئی Notes میں sign in کرتا ہے، یہ اسے AuthCo کے booth پر بھیجتا ہے، band واپس لیتا ہے، اور AuthCo کی wall photo سے band کی seal خود check کرتا ہے۔ Notes کبھی password نہیں دیکھتا اور آپ کی database touch نہیں کرتا۔

Same rhythm، new actor۔ ایک سانس لیں: آپ کوئی foreign چیز build نہیں کر رہے، صرف ایک second، separate app کو اس booth کی طرف point کر رہے ہیں جو آپ already own کرتے ہیں۔ Paste کریں:

Read specs/04-connect-a-real-app/spec.md and the agent-identity-issuer skill (the register-a-client and verify-a-token sections). Plan the approach against our constitution, show me the plan, then build it in small steps. Keep Notes a fully separate process. Run the spec's acceptance checks, especially the adversarial ones, before you call it done.

اب خود کو convince کریں کہ separation genuine ہے۔ ہر prompt اس کا ایک part visible کرتا ہے:

پہلے، prove کریں کہ Notes آپ کے secrets میں سے کچھ hold نہیں کر رہا:

Show me everything Notes knows about AuthCo. Prove it has no copy of BETTER_AUTH_SECRET and no path into AuthCo's database, then explain how it can still verify my tokens.

Answer پھر photo ہے: Notes کو band check کرنے کے لیے صرف AuthCo کی seal کی public photo چاہیے، stamp کبھی نہیں؛ اس لیے وہ ہر token verify کر سکتا ہے جبکہ AuthCo کے secrets میں سے کچھ نہیں hold کرتا۔

پھر audience stamp کو ایک character سے break کریں:

Take a token Notes just verified and change its aud by one character. Show me Notes's verifier rejecting it, and explain why that one character is the whole point.

آخر میں، booth سے band cut کریں اور next call fail ہوتے دیکھیں:

Sign me in through Notes, then revoke the client at AuthCo. Make Notes's next call and show me it fails. Explain what "revocable" actually buys me here.

What just happened: ایک venue جسے آپ control نہیں کرتے، اس نے کسی کو آپ کے booth کے ذریعے sign in کیا اور band کو خود trust کیا، آپ کے secrets میں سے کچھ hold کیے بغیر۔ Booth strangers کے لیے بھی کام کرتا ہے، صرف آپ کے لیے نہیں۔

5. Resource server connect کریں

Resource server ایسا bar ہے جو صرف bands check کرتا ہے اور کبھی کسی کو sign in نہیں کرتا۔ یہی وہ bartender ہے جو آپ نے Connector-Native Apps میں play کیا، اب اپنی زمین پر کھڑا۔ یہ bearer token لیتا ہے، یعنی جو band hold کرتا ہے وہ بس اسے present کرتا ہے اور کوئی دوسرا ID نہیں دکھاتا، اور band کا audience stamp read کرتا ہے، good at THIS bar، اس لیے کسی اور bar کے لیے minted band sight پر refused ہوتا ہے۔ یہاں seal specific signing algorithm (RS256) سے بنتی ہے، اور کسی دوسرے طریقے سے sealed band بھی turn away ہوتا ہے۔ یہ ہر seal AuthCo کی posted photo کے خلاف check کرتا ہے اور booth کو کبھی phone نہیں کرتا، یہی build prompt میں verifying offline via JWKS کا مطلب ہے۔

اب تک loop familiar لگنا چاہیے۔ ایک اور actor، bar جو صرف bands check کرتا ہے اور اندر named person کو serve کرتا ہے۔ Paste کریں:

Read specs/05-connect-a-resource-server/spec.md and the agent-identity-issuer skill (sections 1 and 3). Plan it, show me the plan, then build it in small steps. Configure AuthCo to sign RS256 tokens audience-bound to my API, stand up a tiny protected resource that verifies offline via JWKS, and run all the acceptance checks including the adversarial ones.

Prove کریں کہ band صرف وہاں کام کرتا ہے جہاں intended ہے۔ ہر prompt ایک rule کو visible کرتا ہے:

پہلے، اسی course میں بنائے گئے real connector کے ساتھ loop close کریں:

Bring back the connector from the Connector-Native Apps Crash Course (or clone its worked example if it is not on my machine). Point its issuer and JWKS settings at AuthCo, sign in, and show me it accept a token my issuer just minted: it should check the aud against its own API URL and the seal against my public JWKS, without ever calling me. Explain why the bartender I once played for someone else's tokens now trusts the bands I print.

اب اسی small resource server کی طرف واپس آئیں جو آپ نے یہاں build کیا، اور اسے fool کرنے کی کوشش کریں۔ پہلے غلط طریقے سے sealed band present کریں:

Sign a token with EdDSA and present it to my RS256-only verifier. Show me the exact rejection, then explain why the issuer's signing algorithm has to match what the consumer expects.

دو اور forgeries ہاتھ سے try کرنے کے قابل ہیں، کیونکہ attacker sloppy bartender کے پاس اکثر ایسے ہی slip کرتا ہے۔ پہلے، بغیر seal والا band:

Take a valid token, strip its signature, and set the header's algorithm to none. Present it to my resource server and show me it refused. Explain why a verifier that trusts the token's own header to say "this one needs no seal" is the whole alg: none attack.

پھر زیادہ sneaky one، جہاں attacker wall پر taped photo کو use کر کے band seal کرتا ہے:

My public JWKS is posted for anyone to read. Take that public key, use it as an HMAC secret to sign a token with HS256, and present it claiming alg: HS256. Show me my RS256-pinned verifier rejecting it, then explain why a verifier that reads the algorithm off the token, instead of pinning RS256, would be fooled into checking a forgery against its own public key.

آخر میں، valid band کو غلط bar کی طرف point کریں:

Change the audience on a valid token to a different API's URL and show my resource server refusing it, even though AuthCo's signature is genuine.

What just happened: آپ نے Connector-Native Apps والا bartender اپنی ground پر کھڑا کیا۔ وہ ہر band check کرتا ہے، صرف اندر named person کو serve کرتا ہے، اور کسی different bar کے لیے minted یا غلط طریقے سے sealed band کو turn away کرتا ہے۔

6. CIMD کے ساتھ client identity (edge)

Steps 0 سے 5 settled، production-grade ground ہیں۔ Step 6 اس سے باہر قدم رکھتا ہے۔ اب تک app نے prove کیا کہ وہ کون ہے client registration کے ذریعے: اس نے آپ کی pre-approved partner list پر جگہ earned کی، ahead of time vouched۔ CIMD (Client ID Metadata Document) کے ساتھ app list skip کرتی ہے۔ یہ ایک URL پر public sign لٹکاتی ہے جو اسے describe کرتا ہے، اور آپ کا booth پہلی بار app آنے پر وہ sign on demand read کرتا ہے، no pre-registration۔ MCP world اسی طرف جا رہی ہے، مگر یہ Better Auth pre-release plugin اور IETF draft standard پر run کرتا ہے، اس لیے course آپ سے build سے پہلے live API confirm کرواتا ہے۔

یہ واحد جگہ ہے جہاں build سے پہلے look things up کرتے ہیں، کیونکہ ground newer ہے۔ Slow چلیں؛ prompt خود agent سے live docs پہلے check کرواتا ہے، جو moving standard پر exactly right instinct ہے۔ Paste کریں:

Read specs/06-client-identity-with-cimd/spec.md and section 2 of the agent-identity-issuer skill. Before writing anything, query the live Better Auth docs MCP at https://mcp.better-auth.com/mcp and show me the current @better-auth/cimd API, whether I add cimd() or pass cimdClientDiscovery() to oauthProvider, and the exact discovery key. Then plan it, show me the plan, move us to the Better Auth 1.7 pre-release channel, and build it in small steps. Run the acceptance checks including the adversarial ones.

پھر دیکھیں کہ اس ایک change نے کیا switch on کیا۔ ہر prompt new behavior visible کرتا ہے:

پہلے، اپنے public sign پر new line ظاہر ہوتے دیکھیں:

Show me my discovery document before and after this change, and point at the one new line that tells a client "you can identify yourself by URL." Explain in plain English what that flips on.

پھر booth کو list کے بجائے sign read کرتے دیکھیں:

Walk me through what happens when a client hands you an HTTPS URL as its client_id: what do you fetch, what do you read in that document, and how is that different from looking up a row in my database?

آخر میں، bad sign دیں اور اسے refuse ہوتے دیکھیں:

Hand my issuer a client_id that is a plain http:// URL, and one with a #fragment on the end. Show me each one being refused, and explain why the draft insists on a clean HTTPS URL.

What just happened: ایک app نے آپ کی guest list کا wait کرنے کے بجائے public sign لٹکا کر اپنا تعارف کرایا۔ Agent world اسی طرف جا رہی ہے، اور آپ نے اسے ایسی ground پر build کیا جسے آپ move ہوتے دیکھ سکتے ہیں۔

~50% milestone: آپ کا پہلا project جسے آپ drive کرتے ہیں

Spine کے بعد course آپ کو fully specified، live-verified steps دینا بند کرتا ہے اور projects you drive yourself دینا شروع کرتا ہے۔ پہلا one halfway mark ہے، اور solid ground پر رہتا ہے۔

🔐Project 12-3 hoursاپنا sign-in harden کریںLogin کام کرتا ہے۔ اب اسے چوری کرنا مشکل اور enter کرنا آسان بنائیں۔

آپ کے پاس already working sign-in ہے۔ Working sign-in target بھی ہے: ایک leaked password اور کوئی اندر ہے۔ اس لیے آپ stable 2fa اور social-login specs کے ساتھ stakes دونوں طرف سے raise کرتے ہیں۔

دو new ideas اسے carry کرتی ہیں۔ Second factor password کے علاوہ second proof ہے: آپ کا doorman وہ code بھی check کرتا ہے جو صرف آپ کا phone دکھا سکتا ہے، اس لیے copied ID اکیلا کسی کو اندر نہیں لے جاتا۔ Social login بس second door ہے، Continue with Google entrance جو اندر اسی membership پر land کرتا ہے۔

Read specs/projects/2fa/spec.md and specs/projects/social-login/spec.md. Plan both, show me the plan, then build them in small steps. Harden the sign-in you already own with a second factor, and add a "Continue with Google" door. Run every acceptance check, including the adversarial security ones.

Done when correct password کے ساتھ wrong second factor refused ہو، backup code exactly ایک بار کام کرے، "Continue with Google" email-and-password user والے same dashboard پر land کرے، اور کوئی secret کبھی response body یا log میں appear نہ ہو۔

What just happened: آپ کا door اب دو proofs مانگتا ہے اور دو sides سے open ہوتا ہے، اور stolen password alone کسی کو اندر نہیں لے جاتا۔

Frontier: agents کے لیے identity

اب second half، اور یہی course کے exist کرنے کی وجہ ہے۔ اب تک ہر token human کے لیے کھڑا تھا: آپ signed in ہوئے، آپ کو band ملا، apps اور gateways نے اسے trust کیا۔ مگر Manufacturing path ایسے agents کے بارے میں ہے جو خود act کرتے ہیں۔ تو سوال بدلتا ہے: جب agent کچھ کرتا ہے تو کس کا band پہن رہا ہوتا ہے؟ اگر وہ بس آپ کا login reuse کرتا ہے، logs کہتے ہیں کہ آپ نے کیا، وہ سب کچھ کر سکتا ہے جو آپ کر سکتے ہیں، اور آپ agent کو revoke نہیں کر سکتے مگر خود کو lock out کیے بغیر۔ یہ wrong answer ہے، اور اسے fix کرنا پوری frontier ہے۔

یہی same picture، problem اور fix کے طور پر:

Same picture، problem اور fix: آج ہر agent آپ کے ایک master band کی copy پہنتا ہے، اس لیے bouncer انہیں الگ نہیں پہچان سکتا یا صرف ایک کو cut نہیں کر سکتا۔ Agent auth کے ساتھ ہر agent trusted host کے نیچے run کرتا ہے اور اپنا band پہنتا ہے؛ server exactly read کرتا ہے کہ کون act کر رہا ہے اور باقی کو touch کیے بغیر ایک کو snip کر سکتا ہے۔

یہ why ہے۔ How ایک short flow ہے جو ہر agent اپنا band لینے اور use کرنے کے لیے چلاتا ہے:

یہ تین projects Better Auth کے @better-auth/agent-auth plugin پر run کرتے ہیں، جو beta ہے، Agent Auth Protocol کی implementation۔ Honest framing سامنے رکھیں: specific API کو durable primitives کی ایک swappable instantiation سمجھیں، اور جس version پر land کریں اسے pin کریں۔ جو نہیں ہلتا وہ picture ہے، اسے hold رکھیں: agent کو اب اپنا band ملنے والا ہے۔

آپ zero سے start نہیں کرتے۔ Base نیچے تینوں projects کے لیے verified worked example ship کرتا ہے (worked-examples/ai-identity/ میں answer key)، اور ہر project ایک spec ہے جسے آپ drive کرتے ہیں، وہی loop جو آپ چھ بار چلا چکے ہیں۔

Agent کو اپنا band ملتا ہے

اب تک آپ guest تھے۔ یہاں new guest آتا ہے: AI agent۔ پہلا instinct اسے آپ کے band سے clip کرنا ہے، مگر یہی impersonation problem ہے۔ اس کے بجائے agent کو اپنا own band ملتا ہے، اپنے name میں، اسی kind کا band جو آپ نے اوپر والی picture کے right side پر دیکھا، جہاں ہر agent اپنا band پہنتا ہے۔

تین چیزیں اسے human sign-in سے different بناتی ہیں، اور یہی پوری idea ہے۔ First، agent اکیلا نہیں آتا؛ یہ ایک host کے اندر run کرتا ہے، runtime یا device جسے venue already trust کرتا ہے، اور host agent کو vouch کرتا ہے۔ Second، band self-sealed and short-lived ہے: agent اپنی key سے اپنا band sign کرتا ہے، اور band تقریباً ایک minute کے لیے good ہوتا ہے، اس لیے copied band leak ہوتے ہی stale ہو جاتا ہے (config file میں پڑے long-lived bearer token سے بہت different)۔ یہاں seal EdDSA ہے، Ed25519 curve، وہی algorithm جسے RS256 bartender نے step 5 میں reject کیا تھا، اور یہ contradiction نہیں۔ Different trust domains کے different signers ہوتے ہیں: OAuth issuer RS256 pin کرتا ہے، agent path EdDSA pin کرتا ہے۔ alg-pinning rule نہیں بدلا، صرف pinned algorithm بدلا، اس لیے wrong-algorithm band جو آپ نے پہلے forge کیا تھا یہاں بھی refused رہتا ہے۔ Third، band agent کو جو کرنے دیتا ہے وہ named capabilities کی list ہے، agent کا scope version۔ آپ یہ loop پہلے چلا چکے ہیں؛ یہ پھر ہے، new kind of guest پر aimed:

Read specs/projects/agent-credential/spec.md and .agents/skills/agent-identity-issuer/. Confirm the live agent-auth surface against the Better Auth docs MCP first, it is beta. Plan it, show me the plan, then build in small steps: enable autonomous agent identity, register an agent under a host, have it self-sign its own short-lived credential, and execute a granted capability. Run every acceptance check, including replay and revocation.

اب new idea visible کریں۔ پہلے دیکھیں band پر کس کا name ہے:

Register an autonomous agent and show me the credential it gets. Whose identity is the sub, a person's or the agent's own? Explain in plain English why the agent having its own band is different from it reusing my login.

پھر prove کریں کہ short-lived، self-sealed band theft کے خلاف resist کرتا ہے:

Take my agent's credential and replay the exact same signed band twice. Show me the second call being refused. Explain what the one-time marker is doing and why a band good for only a minute is safer than a long-lived token.

What just happened: agent نے آپ کا band borrow کرنا چھوڑ دیا اور اپنا band لے لیا۔ Logs اب کہتے ہیں agent نے کیا، band agent کے name میں ہے، اور صرف granted capabilities carry کرتا ہے۔

وہ tension جو آپ نے ابھی resolve کی

اس course میں دو promises ایک دوسرے کو کھینچتے ہیں۔ Bartender کبھی booth کو phone نہیں کرتا (offline JWKS)، مگر revoked band کی next call fail ہوتی ہے۔ Long-lived band کے لیے دونوں exactly true نہیں ہو سکتے، کیونکہ offline verifier کو mid-life یہ جاننے کا کوئی طریقہ نہیں کہ still-unexpired band pull کیا گیا ہے۔ Short-lived band اسے square کرتا ہے: جب band تقریباً ایک minute رہتا ہے، revoking simply not reissuing ہے، اس لیے current band window کے اندر خود die ہو جاتا ہے اور new one mint نہیں ہوتا۔ اسی لیے agent path long-lived bearer tokens کے بجائے one-minute bands پر lean کرتا ہے۔ Human OAuth path پر یہی tension وجہ ہے کہ revocation refresh gate پر bite کرتی ہے، وہ one place جو phone home کرتا ہے، ہر access band پر نہیں جو already wild میں ہے۔

On-behalf-of: stamped band

یہ وہ credential ہے جسے right کرنا سب سے زیادہ important ہے۔ Agent rarely purely اپنے لیے act کرتا ہے؛ عام طور پر وہ کسی person کے لیے act کرتا ہے، اور dangerous shortcut یہ ہے کہ اسے وہ person بننے دیں۔ On-behalf-of honest version ہے: band دونوں parties کے names رکھتا ہے، agent اور وہ person جس کے لیے یہ act کرتا ہے، اس لیے action ہمیشہ agent-for-Alice pair کو attributable ہوتا ہے، Alice alone کو کبھی نہیں۔ یہ opening picture والا stamped band ہے: acting for Alice, drinks only, void at midnight.

جو part اسے safe بناتا ہے وہ human approval in the loop ہے۔ Agent یہ band اپنے لیے mint نہیں کر سکتا۔ وہ ask کرتا ہے، Alice کو prompt ملتا ہے (device-code flow، وہی pattern جیسے TV کو streaming account میں login کرنا)، اور وہ yes کہتی ہے؛ authority اس کے بعد exist کرتی ہے۔ No approval، no band۔ اور کیونکہ Alice authority کا source ہے، وہ اسے واپس لے سکتی ہے: revoke کریں، اور agent کی next call fail ہوتی ہے۔ Paste کریں:

Read specs/projects/on-behalf-of/spec.md and .agents/skills/agent-identity-issuer/. Confirm the live agent-auth surface against the Better Auth docs MCP first, it is beta. Plan it, show me the plan, then build in small steps: enable delegated mode, have an agent request a scoped capability, gate it behind human device-code approval, and only then let it act. Run every acceptance check, including no-approval-no-grant and revocation.

پھر دیکھیں human gate واقعی hold کرتا ہے۔ پہلے approve کرنے سے پہلے stop کریں:

Have my agent request the right to act for me, then stop before I approve. Show me that it has nothing yet, no band, no access. Explain why "human in the loop" means the approval is the thing that mints the authority, not a formality after it.

پھر prove کریں کہ یہ delegation ہے، impersonation نہیں:

Approve the grant, then show me the band. Point out where it says both the agent and that it is acting on behalf of me. Explain why that pairing matters for an audit trail.

What just happened: agent اب آپ کے لیے act کر سکتا ہے، مگر صرف اس کے بعد جب آپ نے yes کہا، صرف اس حد تک جو آپ نے approve کی، اور صرف جب تک آپ revoke نہ کریں۔ یہ stamped band پہنتا ہے، کبھی آپ کا band نہیں۔

Band کو tighten کریں: scope، value، اور dangerous چیزوں کے لیے fingerprint

Stamped band already کہتا ہے drinks only۔ یہ step limits کو action کے risk کے مطابق tight کرتا ہے، تین ideas کے ساتھ جو plain scope string سے آگے جاتی ہیں۔

Capability named action ہے (agent share a note کر سکتا ہے)۔ Value-constraint اسے allowed values تک narrow کرتا ہے، صرف on/off نہیں: "may share notes" نہیں بلکہ "may share notes only with @acme.com." Scope string یہ express نہیں کر سکتی؛ constraint کر سکتا ہے، اور server اسی وقت check کرتا ہے جب agent act کرتا ہے، اس لیے @evil.com کو share refused ہوتا ہے چاہے capability on ہو۔ اور step-up approval human gate کو blast radius کے ساتھ scale کرتا ہے: read auto-grants، share کو logged-in human چاہیے، اور irreversible action (delete everything) کو physical presence چاہیے، fingerprint یا passkey، تاکہ AI agent جس کے پاس browser ہو وہ اپنی destruction پر approve خود click نہ کر سکے۔ یہ picture والا over $50 needs Alice ہے، مگر truly dangerous action کو Alice کی fingerprint چاہیے، صرف اس کا yes نہیں۔ Paste کریں:

Read specs/projects/step-up-approval/spec.md and .agents/skills/agent-identity-issuer/. Confirm the live agent-auth surface against the Better Auth docs MCP first, it is beta. Plan it, show me the plan, then build in small steps: three capabilities across the approval ladder (auto, session, physical-presence), one with a required value-constraint, and a single-use grant. Run every acceptance check, including the adversarial ones.

اب prove کریں کہ ہر limit bite کرتی ہے۔ پہلے value-constraint:

Give my agent the right to share notes, but only with @acme.com. Then have it try to share with @evil.com and show me exactly where the server refuses it. Explain why a value-constraint is stronger than an on-or-off scope.

پھر dangerous action پر step-up gate:

Try to approve the "delete everything" capability for my agent with just my logged-in session. Show me the server demanding physical presence instead of granting it, and explain what that step-up protects against when the agent itself has a browser.

What just happened: agent کا band اب job جتنا narrow ہے: capability تک scoped، allowed values تک pinned، اور action جتنا dangerous ہو اتنی hard gate، irreversible actions human fingerprint کے پیچھے locked۔

Maturity پر note: یہ hype نہیں، honest کیوں ہے

Course آپ کو durable primitives پر anchor کرنا سکھاتا ہے، وہ parts جو tooling churn کے دوران true رہتے ہیں: verified sign-in، agent کی own credential، on-behalf-of delegation، least-privilege scope، اور human approval۔ پھر یہ صاف کہتا ہے کہ ہر layer کتنی settled ہے:

• Stable spine آج production-grade ہے۔ Sign-in، issuer، scopes and consent، real app connect کرنا، اور resource server mature، open-source Better Auth stack پر run کرتے ہیں۔ پوری spine، CIMD سمیت، 1.7 line پر live verified ہوئی، اور Connector-Native Apps gateway نے اسی issuer کے signed tokens accept کیے۔ First half وہ چیز ہے جو آپ ship کر سکتے ہیں۔
• CIMD edge ہے۔ یہ کام کرتا ہے، pinned اور proven ہے، مگر Better Auth pre-release اور IETF draft standard پر رہتا ہے۔ Expect کریں کہ move کرے گا؛ build سے پہلے API re-confirm کریں۔
• Agent identity frontier ہے۔ Agent کو اپنی bounded، revocable، on-behalf-of authority دینا industry کی direction ہے۔ Anthropic نے human-agent teams سے signal کیا، اور Better Auth کے پاس early Agent Auth plugin ہے، مگر standards young ہیں اور still settling۔

Primitives پر anchor کرنے کا point یہی split ہے۔ Standards land ہوں گے تو mental model already fit کرے گا: credential پھر بھی band ہے، scope پھر بھی band کو بتاتا ہے کیا کر سکتے ہیں، expiry پھر بھی closing time ہے، اور human approval پھر بھی booth پر person کا yes کہنا ہے۔

یہ کہاں لے جاتا ہے

اب آپ کے پاس پوری identity layer کی through-line ہے۔ کسی بھی system کو ایک سوال پر اٹھائیں، یہ identity کس کی ہے، اور authority human سے agent تک کیسے گزرتی ہے، اور آپ اسے read کر سکتے ہیں: door، booth، band، اور bartender تلاش کریں، پھر پوچھیں کہ agent human کا band borrow کر رہا ہے یا اپنا carry کر رہا ہے۔

یہ Manufacturing path کے باقی حصے کے نیچے credential layer ہے۔ اگلا، Build AI Agents اس agent کو اس کا loop دیتا ہے، وہ reasoning اور tools جو decide کرتے ہیں کہ ابھی سیکھی ہوئی authority سے کیا کرنا ہے۔ اور Human-Agent Teams میں آپ اس identity کو کام پر لگاتے ہیں، people کے ساتھ agents کی roster چلاتے ہیں، ہر ایک کے پاس اپنا band اور صرف دی گئی authority۔

آپ نے identity borrow کرنا چھوڑ دیا۔ اب سے آپ اسے issue کرتے ہیں۔

Flashcards Study Aid

---

اپنی سمجھ جانچیں

Checking access...