JWT توثیق: 2026 میں سیکیورٹی کے بہترین طریقے

JSON ویب ٹوکن ہر جگہ ہیں — لیکن زیادہ تر نفاذ میں کم از کم ایک اہم حفاظتی خامی ہے۔ حملے کی سطح اس کی نظر سے بڑی ہے: الگورتھم کنفیوژن حملے، XSS کے ذریعے ٹوکن کی چوری، میعاد ختم ہونے کی توثیق کی گمشدگی، اور غلط خفیہ انتظام پروڈکشن سسٹمز میں پائے جانے والے سب سے عام کمزوریوں میں سے ہیں۔ JWT کا حق حاصل کرنا لائبریری کو کال کرنے اور آگے بڑھنے کا معاملہ نہیں ہے۔ اسے ہر سطح پر جان بوجھ کر فیصلے کرنے کی ضرورت ہے۔

اس گائیڈ میں مکمل JWT سیکیورٹی لائف سائیکل کا احاطہ کیا گیا ہے — اسٹوریج، گردش، تنسیخ، اور حقیقی دنیا کے NestJS نفاذ کے پیٹرن کے ذریعے الگورتھم کے انتخاب اور ٹوکن ڈھانچے پر دستخط کرنے سے — تاکہ آپ ایسی تصدیق تیار کر سکیں جو حقیقت میں حملے کی زد میں ہو۔

اہم ٹیک ویز

• تقسیم شدہ نظاموں کے لیے ہمیشہ RS256 (غیر متناسب) استعمال کریں۔ HS256 صرف اس صورت میں جب API سرور دونوں جاری کنندہ اور تصدیق کنندہ ہو۔
• HttpOnly, Secure, SameSite=Lax کوکیز میں ٹوکن اسٹور کریں — کبھی بھی لوکل اسٹوریج یا سیشن اسٹوریج میں
• ہمیشہ exp، iss، aud، اور alg دعووں کی توثیق کریں — کبھی بھی غیر دستخط شدہ none الگورتھم پر بھروسہ نہ کریں
• ریفریش ٹوکن روٹیشن کو لاگو کریں: ہر ریفریش ایک نیا جوڑا جاری کرتا ہے اور پرانے ریفریش ٹوکن کو باطل کرتا ہے۔
• رسائی ٹوکن TTL مختصر رکھیں (15 منٹ)؛ ڈیٹا بیس میں ذخیرہ شدہ مبہم ریفریش ٹوکن استعمال کریں۔
• JWT پے لوڈز میں کبھی بھی حساس ڈیٹا (پاس ورڈز، SSNs، ادائیگی کی معلومات) کو ذخیرہ نہ کریں — پے لوڈ بیس 64 ہیں، انکرپٹڈ نہیں ہیں۔
• ڈیٹا بیس میں Redis denylist یا ورژن کاؤنٹر کے ذریعے ٹوکن کی منسوخی کو لاگو کریں۔
• سیکیورٹی آڈٹ ٹریلز کے لیے تمام ٹوکن جاری کرنے اور ایونٹس کو ریفریش کریں۔

---

JWT کی ساخت اور دعوے

JWT کے تین حصے ہوتے ہیں: ہیڈر، پے لوڈ، اور دستخط، نقطوں سے الگ اور base64url-encoded۔

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiJ1c2VyXzEyMyIsImVtYWlsIjoidXNlckBleGFtcGxlLmNvbSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTc0MjM0NTYwMCwiZXhwIjoxNzQyMzQ2NTAwLCJpc3MiOiJodHRwczovL2FwaS5leGFtcGxlLmNvbSIsImF1ZCI6Imh0dHBzOi8vYXBwLmV4YW1wbGUuY29tIn0.
[signature]

ڈی کوڈ شدہ پے لوڈ:

{
  "sub": "user_123",
  "email": "[email protected]",
  "role": "admin",
  "iat": 1742345600,
  "exp": 1742346500,
  "iss": "https://api.example.com",
  "aud": "https://app.example.com"
}

پیداوار کے لیے مطلوبہ دعوے:

• sub — منفرد صارف شناخت کنندہ (کبھی اکیلے ای میل نہ کریں - ای میلز تبدیل)
• exp - ایکسپائری ٹائم اسٹیمپ (ہمیشہ ضروری)
• iat — جاری کردہ ٹائم اسٹیمپ (گھڑی کی ترچھی کا پتہ لگائیں)
• iss — جاری کنندہ URL (اپنے متوقع جاری کنندہ کے خلاف توثیق کریں)
• aud — سامعین (سروسز میں ٹوکن کے دوبارہ استعمال کو روکنے کے لیے توثیق کریں)
• jti — JWT ID (منفرد فی ٹوکن، درست منسوخی کو قابل بناتا ہے)

---

RS256 بمقابلہ HS256: کون سا الگورتھم استعمال کرنا ہے۔

JWT کنفیگریشن میں یہ واحد سب سے زیادہ مؤثر سیکورٹی فیصلہ ہے۔

HS256 (HMAC-SHA256) — ہم آہنگ

// Both signing and verifying require the same secret
const token = jwt.sign(payload, process.env.JWT_SECRET, { algorithm: 'HS256' });
const verified = jwt.verify(token, process.env.JWT_SECRET);

صرف اس وقت استعمال کریں جب: ٹوکن پر دستخط کرنے والی سروس وہی سروس ہے جو ان کی تصدیق کرتی ہے۔ HS256 یک سنگی APIs کے لیے ٹھیک ہے لیکن مائیکرو سروسز میں خطرناک ہے — کوئی بھی سروس جو ٹوکنز کی تصدیق کر سکتی ہے وہ بھی انہیں بنا سکتی ہے۔

RS256 (RSA-SHA256) — غیر متناسب

// Sign with private key (only the auth server holds this)
const privateKey = fs.readFileSync('/secrets/jwt-private.pem');
const token = jwt.sign(payload, privateKey, { algorithm: 'RS256', keyid: 'key-2026-01' });

// Verify with public key (any service can do this safely)
const publicKey = fs.readFileSync('/secrets/jwt-public.pem');
const verified = jwt.verify(token, publicKey, {
  algorithms: ['RS256'], // NEVER omit this — prevents algorithm confusion
  issuer: 'https://auth.example.com',
  audience: 'https://api.example.com',
});

ایک پروڈکشن RSA کلیدی جوڑا بنائیں:

# Generate 4096-bit RSA private key
openssl genrsa -out jwt-private.pem 4096

# Extract public key
openssl rsa -in jwt-private.pem -pubout -out jwt-public.pem

کلیدی گردش: ہیڈر میں keyid (kid) استعمال کریں۔ موجودہ عوامی کلیدوں کو /.well-known/jwks.json پر شائع کریں۔ سروسز JWKS کو کیش کرتی ہیں اور نامعلوم kid پر بازیافت کرتی ہیں۔

---

Http صرف کوکی اسٹوریج

یہ غیر گفت و شنید ہے۔ ٹوکنز کو localStorage یا sessionStorage میں ذخیرہ کرنا انہیں صفحہ پر چلنے والے کسی بھی JavaScript تک رسائی کے قابل بناتا ہے — بشمول XSS حملوں سے انجیکشن شدہ اسکرپٹس۔

// NestJS: set HttpOnly cookie after authentication
@Post('login')
async login(@Body() dto: LoginDto, @Res({ passthrough: true }) res: Response) {
  const { accessToken, refreshToken } = await this.authService.login(dto);

  const cookieBase = {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax' as const,
    path: '/',
    domain: process.env.COOKIE_DOMAIN, // '.example.com' for subdomain sharing
  };

  res.cookie('access_token', accessToken, {
    ...cookieBase,
    maxAge: 15 * 60 * 1000, // 15 minutes
  });

  res.cookie('refresh_token', refreshToken, {
    ...cookieBase,
    maxAge: 30 * 24 * 60 * 60 * 1000, // 30 days
    path: '/auth/refresh', // Scope refresh token to only the refresh endpoint
  });

  return { message: 'Login successful' };
}

// Extract token from cookie in JWT strategy
@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy, 'jwt') {
  constructor(private configService: ConfigService) {
    super({
      jwtFromRequest: ExtractJwt.fromExtractors([
        (req) => req?.cookies?.access_token, // Cookie first
        ExtractJwt.fromAuthHeaderAsBearerToken(), // Bearer fallback for API clients
      ]),
      secretOrKey: configService.get('JWT_PUBLIC_KEY'),
      algorithms: ['RS256'],
      issuer: configService.get('JWT_ISSUER'),
      audience: configService.get('JWT_AUDIENCE'),
    });
  }

  async validate(payload: JwtPayload): Promise<AuthenticatedUser> {
    // Always check token version against database
    const user = await this.usersService.findById(payload.sub);
    if (!user || user.tokenVersion !== payload.tokenVersion) {
      throw new UnauthorizedException('Token invalidated');
    }
    return { id: payload.sub, email: payload.email, role: payload.role };
  }
}

---

ٹوکن کی گردش کو ریفریش کریں۔

کبھی بھی طویل المدت رسائی کا ٹوکن جاری نہ کریں۔ اس کے بجائے، رسائی ٹوکنز کو قلیل المدت رکھیں اور ہر استعمال پر ریفریش ٹوکنز کو گھمائیں۔

// auth.service.ts
@Injectable()
export class AuthService {
  async refreshTokens(refreshToken: string, ipAddress: string) {
    // 1. Look up the refresh token in the database
    const storedToken = await this.db.query.refreshTokens.findFirst({
      where: and(
        eq(refreshTokens.token, this.hashToken(refreshToken)),
        eq(refreshTokens.revoked, false),
        gt(refreshTokens.expiresAt, new Date())
      ),
      with: { user: true },
    });

    if (!storedToken) {
      // Possible reuse attack — revoke all tokens for this user
      if (storedToken?.userId) {
        await this.revokeAllUserTokens(storedToken.userId);
        await this.alertService.send({
          message: `Refresh token reuse detected for user ${storedToken.userId}`,
          severity: 'high',
        });
      }
      throw new UnauthorizedException('Invalid refresh token');
    }

    // 2. Revoke the used refresh token (rotation)
    await this.db
      .update(refreshTokens)
      .set({ revoked: true, revokedAt: new Date(), revokedByIp: ipAddress })
      .where(eq(refreshTokens.id, storedToken.id));

    // 3. Issue new token pair
    const newAccessToken = this.issueAccessToken(storedToken.user);
    const newRefreshToken = await this.issueRefreshToken(
      storedToken.user.id,
      ipAddress,
      storedToken.family // Track token families for reuse detection
    );

    return { accessToken: newAccessToken, refreshToken: newRefreshToken };
  }

  private hashToken(token: string): string {
    return crypto.createHash('sha256').update(token).digest('hex');
  }
}

ریفریش ٹوکنز کے لیے ڈیٹا بیس اسکیما:

CREATE TABLE refresh_tokens (
  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id     UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  token       VARCHAR(64) NOT NULL UNIQUE, -- SHA256 hash of the actual token
  family      UUID NOT NULL,               -- Token family for reuse detection
  expires_at  TIMESTAMPTZ NOT NULL,
  revoked     BOOLEAN DEFAULT false,
  revoked_at  TIMESTAMPTZ,
  revoked_by_ip INET,
  created_at  TIMESTAMPTZ DEFAULT now(),
  created_by_ip INET
);

CREATE INDEX idx_refresh_tokens_user_id ON refresh_tokens(user_id);
CREATE INDEX idx_refresh_tokens_token   ON refresh_tokens(token);

---

ٹوکن منسوخی کی حکمت عملی

JWTs ڈیزائن کے لحاظ سے بے وطن ہیں - ایک بار جاری ہونے کے بعد، آپ اضافی انفراسٹرکچر کے بغیر "انہیں واپس نہیں لے سکتے"۔ یہاں تجارت کے لحاظ سے درجہ بندی کے تین نقطہ نظر ہیں:

1. مختصر TTL (15 منٹ)

سب سے آسان منسوخی کی حکمت عملی: رسائی ٹوکن اتنی تیزی سے ختم ہو جاتے ہیں کہ انہیں منسوخ کرنا شاذ و نادر ہی ضروری ہوتا ہے۔ ڈیٹا بیس میں فوری ریفریش ٹوکن منسوخی کے ساتھ جوڑا بنائیں۔

2. ٹوکن ورژن کاؤنٹر

صارفین کی میز میں ایک tokenVersion ذخیرہ کریں۔ تمام موجودہ ٹوکنز کو باطل کرنے کے لیے اس میں اضافہ کریں:

// Increment version to logout all sessions
await this.db
  .update(users)
  .set({ tokenVersion: sql`token_version + 1` })
  .where(eq(users.id, userId));

// In JWT payload
const payload = {
  sub: user.id,
  tokenVersion: user.tokenVersion, // embedded at sign time
};

// In JwtStrategy.validate()
if (user.tokenVersion !== payload.tokenVersion) {
  throw new UnauthorizedException();
}

فی درخواست کے لیے ایک ڈیٹا بیس تلاش کی ضرورت ہوتی ہے — زیادہ تر ایپلی کیشنز کے لیے قابل قبول۔

3. Redis Denylist

ڈیٹا بیس کی تلاش کے بغیر فوری منسوخی کے لیے:

// Revoke specific token by JTI
async revokeToken(jti: string, expiresIn: number): Promise<void> {
  const key = `token:revoked:${jti}`;
  await this.redis.set(key, '1', 'EX', expiresIn);
}

// Check in JWT strategy before accepting
async validate(payload: JwtPayload): Promise<AuthenticatedUser> {
  const revoked = await this.redis.get(`token:revoked:${payload.jti}`);
  if (revoked) {
    throw new UnauthorizedException('Token revoked');
  }
  return this.buildUser(payload);
}

تجارتی بند: فی درخواست ایک Redis تلاش، لیکن Redis O(1) اور ذیلی ملی سیکنڈ ہے۔ ہائی سیکیورٹی اینڈ پوائنٹس کے لیے قابل قبول۔

---

عام کمزوریاں اور تخفیف

الگورتھم کنفیوژن اٹیک

alg: "none" حملہ: ایک حملہ آور دستخط چھین لیتا ہے اور alg کو none پر سیٹ کرتا ہے، پھر چھیڑ چھاڑ والا پے لوڈ جمع کراتا ہے۔ وہ لائبریریاں جو بغیر دستخط شدہ ٹوکن قبول کرتی ہیں کسی بھی پے لوڈ کو قبول کریں گی۔

// WRONG — never do this
jwt.verify(token, secret); // Accepts alg:none if library allows it

// CORRECT — always specify algorithms explicitly
jwt.verify(token, publicKey, {
  algorithms: ['RS256'], // Whitelist only what you use
});

JWT ہیڈر انجیکشن (jwk/jku)

حملہ آور jku (JWKS URL) یا jwk (ان لائن کلید) ہیڈر کے ساتھ اپنے کلیدی سرور کی طرف اشارہ کرتے ہوئے JWT تیار کرتے ہیں، پھر اپنی ذاتی کلید سے دستخط کرتے ہیں۔ ایک کمزور تصدیق کنندہ حملہ آور کی چابیاں لاتا ہے اور ٹوکن قبول کرتا ہے۔

// WRONG — never fetch keys from the token header
const jwksUri = decodedHeader.jku; // Attacker-controlled!

// CORRECT — always use a pinned, config-driven JWKS URI
const jwksClient = createRemoteJWKSet(new URL(configService.get('JWKS_URI')));

HS256 کے لیے کمزور راز

HS256 کے لیے 32 حروف کے ASCII راز میں تقریباً 190 بٹس اینٹروپی ہیں — ناکافی۔ خفیہ طور پر محفوظ رینڈم سورس سے کم از کم 256 بٹس استعمال کریں:

# Generate a strong HS256 secret
node -e "console.log(require('crypto').randomBytes(64).toString('base64url'))"

---

NestJS JWT ماڈیول کنفیگریشن

// auth.module.ts
import { JwtModule } from '@nestjs/jwt';

@Module({
  imports: [
    JwtModule.registerAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      useFactory: (config: ConfigService) => ({
        privateKey: config.get('JWT_PRIVATE_KEY'),
        publicKey: config.get('JWT_PUBLIC_KEY'),
        signOptions: {
          algorithm: 'RS256',
          expiresIn: '15m',
          issuer: config.get('JWT_ISSUER'),
          audience: config.get('JWT_AUDIENCE'),
        },
        verifyOptions: {
          algorithms: ['RS256'],
          issuer: config.get('JWT_ISSUER'),
          audience: config.get('JWT_AUDIENCE'),
        },
      }),
    }),
  ],
})
export class AuthModule {}

---

عوامی کلید کی تقسیم کے لیے JWKS اینڈ پوائنٹ

// jwks.controller.ts
@Controller('.well-known')
export class JwksController {
  @Get('jwks.json')
  @Public()
  async getJwks() {
    const publicKeyPem = this.configService.get('JWT_PUBLIC_KEY');
    // Convert PEM to JWK format using the 'jose' library
    const publicKey = await importSPKI(publicKeyPem, 'RS256');
    const jwk = await exportJWK(publicKey);

    return {
      keys: [
        {
          ...jwk,
          use: 'sig',
          alg: 'RS256',
          kid: this.configService.get('JWT_KEY_ID'), // e.g., 'key-2026-01'
        },
      ],
    };
  }
}

اس اختتامی نقطہ کو جارحانہ طریقے سے کیش کریں — عوامی کلیدیں شاذ و نادر ہی تبدیل ہوتی ہیں۔ Cache-Control: public, max-age=3600 سیٹ کریں۔

---

سیکیورٹی چیک لسٹ

پروڈکشن میں JWT توثیق کو تعینات کرنے سے پہلے، تصدیق کریں:

• الگورتھم کو واضح طور پر RS256 یا HS256 پر نشانی اور کالوں کی تصدیق دونوں میں سیٹ کیا گیا ہے
• exp، iss، aud ہر درخواست پر توثیق شدہ
• ٹوکن TTL ≤ 15 منٹ تک رسائی حاصل کریں۔
• HttpOnly، Secure، SameSite=Lax کوکیز میں ذخیرہ کردہ ٹوکنز
• ریفریش ٹوکن روٹیشن نافذ - پرانا ٹوکن ہر استعمال پر منسوخ کر دیا گیا۔
• ڈیٹا بیس میں SHA256 ہیش کے بطور ذخیرہ شدہ ٹوکن ریفریش کریں (سادہ متن نہیں)
• jti دعوی کو ہدف شدہ منسوخی کی اہلیت کے لئے شامل کیا گیا۔
• Redis denylist کو ہائی سیکیورٹی اینڈ پوائنٹس کے لیے چیک کیا گیا۔
• JWKS اختتامی نقطہ تقسیم شدہ خدمات کے لیے شائع ہوا۔
• رازوں کے مینیجر میں محفوظ کردہ نجی چابیاں (AWS سیکرٹس مینیجر، والٹ)
• کلیدی گردش کا طریقہ کار دستاویزی اور جانچا گیا۔
• تمام ٹوکن کے اجراء اور باطل ہونے کے واقعات لاگ ان ہو گئے ہیں۔

---

اکثر پوچھے گئے سوالات

کیا دستخط کی تصدیق کیے بغیر JWT کو ڈی کوڈ کرنا محفوظ ہے؟

تصدیق کے بغیر ڈی کوڈنگ پے لوڈ کو پڑھنے کے لیے محفوظ ہے لیکن اجازت کے لیے مواد پر کبھی بھروسہ نہ کریں۔ دعووں پر عمل کرنے سے پہلے ہمیشہ دستخط کی تصدیق کریں۔ زیادہ تر لائبریریوں میں jwt.decode() فنکشن تصدیق کو چھوڑ دیتا ہے — تصدیق کے لیے صحیح کلید کو منتخب کرنے سے پہلے اسے صرف تشخیص کے لیے یا ہیڈر سے kid پڑھنے کے لیے استعمال کریں۔

کیا مجھے براؤزر ایپس کے لیے کوکیز یا اتھارٹی ہیڈر استعمال کرنا چاہیے؟

براؤزر ایپلیکیشنز کے لیے صرف Http کوکیز، مقامی موبائل ایپس کے لیے اجازت کے ہیڈر اور سرور سے سرور API کالز۔ کوکیز XSS exfiltration سے محفوظ ہیں (JavaScript HttpOnly کوکیز نہیں پڑھ سکتا)۔ موبائل ایپس کوکیز کو مؤثر طریقے سے استعمال نہیں کر سکتیں اور آلہ کے محفوظ کی اسٹور میں محفوظ کردہ بیئرر ٹوکن استعمال نہیں کر سکتیں۔

میں فرنٹ اینڈ پر ٹوکن ایکسپائری کو کیسے ہینڈل کروں؟

401 جوابات کو روکیں اور اصل درخواست پر دوبارہ کوشش کرنے سے پہلے خاموش ریفریش کی کوشش کریں۔ React میں، Axios یا بازیافت انٹرسیپٹر استعمال کریں۔ اگر ریفریش بھی ناکام ہوجاتا ہے (میعاد ختم یا منسوخ)، لاگ ان پر ری ڈائریکٹ کریں۔ متوازی ریفریش طوفانوں کو روکنے کے لیے فلائٹ میں ریفریش کا ایک وعدہ رکھیں۔

ایکسیس ٹوکنز اور ریفریش ٹوکنز میں کیا فرق ہے؟

رسائی ٹوکن قلیل المدت (15 منٹ)، بے وطن، اور ہر API درخواست پر عوامی کلید یا مشترکہ راز سے تصدیق شدہ ہوتے ہیں۔ ریفریش ٹوکنز طویل المدت (7-30 دن)، مبہم (بے ترتیب تار، JWTs نہیں)، اور ڈیٹا بیس میں سرور سائیڈ اسٹور کیے جاتے ہیں۔ ریفریش ٹوکن اینڈ پوائنٹ وہ واحد جگہ ہے جہاں ریفریش ٹوکن استعمال کیے جاتے ہیں — انہیں ایک تنگ کوکی پاتھ کے ساتھ اسکوپ کریں۔

کیا میں JWT پے لوڈ میں صارف کے کردار محفوظ کر سکتا ہوں؟

ہاں، لیکن آگاہ رہیں کہ ٹوکن میں انکوڈ کیے گئے رولز ٹوکن کی میعاد ختم ہونے تک کیش کیے جاتے ہیں۔ اگر آپ کسی صارف کے ایڈمن رول کو منسوخ کرتے ہیں، تو وہ اسے اس وقت تک برقرار رکھتے ہیں جب تک کہ ان کے موجودہ رسائی ٹوکن کی میعاد ختم نہ ہو جائے (15 منٹ تک)۔ اعلیٰ حفاظتی کردار کی تبدیلیوں کے لیے، صارف کو Redis نامنظور میں بھی شامل کریں یا فوری دوبارہ تصدیق پر مجبور کرنے کے لیے ان کے ٹوکن ورژن میں اضافہ کریں۔

میں JWTs کے ساتھ "مجھے یاد رکھیں" کو کیسے نافذ کروں؟

ایک طویل المدت ریفریش ٹوکن (90 دن) جاری کریں جب صارف "مجھے یاد رکھیں" بمقابلہ معیاری 30 دن چیک کرتا ہے۔ ریفریش ٹوکن ڈیٹابیس کی قطار میں ایک persistent جھنڈا اسٹور کریں تاکہ آپ صارف کی سیکیورٹی سیٹنگز میں مستقل سیشنز کو الگ سے ڈسپلے اور منسوخ کر سکیں۔ رسائی ٹوکن TTL کو کبھی نہ بڑھائیں - جو مقصد کو ناکام بناتا ہے۔

---

اگلے اقدامات

JWT کی توثیق درست طریقے سے کی گئی ہر محفوظ ویب ایپلیکیشن کی بنیاد ہے۔ RS256 سے HttpOnly کوکی اسٹوریج، ریفریش ٹوکن روٹیشن، اور منسوخی کی حکمت عملی کے ذریعے دستخط کرنے سے، اس گائیڈ میں موجود پیٹرن آپ کے صارفین کو تصدیق کے سب سے عام حملوں سے بچاتے ہیں۔

ECOSIRE ہمارے تمام بیک اینڈ پراجیکٹس میں جنگ کے ٹیسٹ شدہ تصدیقی فن تعمیر کو لاگو کرتا ہے — بشمول Authentik کے ساتھ OIDC کا انضمام، HttpOnly کوکی فلو، اور Redis کی حمایت یافتہ ٹوکن مینجمنٹ —۔ یہ جاننے کے لیے کہ ہم آپ کی توثیق کی پرت کو کس طرح سخت کر سکتے ہیں، ہماری سیکیورٹی پر مرکوز ترقیاتی خدمات کو دریافت کریں۔