AI Identity: Human Sign-In aur Agent Access

Aap identity borrow karna band karte hain aur usay issue karna shuru karte hain - aik spec at a time, agent ko direct karke

Apne Digital FTE ko 2 a.m. par kaam karte imagine karein, jab aap so rahe hain. Woh expense file karta hai, vendor book karta hai, reply bhejta hai. Aik sawal decide karta hai ke yeh safe hai ya hone wali disaster: us ne kis ki identity use ki?

Connector-Native Apps aur Plugins for AI Agents courses mein, aap ki app bas host chalane wale person ki identity borrow karti thi. Jab human chair par baitha hai, yeh theek hai. Lekin jo worker tab run karta hai jab koi human chair par nahin hai, woh human ka login borrow nahin kar sakta, kyun ke agar woh aap ke naam se login karta hai, to woh aap hai: woh woh sab kar sakta hai jo aap kar sakte hain, hamesha ke liye, aur har log kehta hai ke aap ne kiya. Usay scope karne, time-box karne, ya wapas lene ka koi tareeqa nahin rehta.

Yeh course woh jagah hai jahan identity borrowed rehna band karti hai. Aap isay do halves mein build karte hain. Pehle aap apna sign-in own karte hain: third-party login rent karne ke bajaye, aap production-grade authentication aur OAuth/OIDC server khara karte hain jo real tokens issue karta hai. Phir aap agent ko us ki apni identity dete hain: aisi credential jo scoped, time-boxed, revocable, aur human-approved hai, taake worker kisi person ki taraf se real work kar sake, kabhi us person ki impersonation kiye baghair.

Aakhir tak aap aik running app ship kar chuke honge (apni machine par real Next.js project), jo tartib se yeh hogi:

• aap ka apna email-and-password sign-in, real sessions aur protected dashboard ke sath;
• aik OAuth/OIDC issuer jo signed tokens mint karta hai aur apni keys (JWKS) publish karta hai taake koi bhi verify kar sake;
• aik second, separate app jo aap ke issuer ke through logon ko sign in karati hai, jabke aap ki koi secrets hold nahin karti;
• aik resource server jo un tokens ko offline verify karta hai aur sirf apne liye minted bands accept karta hai;
• aur aik beta agent credential: scoped, time-boxed, revocable, human-approved band jo AI worker apne naam mein carry karta hai.

Prerequisite: Spec-Driven Development

Yeh build course hai, aur yeh assume karta hai ke aap spec-driven loop already own karte hain: what par agree karein, phir agent ko how produce karne ke liye direct karein. SDD course ke unlike, yahan main tool claude.ai nahin hai. Yeh course repo-based hai: aap Claude Code ya OpenCode mein real Next.js app par kaam karte hain. Aap TypeScript haath se nahin likhenge; aap general agent ko direct karte hain aur woh code likhta hai, wahi move jo Manufacturing track ke har build course mein hai. Lekin yeh security course bhi hai, is liye code sirf aadha kaam hai: jo cheez aap ke paas rehti hai woh yeh hai ke aap specify karein kya built ho, phir har security property ko inspect, test, aur prove karein. Isi ko course bhar ke spec-less understand prompts drill karte hain: token decode karna, us ki audience tamper karna, usay replay karna, aur server ka refusal dekhna.

📚 Taleemi Madad

Full slideshow kholein

Full presentation dekhein — AI Identity: Human Sign-In aur Agent Access

Yeh course jis aik sawal ka jawab deta hai

Is ke baad aap jo bhi system build karein, usay aik test ke samne rakh sakte hain:

Yeh identity kis ki hai, aur authority human se agent tak kaise guzarti hai?

Yahi spine hai. Agent-identity standards settle hone tak specific tools badalte rahenge. Sawal nahin badlega.

Aik picture: venue aur wristband

Identity abstract lagti hai jab tak aap usay night out ki picture se map nahin karte. Yeh aik picture zehan mein rakhein aur course ka har piece apni jagah baith jayega.

Aap venue par pohanchte hain. Door par koi aap ki ID aik baar check karta hai: yahi signing in hai, yani prove karna ke aap kaun hain. Andar har bar par aapko ID phir se nahin dikhani parti. Is ke bajaye aik booth aapko wristband print karta hai. Band proof hai ke aapko andar ane ki ijazat hai; venue close hone par woh expire ho jata hai, aur bouncer misbehave karne par usay kaat sakta hai. Andar bartender bas band dekhta hai aur serve karta hai. Band par seal hai jo sirf booth bana sakta hai, is liye bartender usay dekhte hi trust karta hai, booth ko phone karke pooche baghair.

Yahi pura identity stack hai, scene ke har part ke liye aik term:

Aik model, har jagah use hota hai: door sign-in hai, booth issuer hai, band token hai, bartender validator hai. Frontier par, agent aap ka band borrow karna band karta hai aur apna band leta hai, kabhi kabhi kisi person ke liye tight limits mein act karne ki stamp ke sath.

Tokens ko chalane wala hissa notice karein: bartender kabhi booth ko call nahin karta. Band ki seal kaafi hai. Real systems mein woh seal cryptographic signature hai, aur booth woh key publish karta hai jis se koi bhi signature check kar sakta hai, jab ke signature banane wali key apne paas rakhta hai. Is liye koi stranger app aap ke tokens par trust kar sakti hai, aap ki database ya secrets ko touch kiye baghair.

Tokens aur sessions, zero se

Is course ke baqi hisse mein teen words baar baar ayenge. Yahan har word plain terms mein hai, usi picture par jo aap abhi hold kar rahe hain.

Session woh tareeqa hai jis se server yaad rakhta hai ke aap signed in hain. Door aap ki ID check karne ke baad browser mein aik chota marker set karta hai, aik cookie, aur har baad ki request par usay parhta hai, taake har page par phir sign in na karna pare. Session venue ka yeh janana hai ke aap aaj raat andar aye the.

Token wristband khud hai: signed claim ke aap kaun hain aur kya kar sakte hain. Common kind JWT (JSON Web Token) hai, dots se jure teen parts, header.payload.signature. Payload claims carry karta hai; signature booth ki seal hai.

Course ke baqi hisse ke liye yeh image hold karein. Booth apni wax seal daba kar band sign karta hai. Us seal ko banane wali stamp, booth ki private key, booth ke andar locked rehti hai aur kabhi bahar nahin jati, is liye koi aur mark copy nahin kar sakta. Duniya ko seal check karne dene ke liye booth door ke paas wall par us ki clear photo tape kar deta hai, yani published (public) key. Koi bhi band ko photo ke samne rakh kar confirm kar sakta hai ke seal genuine hai, lekin photo se working stamp carve nahin kar sakta. Trick yahi hai: photo kisi stranger ko band verify karne deti hai, magar forge nahin karne deti, aur bartender exactly isi par sight se trust karta hai.

OAuth, jis ke upar OIDC layer ho kar person kaun hai carry karta hai, woh agreed protocol hai us handshake ka jis mein booth kisi doosri app ke liye band print karta hai: aik app person ko sign in karne bhejti hai, aap ka server token wapas deta hai, aur doosri app usay read karti hai.

Try it

Koi bhi JWT lein, aap ki apni app kuch minutes mein mint karegi ya example paste karein, aur agent se kahen: "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." Is ka answer parhna is section ko dobara parhne se tez gut-check deta hai.

Apna environment set up karein, aik baar

Aap jo bhi build karenge woh aik chote folder ke andar hoga: course base. Yeh jaan boojh kar lean hai: is mein constitution, specs, prompts, aur aik skill hai, aur abhi koi app nahin hai. Aap ka pehla move agent ko app build karne ke liye direct karna hai, jo khud us loop ki pehli rep hai jisay aap pura rasta use karenge.

Isay aik baar download karein; wahi folder pure course mein kaam ayega.

Download ai-identity-base.zip

Ya agentfactory-manufacturing repo clone karein aur us ka ai-identity folder open karein. Kisi bhi tareeqe se, folder ko apne agent mein open karein:

cd ai-identity
claude

cd ai-identity
opencode

Sign-in data ke liye aapko free Neon Postgres database bhi chahiye, no credit card; base isay aap ke liye wire karta hai. Neeche wale second prompt se pehle isay set up karein.

Lesson 0 do prompts mein ata hai, taake kuch build hone se pehle aap ground prove hoti dekhein.

Step 1, environment prove karein. Paste karein:

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 silently skill name drop kar sakta hai, is liye agent confirm karta hai ke har skill waqai land hui. Done when: Node aur pnpm versions report karein, better-auth, shadcn, aur neon-postgres skills present hon, aur teeno MCP servers answer karein.

Abhi kya hua: Aap ne trained staff hire kiya aur phones wire kiye, magar abhi kuch build nahin kiya. Skills booth operator ki manuals hain, yani band kaise issue karna hai aur UI kaise build karni hai; MCP servers agent ki direct lines hain Neon control room aur live docs tak. Ground prove ho gayi; us par abhi kuch khara nahin hai.

Step 2, app scaffold karein. Pehle apni Neon database provision karein, phir paste karein:

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 mein scaffold karne se mana karta hai, is liye base ki recipe temp dir mein scaffold karti hai aur result wapas merge karti hai; conflicts mein base files win karti hain. Done when: pnpm dev http://localhost:3000 par plain landing page serve kare, aur pnpm build aur tsc dono clean run karein.

Abhi kya hua: building mojood hai. Dev server lights-on empty venue dikhata hai, aap ki machine par real app boot ho rahi hai, lekin abhi door, booth, aur bands nahin hain. Identity system rakhne ki jagah mil gayi hai, aur Lesson 1 exactly wahi banana shuru karta hai.

Quick Win: apni app mein signed in hon

Base ready hai, aur aap aik prompt door hain aisi sign-in screen se jisay aap own karte hain, real database ke sath. Pehle succeed karein, phir understand karein.

Paste karne se pehle, usi picture par woh chaar pieces naam dein jo yeh build karta hai. Email aur password sign-in door hai jo aap ki ID check karta hai, jisay aap pehli baar arrive karte waqt set karte hain. Session venue ka yeh yaad rakhna hai ke aap aaj raat andar aye the, pehle wali cookie se, taake har page par phir ID na dikhani pare. Protected route back room hai jahan sirf signed-in members ja sakte hain. Aur password hash woh one-way fingerprint hai jisay door aap ke actual password ki jagah rakhta hai, taake venue bhi usay wapas parh na sake.

Lesson 1, apna sign-in own karein. Paste karein:

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.

Aap plan review karte hain, agent build karta hai, aur aap account create karke dashboard par land karte hain jo prove karta hai ke aap kaun hain. Yahi win hai: sign-up, sign-in, sessions, aur protected page, sab aap ke own server par run ho raha hai.

Watch for: Better Auth ke POST endpoints aisi request reject karte hain jis ka Origin header trusted nahin hai, is liye base config aap ka dev origin pehle se list karta hai. Done when: aap account create karke aise dashboard par land karein jo aap ka name aur email dikhaye, aur aap ka password sirf one-way hash ke roop mein stored ho, jisay neeche wala understand prompt prove karta hai.

Ab isay apne liye real banayein, aik understand prompt se, jis ki koi spec nahin hai; yeh bas aapko dikhata hai ke aap ne kya banaya:

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?

Answer, ke aap ka password sirf one-way hash ke roop mein stored hai, is liye aap ka own server bhi usay parh kar nahin dikha sakta, is course ki pehli identity literacy hai. Aap ne isay paragraph mein nahin parha. Aap ne isay apne data par dekha.

Build path: login rent karne se usay issue karne tak

Course saat steps ki spine hai jo base ki specs se one-to-one map hoti hai. Aap har step short prompt paste karke build karte hain; spec detail carry karti hai aur skill exact API carry karti hai, is liye prose idea par rehta hai. Yeh pura arc hai, aur jahan yeh settled ground hona band karta hai.

Saat-step spine, phir milestone, phir frontier. Jitna right jate hain, standards utne young hote hain; mental model pura rasta wahi rehta hai.

0-1. Base set up karein, phir apna sign-in own karein

Aap ne inhein Quick Win mein dekha. Step 0 toolchain scaffold karta hai: Next.js, shadcn, Better Auth 1.7 stack, aur Neon. Step 1 email aur password sign-in khara karta hai, real server-side sessions aur protected dashboard ke sath. Yeh door hai: aap ke users prove karte hain ke woh kaun hain, aik baar.

2. Issuer banein, marquee step

Yeh woh step hai jis ki taraf pura track point kar raha tha. Connector-Native Apps mein aap bartender the: aap ka gateway kisi aur ke signed tokens validate karta tha. Yahan aap counter ke peeche jate hain aur booth bante hain. Jab doosri app person ko sign in karne aap ke paas bhejti hai, aap ka server signed token wapas deta hai jisay doosri app puri tarah apne dum par verify kar sakti hai, aap ke seal ki public photo check karke, password dekhe ya database call kiye baghair.

Loop band ho gaya: jis course ne aapko wristbands check karna sikhaya tha, ab wahi unhein print karna sikha raha hai.

Isay paste karne se pehle, us handshake se milen jo aap ka booth run karne wala hai. Jab OAuth client, yani doosra venue jo aap ki wristbands honor karne ko agree karta hai, person ko sign in karne bhejta hai, aap band ko us ke browser se wapas pass nahin karte. Aap authorization-code flow run karte hain: person aap ke booth par sign in karta hai, aap app ko short-lived code dete hain, claim-check stub ki tarah, aur app quietly us stub ko real token se swap karti hai out of sight, taake band khud browser se travel na kare. PKCE one-line proof hai ke handshake shuru karne wali wahi app usay finish kar rahi hai, is liye stolen stub kisi aur ke liye useless hai. Aur band print hone se pehle, person consent screen par approve karta hai ke app kya dekh sakti hai. Pehle wali seal ki public photo hi app ko band verify karne deti hai.

Yeh wahi plan, small steps, then check loop hai jo Quick Win mein tha, bas ab target bara hai. Kaam karne ka tareeqa naya nahin; bas build bhaari hai. Ready hon to paste karein:

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.

Aap OAuth configuration haath se nahin likhenge. Shipped agent-identity-issuer skill verified config carry karti hai, aur spec acceptance checks carry karti hai. Aap ka kaam build direct karna aur confirm karna hai ke woh pass karta hai, including security gates jinhein working-but-insecure version fail karega.

Aap ne build kiya; ab dekhein ke yeh waqai safe hai. Neeche wale prompts ki spec nahin hai. Har prompt aap ke own issuer par aik security property visible karta hai.

Pehle wall par photo dekhein. Aap ka JWKS endpoint exactly wahi wall hai: aap ke booth ki seal ki public photo, taake koi bhi band check kar sake. Seal dabane wali stamp, aap ki private signing key, booth mein locked rehti hai aur photo mein kabhi nahin hoti.

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.

Yahi gap point hai: sirf photo post karein, stamp kabhi nahin, aur duniya aap ke bands verify kar sakti hai jab ke koi unhein forge nahin kar sakta.

Phir abhi print kiya band read karein, aur aik character badal kar usay break karein:

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.

Aakhir mein band ko closing time ke past push karein:

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

Abhi kya hua: Aap counter ke peeche gaye. Jis course ne wristbands dekhna sikhaya tha, ab us ne unhein print karna sikhaya, aisi seal ke sath ke stranger app har one ko sight par trust kar sake booth ko phone kiye baghair, aur aap ne seal, audience stamp, aur expiry ko hold karte dekha.

3. Scopes aur consent

Token ko exactly kehna chahiye ke woh kya kar sakta hai, us se zyada nahin. Step 3 scope add karta hai, yani band ko kya karne ki ijazat hai, jaise drinks only stamped colored band banam drinks and kitchen; aur consent screen add karta hai jahan person approval se pehle exact list dekhta hai. Least privilege real ho gaya: band job karne wali narrowest authority carry karta hai, aur bartender har order par check karta hai, sirf door par nahin.

Aap yeh loop do baar run kar chuke hain. Yahan yeh phir hai, exactly aik new idea, scope, aap ke already-built issuer ke upar layered. Paste karein:

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.

Ab prove karein ke limit real hai, decoration nahin. Har prompt scope ko hold karte dikhata hai:

Pehle, khud ko narrow band dein aur overreach karne ki koshish karein:

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.

Phir us approval screen ko dekhein jo person waqai dekhta hai:

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.

Last, registered authority se zyada grab karne ki koshish karein:

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.

Abhi kya hua: Aap ke bands ab colors mein ate hain. Har one job karne wali narrowest authority carry karta hai, aur person ne band print hone se pehle exact list dekhi.

4. Real app connect karein

Ab prove karein ke booth aap ke ilawa kisi aur ke liye bhi kaam karta hai. Client app alag venue hai jo people ko aap ke through sign in karati hai, aap ki secrets share kiye baghair. Apne issuer ko AuthCo kahen aur new app ko Notes. Jab koi Notes mein sign in karta hai, woh usay AuthCo booth par bhejta hai, band wapas leta hai, aur AuthCo wall par posted seal photo ke against band ki seal puri tarah khud check karta hai. Notes kabhi password nahin dekhta aur aap ki database ko touch nahin karta.

Same rhythm, new actor. Saans lein: aap koi foreign cheez build nahin kar rahe, bas second, separate app ko us booth par point kar rahe hain jisay aap already own karte hain. Paste karein:

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.

Ab khud ko convince karein ke separation genuine hai. Har prompt us ka aik part visible karta hai:

Pehle, prove karein ke Notes aap ki koi secret hold nahin kar raha:

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 phir wahi photo hai: Notes ko band check karne ke liye AuthCo ki seal ki public photo chahiye, stamp nahin, is liye woh every token verify kar sakta hai jab ke AuthCo ki koi secret hold nahin karta.

Phir audience stamp ko aik character se break karein:

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.

Finally, booth se band cut karein aur next call fail hote dekhein:

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.

Abhi kya hua: Aik venue jisay aap control nahin karte, us ne aap ke booth se kisi ko sign in karaya aur band par apne dum par trust kiya, aap ki koi secret hold kiye baghair. Booth strangers ke liye kaam karta hai, sirf aap ke liye nahin.

5. Resource server connect karein

Resource server aisa bar hai jo sirf bands check karta hai aur kisi ko sign in nahin karata. Yeh exactly wahi bartender hai jo aap ne Connector-Native Apps mein play kiya tha, ab aap ki own ground par. Yeh bearer token leta hai, yani jo bhi band hold karta hai woh usay present karta hai aur koi extra ID nahin dikhata, aur band ki audience stamp read karta hai, good at THIS bar, is liye doosre bar ke liye minted band sight par refuse ho jata hai. Seal yahan specific signing algorithm (RS256) se bani hai, aur kisi bhi other way se sealed band bhi turn away hota hai. Yeh har seal AuthCo ki posted photo se check karta hai aur booth ko phone nahin karta, exactly wahi jo neeche build prompt mein verifying offline via JWKS hai.

Ab tak loop familiar lagna chahiye. One more actor, bar jo sirf bands check karta hai aur andar named person ko serve karta hai. Paste karein:

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 karein ke band sirf wahin kaam karta hai jahan intended hai. Har prompt aik rule ko visible banata hai:

Pehle, do tarah ke band side by side rakhein:

Show me two tokens side by side: the ID token from the login flow (lesson 4) and the access token a resource server gets. Point at the aud on each and explain in plain English why they're different.

Phir ghalat tareeqe se sealed band present karein:

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.

Last, valid band ko wrong bar par point karein:

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.

Abhi kya hua: Aap ne Connector-Native Apps wale bartender ko apni ground par stand up kiya. Woh har band check karta hai, sirf andar named person ko serve karta hai, aur kisi different bar ke liye minted ya wrong way sealed band ko turn away karta hai.

6. CIMD ke sath client identity, edge

Steps 0 se 5 settled, production-grade ground hain. Step 6 us ground se bahar jata hai. Ab tak app prove karti thi ke woh kaun hai client registration se: usay pehle se aap ke approved partner list mein spot milta tha. CIMD (Client ID Metadata Document) ke sath app list skip karti hai. Woh URL par public sign hang karti hai jo khud ko describe karta hai, aur aap ka booth pehli baar app ane par demand par woh sign read karta hai, bina pre-registration. MCP world isi taraf ja raha hai, lekin yeh Better Auth pre-release plugin aur IETF draft standard par run karta hai, is liye course aap se build se pehle live API confirm karwata hai.

Yeh woh aik jagah hai jahan build se pehle cheezein look up karein, kyun ke ground newer hai. Slow lein; prompt khud agent se live docs pehle check karne ko kehta hai, moving standard par yahi sahi instinct hai. Paste karein:

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.

Phir dekhein us one change ne kya switch on kiya. Har prompt new behavior visible karta hai:

Pehle, apni public sign par new line appear hote dekhein:

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.

Phir booth ko list ke bajaye sign read karte dekhein:

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?

Finally, usay bad sign dein aur refuse hote dekhein:

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.

Abhi kya hua: App ne aap ki guest list par wait karne ke bajaye public sign hang karke khud ko introduce kiya. Agent world isi taraf ja raha hai, aur aap ne isay aisi ground par build kiya jisay aap move hote dekh sakte hain.

~50% milestone: aap ka pehla project jisay aap drive karte hain

Spine ke baad, course fully specified, live-verified steps dena band karta hai aur aapko projects deta hai jinhein aap khud drive karte hain. Pehla halfway mark hai, aur stable ground par rehta hai.

🔐Project 12-3 hoursApne sign-in ko harden kareinLogin kaam karta hai. Ab isay chori karna mushkil aur enter karna asan banayein.

Aap ke paas already working sign-in hai. Working sign-in target bhi hai: aik leaked password aur koi andar hai. Is liye aap dono sides se stakes raise karte hain, base ki stable 2fa aur social-login specs ke sath.

Do new ideas isay carry karte hain. Second factor password ke ilawa second proof hai: aap ka doorman aisa code bhi check karta hai jo sirf aap ka phone dikha sakta hai, is liye copied ID akeli kisi ko andar nahin le jati. Social login bas doosra door hai, Continue with Google entrance jo andar usi membership par land karta hai.

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 ke sath wrong second factor refuse ho, backup code exactly once kaam kare, "Continue with Google" email-and-password user wale same dashboard par land kare, aur koi secret response body ya log mein kabhi na dikhe.

Abhi kya hua: Aap ka door ab do proofs mangta hai aur do sides se khulta hai, aur stolen password akela kisi ko andar nahin le jata.

Frontier: agents ke liye identity

Ab second half, aur course ke hone ki wajah. Ab tak har token human ke liye khara tha: aap ne sign in kiya, band mila, apps aur gateways ne us par trust kiya. Lekin Manufacturing path un agents ke bare mein hai jo apne dum par act karte hain. Is liye sawal badalta hai: jab agent kuch karta hai, woh kis ka band pehne hue hai? Agar woh aap ka login reuse karta hai, logs kehte hain ke aap ne kiya, woh woh sab kar sakta hai jo aap kar sakte hain, aur aap agent revoke nahin kar sakte bina khud ko lock out kiye. Yeh wrong answer hai, aur isay fix karna pura frontier hai.

Yeh same picture hai, problem aur fix ke roop mein:

Same picture, problem aur fix: aaj har agent aap ke one master band ki copy pehnta hai, is liye bouncer unhein alag nahin pehchan sakta ya sirf aik ko cut nahin kar sakta. Agent auth ke sath, har agent trusted host ke andar run karta hai aur apna band pehnta hai, aur server exactly parhta hai ke kaun act kar raha hai aur baqi ko chhuye baghair aik ko snip kar sakta hai.

Yeh why hai. How aik short flow hai jo har agent apna band lene aur use karne ke liye run karta hai:

Yeh teen steps Better Auth ke @better-auth/agent-auth plugin par run karte hain, jo beta hai, Agent Auth Protocol ka implementation. Honest framing front and center rakhein: specific API ko durable primitives ki one swappable instantiation samjhein, aur jis version par land karein usay pin karein. Jo nahin badalta woh picture hai, is liye usay hold rakhein: agent apna band lene wala hai.

Aap zero se start nahin karte. Base neeche ke teeno steps ke liye verified worked example ship karta hai, worked-examples/ai-identity/ mein answer key, aur har step aik spec hai jisay aap drive karte hain, wahi loop jo aap chhe baar run kar chuke hain.

Agent apna band leta hai

Ab tak guest aap the. Yahan new guest ata hai: AI agent. First instinct usay aap ke band se clip karna hai, lekin wahi impersonation problem hai. Is ke bajaye agent ko us ka own band milta hai, apne naam mein, picture wala agent #7 band.

Teen cheezein isay human sign-in se alag banati hain, aur yahi puri idea hai. First, agent akela arrive nahin karta; woh aik host ke andar run karta hai, runtime ya device jis par venue already trust karta hai, aur host agent ko vouch karta hai. Second, band self-sealed aur short-lived hai: agent apni key se apna band sign karta hai, aur band taqreeban aik minute ke liye good hai, is liye copied band leak hote hi stale ho jata hai, long-lived bearer token se bahut alag jo config file mein para rehta hai. Third, band agent ko jo karne deta hai woh named capabilities ki list hai, agent ka scope version. Aap ne yeh loop pehle run kiya hai; yahan yeh phir hai, new kind of guest ke liye:

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.

Ab new idea visible karein. Pehle dekhein band par kis ka name hai:

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.

Phir prove karein ke short-lived, self-sealed band theft resist karta hai:

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.

Abhi kya hua: agent ne aap ka band borrow karna band kiya aur apna band liya. Logs ab kehte hain ke agent ne kiya, band agent ke naam mein hai, aur woh sirf granted capabilities carry karta hai.

On-behalf-of: stamped band

Yeh credential sab se zyada right karna zaroori hai. Agent rarely sirf apne liye act karta hai; aksar woh person ke liye act karta hai, aur dangerous shortcut hai usay us person banne dena. On-behalf-of honest version hai: band dono parties naam deta hai, agent #7, Alice ke liye acting, is liye action hamesha agent-for-Alice pair ko attributable hai, Alice alone ko nahin. Picture wala stamped band yahi hai: for Alice, drinks only, void at midnight.

Safe banane wala part hai human approval in the loop. Agent yeh band khud mint nahin kar sakta. Woh ask karta hai, aur Alice ko prompt milta hai, device-code flow, jaise TV ko streaming account mein log in karna, aur authority exist hone se pehle woh yes kehti hai. No approval, no band. Aur kyun ke Alice authority ki source hai, woh isay wapas pull kar sakti hai: revoke karein, aur agent ki next call fail ho jati hai. Paste karein:

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.

Phir human gate ko actually hold karte dekhein. Pehle, approve karne se pehle stop karein:

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.

Phir prove karein ke yeh delegation hai, impersonation nahin:

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.

Abhi kya hua: agent ab aap ke liye act kar sakta hai, lekin sirf aap ke yes kehne ke baad, sirf usi ke andar jisay aap ne approve kiya, aur sirf revoke hone tak. Woh stamped band pehnta hai, aap ka band nahin.

Band tighten karein: scope, value, aur dangerous stuff ke liye fingerprint

Stamped band pehle hi kehta hai drinks only. Yeh step limits ko action ke hisaab se tight banata hai, teen ideas ke sath jo plain scope string se aage jate hain.

Capability named action hai, agent may share a note. Value-constraint isay allowed values tak narrow karta hai, sirf on/off nahin: "may share notes" nahin, balke "may share notes only with @acme.com." Scope string yeh express nahin kar sakta; constraint kar sakta hai, aur server isay usi moment check karta hai jab agent act karta hai, is liye @evil.com par share refuse ho jata hai even though capability on hai. Aur step-up approval human gate ko blast radius ke hisaab se scale karta hai: read auto-grants, share logged-in human mangta hai, aur irreversible action, delete everything, physical presence mangta hai, fingerprint ya passkey, taake AI agent jis ke paas browser hai woh apne destruction par khud approve click na kar sake. Picture ka over $50 needs Alice yahi hai, bas truly dangerous action ko Alice ki fingerprint chahiye, sirf say-so nahin. Paste karein:

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.

Ab prove karein ke har limit bite karti hai. Pehle, 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.

Phir dangerous action par 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.

Abhi kya hua: agent ka band ab job jitna narrow hai: capability scoped, allowed values se pinned, aur action jitna dangerous ho utni strong gate, irreversible actions human fingerprint ke peeche locked.

Maturity par note: yeh hype nahin, honest kyun hai

Course aapko durable primitives par anchor karna sikhata hai, woh parts jo tooling churn ke beech true rehte hain: verified sign-in, agent ki own credential, on-behalf-of delegation, least-privilege scope, aur human approval. Phir yeh saaf kehta hai ke har layer kitni settled hai:

• Stable spine aaj production-grade hai. Sign-in, issuer, scopes aur consent, real app connect karna, aur resource server sab mature, open-source Better Auth stack par run karte hain. Pura spine, plus CIMD, 1.7 line par live verify kiya gaya, aur Connector-Native Apps gateway ne isi issuer ke signed tokens accept kiye. First half woh cheez hai jisay aap ship kar sakte hain.
• CIMD edge hai. Yeh kaam karta hai, pinned aur proven hai, lekin Better Auth pre-release aur IETF draft standard par rehta hai. Is ke move hone ki umeed rakhein; build se pehle API re-confirm karein.
• Agent identity frontier hai. Agent ko us ki own bounded, revocable, on-behalf-of authority dena industry ki direction hai. Anthropic ne human-agent teams se signal diya, aur Better Auth ke paas early Agent Auth plugin hai, lekin standards young hain aur settle ho rahe hain.

Primitives par anchor karne ka point yahi hai. Standards land hone par mental model already fit karega: credential ab bhi band hai, scope ab bhi woh hai jo band karne deta hai, expiry ab bhi closing time hai, aur human approval ab bhi booth par person ka yes kehna hai.

Yeh kahan le jata hai

Ab aap ke paas puri identity layer ki through-line hai. Kisi bhi system ko aik sawal ke samne rakhein, yeh identity kis ki hai, aur authority human se agent tak kaise guzarti hai, aur aap usay read kar sakte hain: door, booth, band, aur bartender dhoondhein, phir poochein ke agent human ka band borrow kar raha hai ya apna band carry kar raha hai.

Yeh Manufacturing path ke baqi hisse ke neeche credential layer hai. Next, Build AI Agents us agent ko us ka loop deta hai, reasoning aur tools jo decide karte hain ke aap ne jo authority grant karna seekhi hai us se kya karna hai. Aur Human-Agent Teams mein aap is identity ko work mein lagate hain, people ke sath agents ki roster run karte hue, har agent apne band ke sath aur sirf utni authority ke sath jo usay di gayi hai.

Aap ne identity borrow karna band kar diya. Yahan se aage, aap usay issue karte hain.

Study ke liye Flashcards

---

Apni Samajh Test Karein

Checking access...