AI Identity: Human Sign-In और Agent Access

आप identity borrow करना बंद करते हैं और उसे issue करना शुरू करते हैं · एक spec at a time, agent को direct करके build किया गया

अपने Digital FTE को 2 a.m. पर काम करते हुए imagine करें, जब आप सो रहे हैं। वह expense file करता है, vendor book करता है, reply भेजता है। एक सवाल तय करता है कि यह safe है या होने वाली disaster: उसने किसकी identity use की?

Connector-Native Apps और Plugins for AI Agents courses में, आपकी app बस host चला रहे person की identity borrow करती थी। जब 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 लोगों को sign in कराती है, जबकि आपकी कोई secrets 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 है, और यह मानता है कि आप spec-driven loop already own करते हैं: what पर agree करें, फिर agent को how produce करने के लिए direct करें। SDD course से अलग, यहाँ main tool claude.ai नहीं है। यह course repo-based है: आप Claude Code या OpenCode में real Next.js app पर काम करते हैं। आप TypeScript हाथ से नहीं लिखेंगे; आप general agent को direct करते हैं और वह code लिखता है, वही move जो Manufacturing track के हर build course में है। लेकिन यह security course भी है, इसलिए code सिर्फ आधा काम है: जो चीज़ आपकी रहती है वह है specify करना कि क्या built हो, फिर हर security property को inspect, test, और prove करना। इसी को course में आने वाले spec-less understand prompts drill करते हैं: token decode करना, उसकी audience tamper करना, उसे replay करना, और server का refusal देखना।

📚 शिक्षण सहायता

Full slideshow खोलें

Full presentation देखें — AI Identity: Human Sign-In और Agent Access

यह course जिस एक सवाल का जवाब देता है

इसके बाद आप जो भी system build करें, उसे एक test के सामने रख सकते हैं:

यह identity किसकी है, और authority human से agent तक कैसे जाती है?

यही spine है। Agent-identity standards settle होने तक specific tools बदलते रहेंगे। सवाल नहीं बदलेगा।

एक picture: venue और wristband

Identity abstract लगती है जब तक आप उसे night out की picture से map नहीं करते। यह एक picture दिमाग़ में रखें और course का हर piece अपनी जगह बैठ जाएगा।

आप venue पर पहुँचते हैं। Door पर कोई आपकी ID एक बार check करता है: यही signing in है, यानी prove करना कि आप कौन हैं। अंदर हर bar पर आपको ID फिर से नहीं दिखानी पड़ती। इसके बजाय एक booth आपको wristband print करता है। Band proof है कि आपको अंदर आने की अनुमति है; venue close होने पर वह expire हो जाता है, और bouncer misbehave करने पर उसे काट सकता है। अंदर bartender बस band देखता है और serve करता है। Band पर seal है जो सिर्फ booth बना सकता है, इसलिए bartender उसे देखते ही trust करता है, booth को phone करके पूछे बिना।

यही पूरा identity stack है, scene के हर part के लिए एक term:

एक model, हर जगह use होता है: door sign-in है, booth issuer है, band token है, bartender validator है। Frontier पर, agent आपका band borrow करना बंद करता है और अपना band लेता है, कभी-कभी किसी person के लिए tight limits में act करने की stamp के साथ.

Tokens को चलाने वाला हिस्सा notice करें: bartender कभी booth को call नहीं करता। Band की seal काफ़ी है। Real systems में वह seal cryptographic signature है, और booth वह key publish करता है जिसकी मदद से कोई भी signature check कर सकता है, जबकि signature बनाने वाली key अपने पास रखता है। इसलिए कोई stranger app आपकी tokens पर trust कर सकती है, बिना आपकी database या secrets को छुए।

Tokens और sessions, zero से

इस course के बाकी हिस्से में तीन words बार-बार आएँगे। यहाँ हर word plain terms में है, उसी picture पर जिसे आप अभी hold कर रहे हैं।

Session वह तरीका है जिससे server याद रखता है कि आप signed in हैं। Door आपकी ID check करने के बाद browser में एक छोटा marker set करता है, एक cookie, और हर बाद की request पर उसे पढ़ता है, ताकि हर page पर फिर sign in न करना पड़े। Session venue का यह जानना है कि आप आज रात अंदर आए थे।

Token wristband खुद है: signed claim कि आप कौन हैं और क्या कर सकते हैं। Common kind JWT (JSON Web Token) है, dots से जुड़े तीन parts: header.payload.signature। Payload claims carry करता है; signature booth की seal है।

Course के बाकी हिस्से के लिए यह image hold करें। Booth अपनी wax seal दबाकर band sign करता है। उस seal को बनाने वाली stamp, booth की private key, booth के अंदर locked रहती है और कभी बाहर नहीं जाती, इसलिए कोई और mark copy नहीं कर सकता। दुनिया को seal check करने देने के लिए booth door के पास wall पर उसकी clear photo tape कर देता है, यानी published (public) key। कोई भी band को photo के सामने रखकर confirm कर सकता है कि seal genuine है, लेकिन photo से working stamp carve नहीं कर सकता। Trick यही है: photo किसी stranger को band verify करने देती है, मगर forge नहीं करने देती, और bartender exactly इसी पर sight से trust करता है।

OAuth, जिसके ऊपर OIDC layer होकर person कौन है carry करता है, वह agreed protocol है उस handshake का जिसमें booth किसी दूसरी app के लिए band print करता है: एक app person को sign in करने भेजती है, आपका server token वापस देता है, और दूसरी app उसे read करती है।

Try it

कोई भी JWT लें, आपकी अपनी app कुछ minutes में 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." इसका answer पढ़ना इस section को दोबारा पढ़ने से तेज़ gut-check देता है।

अपना environment set up करें, एक बार

आप जो भी build करेंगे वह एक छोटे folder के अंदर होगा: course base। यह जानबूझकर lean है: इसमें constitution, specs, prompts और एक skill है, और अभी कोई app नहीं है। आपका पहला move agent को app build करने के लिए direct करना है, जो खुद उस loop की पहली rep है जिसे आप पूरा रास्ता use करेंगे।

इसे एक बार download करें; वही folder पूरे course में काम आएगा।

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 भी चाहिए, no credit card; base इसे आपके लिए wire करता है। नीचे वाले second prompt से पहले इसे set up करें।

Lesson 0 दो prompts में आता है, ताकि कुछ build होने से पहले आप ground prove होते देखें।

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 silently skill name drop कर सकता है, इसलिए agent confirm करता है कि हर skill सच में land हुई। Done when: Node और pnpm versions report करें, better-auth, shadcn और neon-postgres skills present हों, और तीनों MCP servers answer करें।

अभी क्या हुआ: आपने 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 prove हो गया; उस पर अभी कुछ खड़ा नहीं है।

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 करने से मना करता है, इसलिए base की recipe temp dir में scaffold करती है और result वापस merge करती है, conflicts में base files win करती हैं। Done when: pnpm dev http://localhost:3000 पर plain landing page serve करे, और pnpm build और tsc दोनों clean run करें।

अभी क्या हुआ: building मौजूद है। Dev server lights-on empty venue दिखाता है, आपकी machine पर real app boot हो रही है, लेकिन अभी door, booth और bands नहीं हैं। Identity system रखने की जगह मिल गई है, और Lesson 1 exactly वही बनाना शुरू करता है।

Quick Win: अपनी app में signed in हों

Base ready है, और आप एक prompt दूर हैं ऐसी sign-in screen से जिसे आप own करते हैं, real database के साथ। पहले succeed करें, फिर understand करें।

Paste करने से पहले, उसी picture पर वह चार pieces नाम दें जो यह build करता है। Email और password sign-in door है जो आपकी ID check करता है, जिसे आप पहली बार arrive करते समय set करते हैं। Session venue का यह याद रखना है कि आप आज रात अंदर आए थे, पहले वाली cookie से, ताकि हर page पर फिर ID न दिखानी पड़े। Protected route back room है जहाँ सिर्फ signed-in members जा सकते हैं। और password hash वह one-way fingerprint है जिसे door आपके actual password की जगह रखता है, ताकि venue भी उसे वापस पढ़ न सके।

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, सब आपके own server पर run हो रहा है।

Watch for: Better Auth के POST endpoints ऐसी request reject करते हैं जिसका Origin header trusted नहीं है, इसलिए base config आपका dev origin पहले से list करता है। Done when: आप account create करके ऐसे dashboard पर land करें जो आपका name और email दिखाए, और आपका password सिर्फ one-way hash के रूप में stored हो, जिसे नीचे वाला understand prompt prove करता है।

अब इसे अपने लिए real बनाएँ, एक understand prompt से, जिसकी कोई spec नहीं है; यह बस आपको दिखाता है कि आपने क्या बनाया:

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, कि आपका password सिर्फ one-way hash के रूप में stored है, इसलिए आपका own server भी उसे पढ़कर नहीं दिखा सकता, इस course की पहली identity literacy है। आपने इसे 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 होना बंद करता है।

सात-step spine, फिर milestone, फिर frontier। जितना right जाते हैं, standards उतने young होते हैं; mental model पूरा रास्ता वही रहता है.

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 email और password sign-in खड़ा करता है, real server-side sessions और protected dashboard के साथ। यह door है: आपके users prove करते हैं कि वे कौन हैं, एक बार।

2. Issuer बनें, marquee step

यह वह step है जिसकी तरफ़ पूरा track point कर रहा था। Connector-Native Apps में आप bartender थे: आपका gateway किसी और के signed tokens validate करता था। यहाँ आप counter के पीछे जाते हैं और booth बनते हैं। जब दूसरी app person को sign in करने आपके पास भेजती है, आपका server signed token वापस देता है जिसे दूसरी app पूरी तरह अपने दम पर verify कर सकती है, आपके seal की public photo check करके, बिना password देखे या database call किए।

Loop बंद हो गया: जिस course ने आपको wristbands check करना सिखाया था, अब वही उन्हें print करना सिखा रहा है।

इसे paste करने से पहले, उस handshake से मिलें जो आपका booth run करने वाला है। जब OAuth client, यानी दूसरा venue जो आपकी wristbands honor करने को agree करता है, person को sign in करने भेजता है, आप band को उसके browser से वापस pass नहीं करते। आप authorization-code flow run करते हैं: person आपके booth पर sign in करता है, आप app को short-lived code देते हैं, claim-check stub की तरह, और app quietly उस stub को real token से swap करती है out of sight, ताकि band खुद browser से travel न करे। PKCE one-line proof है कि handshake शुरू करने वाली वही app उसे finish कर रही है, इसलिए stolen stub किसी और के लिए useless है। और band print होने से पहले, person consent screen पर approve करता है कि app क्या देख सकती है। पहले वाली seal की public photo ही app को band verify करने देती है।

यह वही plan, small steps, then check loop है जो Quick Win में था, बस अब target बड़ा है। काम करने का तरीका नया नहीं; बस build भारी है। 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 करता है, including security gates जिन्हें working-but-insecure version fail करेगा।

आपने build किया; अब देखें कि यह सच में safe है। नीचे वाले prompts की spec नहीं है। हर prompt आपके own issuer पर एक security property visible करता है।

पहले wall पर photo देखें। आपका JWKS endpoint exactly वही wall है: आपके booth की seal की public photo, ताकि कोई भी band check कर सके। Seal दबाने वाली 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 point है: सिर्फ 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 के past push करें:

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

अभी क्या हुआ: आप counter के पीछे गए। जिस course ने wristbands देखना सिखाया था, अब उसने उन्हें print करना सिखाया, ऐसी seal के साथ कि stranger app हर one को sight पर trust कर सके बिना booth को phone किए, और आपने seal, audience stamp और expiry को hold करते देखा।

3. Scopes और consent

Token को exactly कहना चाहिए कि वह क्या कर सकता है, उससे ज़्यादा नहीं। Step 3 scope add करता है, यानी band को क्या करने की अनुमति है, जैसे drinks only stamped colored band बनाम drinks and kitchen; और consent screen add करता है जहाँ person approval से पहले exact list देखता है। Least privilege real हो गया: band job करने वाली narrowest authority carry करता है, और bartender हर order पर check करता है, सिर्फ door पर नहीं।

आप यह loop दो बार run कर चुके हैं। यहाँ यह फिर है, exactly एक new idea, scope, आपके already-built issuer के ऊपर layered। 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.

Last, 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.

अभी क्या हुआ: आपके bands अब colors में आते हैं। हर one job करने वाली narrowest authority carry करता है, और person ने band print होने से पहले exact list देखी।

4. Real app connect करें

अब prove करें कि booth आपके अलावा किसी और के लिए भी काम करता है। Client app अलग venue है जो people को आपके through sign in कराती है, आपकी secrets share किए बिना। अपने issuer को AuthCo कहें और new app को Notes। जब कोई Notes में sign in करता है, वह उसे AuthCo booth पर भेजता है, band वापस लेता है, और AuthCo wall पर posted seal photo के against 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 आपकी कोई secret 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 नहीं, इसलिए वह every token verify कर सकता है जबकि AuthCo की कोई secret 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.

Finally, 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.

अभी क्या हुआ: एक venue जिसे आप control नहीं करते, उसने आपके booth से किसी को sign in कराया और band पर अपने दम पर trust किया, आपकी कोई secret hold किए बिना। Booth strangers के लिए काम करता है, सिर्फ आपके लिए नहीं।

5. Resource server connect करें

Resource server ऐसा bar है जो सिर्फ bands check करता है और किसी को sign in नहीं कराता। यह exactly वही bartender है जो आपने Connector-Native Apps में play किया था, अब आपकी own ground पर। यह bearer token लेता है, यानी जो भी band hold करता है वह उसे present करता है और कोई extra ID नहीं दिखाता, और band की audience stamp read करता है, good at THIS bar, इसलिए दूसरे bar के लिए minted band sight पर refuse हो जाता है। Seal यहाँ specific signing algorithm (RS256) से बनी है, और किसी भी other way से sealed band भी turn away होता है। यह हर seal AuthCo की posted photo से check करता है और booth को phone नहीं करता, exactly वही जो नीचे build prompt में verifying offline via JWKS है।

अब तक loop familiar लगना चाहिए। One more 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 बनाता है:

पहले, दो तरह के band side by side रखें:

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.

फिर गलत तरीके से 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.

Last, valid band को wrong 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.

अभी क्या हुआ: आपने Connector-Native Apps वाले bartender को अपनी ground पर stand up किया। वह हर band check करता है, सिर्फ अंदर named person को serve करता है, और किसी different bar के लिए minted या wrong way sealed band को turn away करता है।

6. CIMD के साथ client identity, edge

Steps 0 से 5 settled, production-grade ground हैं। Step 6 उस ground से बाहर जाता है। अब तक app prove करती थी कि वह कौन है client registration से: उसे पहले से आपके approved partner list में spot मिलता था। CIMD (Client ID Metadata Document) के साथ app list skip करती है। वह URL पर public sign hang करती है जो खुद को describe करता है, और आपका booth पहली बार app आने पर demand पर वह sign read करता है, बिना pre-registration। MCP world इसी तरफ़ जा रहा है, लेकिन यह Better Auth pre-release plugin और IETF draft standard पर run करता है, इसलिए course आपसे build से पहले live API confirm करवाता है।

यह वह एक जगह है जहाँ build से पहले चीज़ें look up करें, क्योंकि ground newer है। Slow लें; prompt खुद agent से live docs पहले check करने को कहता है, moving standard पर यही सही 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.

फिर देखें उस one change ने क्या switch on किया। हर prompt new behavior visible करता है:

पहले, अपनी public sign पर new line appear होते देखें:

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?

Finally, उसे 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.

अभी क्या हुआ: app ने आपकी guest list पर wait करने के बजाय public sign hang करके खुद को introduce किया। Agent world इसी तरफ़ जा रहा है, और आपने इसे ऐसी ground पर build किया जिसे आप move होते देख सकते हैं।

~50% milestone: आपका पहला project जिसे आप drive करते हैं

Spine के बाद, course fully specified, live-verified steps देना बंद करता है और आपको projects देता है जिन्हें आप खुद drive करते हैं। पहला halfway mark है, और stable ground पर रहता है।

🔐Project 12-3 hoursअपने sign-in को harden करेंLogin काम करता है। अब इसे चोरी करना मुश्किल और enter करना आसान बनाएँ।

आपके पास already working sign-in है। Working sign-in target भी है: एक leaked password और कोई अंदर है। इसलिए आप दोनों sides से stakes raise करते हैं, base की stable 2fa और social-login specs के साथ।

दो new ideas इसे carry करते हैं। Second factor password के अलावा second proof है: आपका doorman ऐसा code भी check करता है जो सिर्फ आपका phone दिखा सकता है, इसलिए copied ID अकेले किसी को अंदर नहीं ले जाती। Social login बस दूसरा 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 refuse हो, backup code exactly once काम करे, "Continue with Google" email-and-password user वाले same dashboard पर land करे, और कोई secret response body या log में कभी न दिखे।

अभी क्या हुआ: आपका door अब दो proofs माँगता है और दो sides से खुलता है, और stolen password अकेला किसी को अंदर नहीं ले जाता।

Frontier: agents के लिए identity

अब second half, और course के होने की वजह। अब तक हर token human के लिए खड़ा था: आपने sign 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 आपके one master band की copy पहनता है, इसलिए bouncer उन्हें अलग नहीं पहचान सकता या सिर्फ एक को cut नहीं कर सकता। Agent auth के साथ, हर agent trusted host के अंदर run करता है और अपना band पहनता है, और server exactly पढ़ता है कि कौन act कर रहा है और बाकी को छुए बिना एक को snip कर सकता है.

यह why है। How एक short flow है जो हर agent अपना band लेने और use करने के लिए run करता है:

ये तीन steps Better Auth के @better-auth/agent-auth plugin पर run करते हैं, जो beta है, Agent Auth Protocol का implementation। Honest framing front and center रखें: specific API को durable primitives की one swappable instantiation मानें, और जिस version पर land करें उसे pin करें। जो नहीं बदलता वह picture है, इसलिए उसे hold रखें: agent अपना band लेने वाला है।

आप zero से start नहीं करते। Base नीचे के तीनों steps के लिए verified worked example ship करता है, worked-examples/ai-identity/ में answer key, और हर step एक spec है जिसे आप drive करते हैं, वही loop जो आप छह बार run कर चुके हैं।

Agent अपना band लेता है

अब तक guest आप थे। यहाँ new guest आता है: AI agent। First instinct उसे आपके band से clip करना है, लेकिन वही impersonation problem है। इसके बजाय agent को उसका own band मिलता है, अपने नाम में, picture वाला agent #7 band।

तीन चीज़ें इसे human sign-in से अलग बनाती हैं, और यही पूरी idea है। First, agent अकेला arrive नहीं करता; वह एक host के अंदर run करता है, runtime या device जिस पर venue already trust करता है, और host agent को vouch करता है। Second, band self-sealed और short-lived है: agent अपनी key से अपना band sign करता है, और band लगभग एक minute के लिए good है, इसलिए copied band leak होते ही stale हो जाता है, long-lived bearer token से बहुत अलग जो config file में पड़ा रहता है। Third, band agent को जो करने देता है वह named capabilities की list है, agent का scope version। आपने यह loop पहले run किया है; यहाँ यह फिर है, new kind of guest के लिए:

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.

अभी क्या हुआ: agent ने आपका band borrow करना बंद किया और अपना band लिया। Logs अब कहते हैं कि agent ने किया, band agent के नाम में है, और वह सिर्फ granted capabilities carry करता है।

On-behalf-of: stamped band

यह credential सबसे ज़्यादा right करना ज़रूरी है। Agent rarely सिर्फ अपने लिए act करता है; अक्सर वह person के लिए act करता है, और dangerous shortcut है उसे उस person बनने देना। On-behalf-of honest version है: band दोनों parties नाम देता है, agent #7, Alice के लिए acting, इसलिए action हमेशा agent-for-Alice pair को attributable है, Alice alone को नहीं। Picture वाला stamped band यही है: for Alice, drinks only, void at midnight.

Safe बनाने वाला part है human approval in the loop। Agent यह band खुद mint नहीं कर सकता। वह ask करता है, और Alice को prompt मिलता है, device-code flow, जैसे TV को streaming account में log in करना, और authority exist होने से पहले वह yes कहती है। No approval, no band। और क्योंकि Alice authority की source है, वह इसे वापस pull कर सकती है: 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 को actually 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.

अभी क्या हुआ: agent अब आपके लिए act कर सकता है, लेकिन सिर्फ आपके yes कहने के बाद, सिर्फ उसी के अंदर जिसे आपने approve किया, और सिर्फ revoke होने तक। वह stamped band पहनता है, आपका band नहीं।

Band tighten करें: scope, value और dangerous stuff के लिए fingerprint

Stamped band पहले ही कहता है drinks only। यह step limits को action के हिसाब से tight बनाता है, तीन ideas के साथ जो plain scope string से आगे जाते हैं।

Capability named action है, agent may 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 इसे उसी moment check करता है जब agent act करता है, इसलिए @evil.com पर share refuse हो जाता है even though 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 चाहिए, सिर्फ say-so नहीं। 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.

अभी क्या हुआ: agent का band अब job जितना narrow है: capability scoped, allowed values से pinned, और action जितना dangerous हो उतनी strong 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 और consent, real app connect करना और resource server सब mature, open-source Better Auth stack पर run करते हैं। पूरा spine, plus CIMD, 1.7 line पर live verify किया गया, और Connector-Native Apps gateway ने इसी issuer के signed tokens accept किए। First half वह चीज़ है जिसे आप ship कर सकते हैं।
• CIMD edge है। यह काम करता है, pinned और proven है, लेकिन Better Auth pre-release और IETF draft standard पर रहता है। इसके move होने की उम्मीद रखें; build से पहले API re-confirm करें।
• Agent identity frontier है। Agent को उसकी own bounded, revocable, on-behalf-of authority देना industry की direction है। Anthropic ने human-agent teams से signal दिया, और Better Auth के पास early Agent Auth plugin है, लेकिन standards young हैं और settle हो रहे हैं।

Primitives पर anchor करने का point यही है। 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 कर रहा है या अपना band carry कर रहा है।

यह Manufacturing path के बाकी हिस्से के नीचे credential layer है। Next, Build AI Agents उस agent को उसका loop देता है, reasoning और tools जो decide करते हैं कि आपने जो authority grant करना सीखा है उससे क्या करना है। और Human-Agent Teams में आप इस identity को work में लगाते हैं, people के साथ agents की roster run करते हुए, हर agent अपने band के साथ और सिर्फ उतनी authority के साथ जो उसे दी गई है।

आपने identity borrow करना बंद कर दिया। यहाँ से आगे, आप उसे issue करते हैं।

Flashcards Study Aid

---

Test Your Understanding

Checking access...