प्रमाणीकरण एवं प्राधिकरण¶

पॉलीगार्ड विभिन्न प्रमाणीकरण तंत्रों का उपयोग करता है जो इस बात पर निर्भर करता है कि कॉल करने वाला मोबाइल डिवाइस है, वेब एप्लिकेशन है या सर्वर-साइड एपीआई क्लाइंट है। यह पेज तीनों को कवर करता है।

मोबाइल एसडीके: हार्डवेयर सत्यापन¶

मोबाइल एसडीके और पॉलीगार्ड एपीआई के बीच सभी संचार हार्डवेयर सत्यापन पर निर्भर करता है - क्रिप्टोग्राफ़िक प्रमाण कि अनुरोध एप्लिकेशन की वैध प्रतिलिपि चलाने वाले वास्तविक, असम्बद्ध डिवाइस से उत्पन्न होता है।

आईओएसएंड्रॉइड

डिवाइस की अखंडता स्थापित करने के लिए iOS मोबाइल SDK Apple AppAttest और DeviceCheck का उपयोग करता है।

AppAttest ऐप इंस्टॉलेशन के दौरान एक अद्वितीय, हार्डवेयर-बाउंड कुंजी जोड़ी उत्पन्न करता है। प्रत्येक एपीआई अनुरोध में इस कुंजी द्वारा हस्ताक्षरित एक सत्यापन ऑब्जेक्ट शामिल होता है, जिसे ऐप्पल के सर्वर सत्यापित कर सकते हैं।
डिवाइसचेक प्रति-डिवाइस स्थिति बिट्स प्रदान करता है जिसका उपयोग पॉलीगार्ड पुनर्स्थापना धोखाधड़ी और डिवाइस-स्तरीय विसंगतियों का पता लगाने के लिए करता है।

ये सत्यापन तंत्र iOS में निर्मित हैं और अंतिम उपयोगकर्ता द्वारा किसी अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता नहीं है। मोबाइल एसडीके सभी सत्यापन प्रवाह को स्वचालित रूप से संभालता है।

एंड्रॉइड मोबाइल एसडीके डिवाइस और ऐप की अखंडता को सत्यापित करने के लिए Google Play इंटीग्रिटी एपीआई का उपयोग करता है।

प्ले इंटीग्रिटी एक हस्ताक्षरित अखंडता निर्णय लौटाता है जिसमें डिवाइस की अखंडता (वास्तविक डिवाइस, रूट नहीं किया गया), ऐप की अखंडता (किसी मान्यता प्राप्त वितरण चैनल से वैध एपीके), और खाता लाइसेंसिंग शामिल है।
निर्णय एपीआई अनुरोधों और पॉलीगार्ड सिस्टम द्वारा मान्य सर्वर-साइड से जुड़ा हुआ है।

आईओएस की तरह, सत्यापन प्रवाह अंतिम उपयोगकर्ता के लिए पारदर्शी है।

एमुलेटर और रूटेड डिवाइस

एमुलेटर, रूट किए गए/जेलब्रेक किए गए डिवाइस और साइडलोड किए गए बिल्ड पर हार्डवेयर सत्यापन विफल हो जाएगा जो सही वितरण प्रमाणपत्र के साथ हस्ताक्षरित नहीं हैं। यह डिज़ाइन के अनुसार है - विश्वास जांच के लिए विश्वास की वास्तविक हार्डवेयर जड़ की आवश्यकता होती है।

REST API: सत्र टोकन¶

लिंक प्रबंधन, लॉग एक्सेस और उपयोगकर्ता प्रबंधन के लिए सर्वर-साइड और वेब-आधारित एपीआई कॉल के लिए Authorization हेडर में एक सक्रिय सत्र टोकन की आवश्यकता होती है।

Authorization: Bearer <session_token>

एक सत्र टोकन प्राप्त करना¶

सत्र टोकन प्राप्त करने की दो विधियाँ हैं:

विधि 1: जेडब्ल्यूटी एक्सचेंज¶

यदि आपके पास उपयोगकर्ता खाते वाले पॉलीयूजर के लिए मौजूदा पॉलीगार्ड जेडब्ल्यूटी है, तो आप इसे सत्र टोकन के लिए एक्सचेंज कर सकते हैं।

POST /api/v1/auth/token
{
  "grant_type": "jwt_exchange",
  "jwt": "<polyguard_jwt>"
}

प्रतिक्रिया में एक सत्र टोकन और उसकी समाप्ति समय शामिल है:

{
  "session_token": "pg_sess_...",
  "expires_at": "2026-02-24T12:00:00Z"
}

विधि 2: एसएसओ टोकन एक्सचेंज¶

यदि आपका संगठन एक एकीकृत एसएसओ प्रदाता का उपयोग करता है, तो आप पॉलीगार्ड सत्र टोकन के लिए उस प्रदाता से एक्सेस टोकन का आदान-प्रदान कर सकते हैं।

POST /api/v1/auth/token
{
  "grant_type": "sso_exchange",
  "provider": "microsoft_entra",
  "access_token": "<sso_access_token>"
}

प्रतिक्रिया प्रारूप JWT एक्सचेंज के समान है।

एपीआई समापन बिंदु दस्तावेज़ीकरण

उपरोक्त कोड उदाहरण प्रमाणीकरण प्रवाह का सामान्य आकार दिखाते हैं। सटीक अनुरोध/प्रतिक्रिया स्कीमा, त्रुटि कोड और दर सीमा के लिए, REST API दस्तावेज़ देखें।

एसएसओ एकीकरण¶

पॉलीगार्ड प्लेटफ़ॉर्म ऑपरेटरों और व्यावसायिक उपयोगकर्ताओं के लिए फ़ेडरेटेड सिंगल साइन-ऑन का समर्थन करता है जो अपने उपयोगकर्ताओं को अपने मौजूदा पहचान प्रदाता के माध्यम से प्रमाणित करना चाहते हैं।

समर्थित प्रदाता¶

प्रदाता	एकीकरण प्रकार	उपलब्धता
माइक्रोसॉफ्ट एंट्रा आईडी	मूल एकीकरण	आम तौर पर उपलब्ध
संघीय ओआईडीसी	कोई भी ओआईडीसी-अनुपालक पहचान प्रदाता	सेवा अनुबंध के माध्यम से उपलब्ध है

यह काम किस प्रकार करता है¶

उपयोगकर्ता अपने संगठन के एसएसओ प्रदाता (उदाहरण के लिए, माइक्रोसॉफ्ट एंट्रा आईडी) से प्रमाणित करता है।
आपके एप्लिकेशन को SSO प्रदाता से एक एक्सेस टोकन प्राप्त होता है।
आपका एप्लिकेशन /auth/token एंडपॉइंट के माध्यम से पॉलीगार्ड सत्र टोकन के लिए उस एक्सेस टोकन का आदान-प्रदान करता है।
बाद की पॉलीगार्ड एपीआई कॉल पॉलीगार्ड सत्र टोकन का उपयोग करती हैं।

इसका मतलब यह है कि आपके उपयोगकर्ताओं को कभी भी अलग पॉलीगार्ड क्रेडेंशियल की आवश्यकता नहीं होती है - वे अपनी मौजूदा संगठनात्मक पहचान के साथ प्रमाणित करते हैं, और पॉलीगार्ड उस पहचान को उचित उपयोगकर्ता खाते और अनुमतियों में मैप करता है।

भूमिका मानचित्रण¶

जब एसएसओ कॉन्फ़िगर किया जाता है, तो पॉलीगार्ड एसएसओ समूहों या दावों को पॉलीगार्ड ऑब्जेक्ट मॉडल के भीतर उपयोगकर्ता खाता भूमिकाओं में मैप कर सकता है। यह आपको यह नियंत्रित करने की अनुमति देता है कि आपके संगठन में कौन से उपयोगकर्ता लिंक बना सकते हैं, ऑडिट लॉग तक पहुंच सकते हैं, या ऐप कॉन्फ़िगरेशन प्रबंधित कर सकते हैं, यह सब उनकी मौजूदा एसएसओ समूह सदस्यता के आधार पर।

वेब एसडीके प्रमाणीकरण¶

वेब एसडीके को ट्रस्ट चेक मोडल प्रदर्शित करने के लिए अलग प्रमाणीकरण की आवश्यकता नहीं है। SDK को लिंक URL (तैयारी चरण के दौरान REST API के माध्यम से प्राप्त) के साथ प्रारंभ किया गया है, और ट्रस्ट चेक सत्र को लिंक के स्वयं के टोकन के माध्यम से प्रमाणित किया गया है।

const polyguard = new Polyguard({ appId: "your-app-id" });

// The link URL contains embedded session authentication
polyguard.startTrustCheck({ linkUrl: "https://api-global.polyguard.ai/link/..." });

बैकएंड एपीआई कॉल जो लिंक बनाते हैं और परिणाम पुनर्प्राप्त करते हैं, उन्हें अभी भी एक सत्र टोकन की आवश्यकता होती है, जैसा कि ऊपर वर्णित है।

सारांश¶

प्रसंग	प्रामाणिक तंत्र	इसका उपयोग कौन करता है
एपीआई के लिए मोबाइल एसडीके	हार्डवेयर सत्यापन (ऐपअटेस्ट/प्ले इंटीग्रिटी)	अंतिम उपयोगकर्ता (स्वचालित, पारदर्शी)
REST API कॉल	जेडब्ल्यूटी या एसएसओ एक्सचेंज के माध्यम से सत्र टोकन	प्लेटफ़ॉर्म ऑपरेटर, व्यावसायिक उपयोगकर्ता, सर्वर-साइड एकीकरण
वेब एसडीके (ट्रस्ट चेक डिस्प्ले)	एंबेडेड लिंक टोकन	वेब एप्लिकेशन ट्रस्ट चेक मोडल प्रदर्शित करते हैं
एसएसओ फेडरेशन	माइक्रोसॉफ्ट एंट्रा आईडी या ओआईडीसी	मौजूदा पहचान प्रदाताओं वाले संगठन