1 
2پاس ورڈز ان چیزوں میں سے ایک ہیں جنہیں ہم نے صرف اس لیے معمول بنایا ہے کہ ہم ان کے ساتھ برسوں سے رہتے ہیں۔ صارفین انہیں بھول جاتے ہیں، انہیں دوبارہ استعمال کرتے ہیں، انہیں وہ جگہ لکھتے ہیں جہاں انہیں نہیں کرنا چاہیے۔ ٹیموں کو ری سیٹ، پالیسیاں، ہیش، لیک، فشنگ اور سپورٹ کا انتظام کرنا چاہیے۔
3 
4passkey توثیق کو کامل نہیں بناتے ہیں، لیکن یہ ایک بہت بڑی پریشانی کو دور کرتے ہیں: سرور کو اب صارف کے ساتھ اشتراک کردہ کوئی راز نہیں رکھنا پڑتا ہے۔
5 
6## واقعی کیا ہوتا ہے۔
7 
8A passkey WebAuthn پر مبنی ایک سند ہے۔ جب صارف اسے بناتا ہے، تو آلہ ایک کلیدی جوڑا تیار کرتا ہے:
9 
10- ایک نجی کلید، جو آلہ پر یا پاس ورڈ مینیجر میں رہتی ہے۔
11- ایک عوامی کلید، جسے سرور محفوظ کر سکتا ہے۔
12 
13سرور میں لاگ ان ہونے پر "مجھے پاس ورڈ بتائیں" نہیں پوچھتا ہے۔ بے ترتیب چیلنج بھیجیں۔ آلہ اس پر نجی کلید سے دستخط کرتا ہے۔ سرور عوامی کلید کے ساتھ دستخط کی تصدیق کرتا ہے۔
14 
15یہ اچھا حصہ ہے: اگر ڈیٹا بیس چوری ہو جاتا ہے، تو کریک کرنے کے لیے اندر کوئی پاس ورڈ نہیں ہے۔ اور اگر کوئی صارف جعلی ڈومین پر ختم ہوتا ہے، تو passkey اس ڈومین کے لیے درست نہیں ہے۔ یہ صرف سہولت نہیں ہے، یہ فشنگ کے خلاف ٹھوس تحفظ ہے۔
16 
17## براؤزر ایک پل کا کام کرتا ہے۔
18 
19براؤزر میں دو اہم API ہیں:
20 
21- `navigator.credentials.create()` ایک passkey بنانے کے لیے؛
22- لاگ ان کے دوران اسے استعمال کرنے کے لیے `navigator.credentials.get()`۔
23 
24لیکن اہم منطق سرور پر ہے۔ سرور کو چیلنج پیدا کرنا چاہیے، اسے عارضی طور پر محفوظ کرنا چاہیے، جواب کی تصدیق کرنا چاہیے، ماخذ کی جانچ کرنا چاہیے اور Relying Party ID، پھر سیشن بنانا چاہیے۔
25 
26کلائنٹ کا حصہ تقریبا بورنگ ہونا چاہئے:
27 
28```typescript
29const options = await fetch('/api/passkeys/login/options').then((r) => r.json());
30 
31const credential = await navigator.credentials.get({
32  publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(options),
33});
34 
35await fetch('/api/passkeys/login/verify', {
36  method: 'POST',
37  headers: { 'Content-Type': 'application/json' },
38  body: JSON.stringify(credential?.toJSON()),
39});
40```
41 
42اگر آپ خود کو ہاتھ سے WebAuthn خفیہ کاری کو نافذ کرتے ہوئے پاتے ہیں تو رک جائیں۔ ایک مضبوط سرور سائیڈ لائبریری کا استعمال کریں۔ یہاں کی غلطیاں "پیارا کیڑے" نہیں ہیں، وہ توثیق کے سوراخ ہیں۔
43 
44## ڈیٹا بیس میں کیا محفوظ کرنا ہے۔
45 
46آدھی دنیا کو بچانے کی ضرورت نہیں ہے۔ عام طور پر کافی:
47 
48- اسناد کی شناخت؛
49- عوامی کلید؛
50- منسلک صارف؛
51- کوئی بھی تصدیقی کاؤنٹر یا میٹا ڈیٹا؛
52- نقل و حمل، اگر UX کے لیے مفید ہو؛
53- صارف کے ذریعہ منتخب کردہ نام؛
54- تخلیق کی تاریخ اور آخری استعمال۔
55 
56ایک کم سے کم ٹیبل اس طرح نظر آسکتا ہے:
57 
58```sql
59create table passkey_credentials (
60  id uuid primary key default gen_random_uuid(),
61  user_id uuid not null references users(id),
62  credential_id text not null unique,
63  public_key text not null,
64  name text,
65  created_at timestamptz not null default now(),
66  last_used_at timestamptz
67);
68```
69 
70پھر میں آڈٹ لاگ اور اطلاعات شامل کروں گا: اگر کوئی میرے اکاؤنٹ پر ایک نیا passkey بناتا ہے، میں اس کے بارے میں جاننا چاہتا ہوں۔
71 
72## UX ڈیمو سے زیادہ اہمیت رکھتا ہے۔
73 
74passkey کا ڈیمو ہمیشہ خوبصورت ہوتا ہے: آپ کلک کریں، Face ID، آپ داخل ہو گئے۔ اصل پروڈکٹ زیادہ پیچیدہ ہے۔
75 
76کوئی اپنا فون بدلتا ہے۔ کوئی بند کمپنی کا کمپیوٹر استعمال کرتا ہے۔ کچھ لوگ نہیں سمجھتے کہ براؤزر passkey کیوں تجویز کرتا ہے۔ کوئی اپنے آلے تک رسائی کھو دیتا ہے۔
77 
78یہی وجہ ہے کہ میں "آج سے ہر کسی کے لیے مزید پاس ورڈ نہیں" کے ساتھ شروع نہیں کروں گا۔ میں اس طرح شروع کروں گا:
79 
801. اندرونی صارفین کے لیے passkey اختیاری؛
812. کامیاب لاگ ان کے بعد ایک بنانے کی تجویز۔
823. نام تبدیل کرنے اور ہٹانے کے لیے اکاؤنٹ کا صفحہ passkey;
834. واضح فال بیک؛
845. مین لاگ ان میں بتدریج رول آؤٹ۔
85 
86انٹرفیس میں متن آسان ہونا چاہئے۔ "اپنے آلے کی لاک اسکرین کا استعمال کریں" اس سے بہتر ہے کہ "رہائشی FIDO2 اسناد کے ساتھ تصدیق کریں۔"
87 
88## غلطیوں سے بچوں گا۔
89 
90کلائنٹ پر چیلنجز پیدا نہ کریں۔ چیلنج سرور پر بنایا گیا ہے اور اس کی تصدیق صرف ایک بار ہونی چاہیے۔
91 
92صرف اسناد کی شناخت پر بھروسہ نہ کریں۔ آپ کو دستخط، چیلنج، اصلیت اور Relying Party ID کی تصدیق کرنے کی ضرورت ہے۔
93 
94فال بیکس کو حذف نہ کریں اس سے پہلے کہ آپ کے پاس بحالی کا اچھا بہاؤ ہو۔ پاس ورڈ لیس ہونے کی ضرورت نہیں ہے "اگر آپ اپنا فون کھو دیتے ہیں تو آپ ہمیشہ کے لیے باہر ہو جائیں گے"۔
95 
96passkey کو خالصتاً فرنٹ اینڈ بٹن نہ سمجھیں۔ بٹن کو چھپانا سیکیورٹی نہیں ہے: اصل تصدیق سرور کی طرف ہے۔
97 
98## Passkey-پہلا یا passkey-دوستانہ؟
99 
100ایک نئی پروڈکٹ کے لیے آپ passkey پہلے سوچ سکتے ہیں۔ موجودہ ایپ کے لیے میں passkey دوستانہ کو ترجیح دیتا ہوں: تجویز کردہ طریقہ کے طور پر passkey شامل کریں، کامیابی اور مسائل کی پیمائش کریں، پھر پرسکون طریقے سے پاس ورڈ کا وزن کم کریں۔
101 
102مثالی نقل مکانی محسوس نہیں کی جاتی۔ صارف کو پتہ چلتا ہے کہ لاگ ان کرنا آسان ہے، یہ نہیں کہ کمپنی نے اپنا تصدیقی پروٹوکول تبدیل کیا ہے۔
103 
104## نتیجہ
105 
106passkey دلچسپ ہیں کیونکہ وہ بیک وقت سیکیورٹی اور UX کو بہتر بناتے ہیں، جو کہ بہت کم ہے۔ وہ جادو کی چھڑی نہیں ہیں: بحالی، مطابقت، تعاون اور رول آؤٹ کو اچھی طرح سے ڈیزائن کیا جانا باقی ہے۔
107 
108لیکن بنیادی تبدیلی مضبوط ہے۔ صارفین سے رازوں کی ایجاد اور حفاظت کے لیے کہنا بند کریں۔ آپ آلہ کو اپنے ڈومین سے منسلک ایک خفیہ ثبوت پر دستخط کرنے دیتے ہیں۔ کم انسانی میموری، کم فشنگ، کم پاس ورڈ ری سیٹ۔ میں کہوں گا کہ وہ سنجیدگی سے لینے کے قابل ہیں۔
109 
110## ذرائع
111 
112- [MDN: Passkeys](https://developer.mozilla.org/en-US/docs/Web/Security/Authentication/Passkeys)
113- [MDN: Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API)
114- [W3C: Web Authentication](https://www.w3.org/TR/webauthn-3/)
115- [passkeys.dev](https://passkeys.dev/)
116