निर्धारित कार्य या मानव लॉगिन: API को कौन-सी पहचान देखनी चाहिए?

एक निर्धारित कार्य और लॉगिन संकेत पर खड़ा व्यक्ति एक ही API को अलग-अलग क्रेडेंशियल, अलग-अलग जीवनकाल और अलग-अलग स्वामियों के साथ कॉल करते हैं। कार्य को नेटवर्क पथ, अनुप्रयोग पहचान और अनुमतियों का समूह चाहिए; व्यक्ति को लॉगिन, दूसरा कारक और सत्र चाहिए। दोनों को मिलाने से ऐसा स्वचालन बनता है जो व्यक्ति का पासवर्ड बदलते ही टूट जाता है, या ऐसी बहु-कारक नीति जो cron कार्य को जीवित रखने के लिए ठीक उतनी ही कमज़ोर की गई हो।

तीन द्वार जो एक जैसे दिखते हैं

स्रोत-पता नियम पूछता है कि अनुरोध कहाँ से आया। प्रमाणीकरण पूछता है कि कौन बुला रहा है और कौन-से प्रमाण प्रस्तुत किए गए। प्राधिकरण पूछता है कि क्या यह प्रिंसिपल यह क्रिया कर सकता है। VPN इन तीनों में से केवल पहले को बदलता है, और इसे कार्य के लिए ही नहीं बल्कि होस्ट पर चल रही हर प्रक्रिया के लिए बदलता है, इसलिए घटना रिकॉर्ड में तीनों अवलोकनों को अलग रखें।

इसी कारण एग्रेस नोड बदलने से स्रोत-पते के कारण मिला अस्वीकरण ठीक हो सकता है और अमान्य टोकन अछूता रह सकता है। इसी कारण एक वैध API टोकन उस कार्य से निजी एंडपॉइंट तक पहुँच नहीं बनाता जिसका वहाँ कोई मार्ग नहीं है।

इंटरैक्टिव पथ स्वचालन के लिए खराब टेम्पलेट है

किसी व्यक्ति के लॉगिन को स्क्रिप्ट करना लुभावना है क्योंकि यह एक बार काम करता है। स्क्रिप्ट एक पासवर्ड, शायद एक-बार-पासवर्ड का बीज संग्रहीत करती है, और फिर ऐसी चुनौती पर निर्भर रहती है जो मनुष्य की अपेक्षा के लिए बनाई गई है। OAuth के लिए वर्तमान सर्वोत्तम सुरक्षा अभ्यास, RFC 9700, resource-owner-password-credentials अनुदान को प्रतिबंधित करता है और समझाता है कि यह दो-कारक और बहु-चरणीय प्रमाणीकरण के साथ बुरी तरह क्यों बैठता है।

समर्थित विकल्प सामान्यतः गोपनीय-क्लाइंट प्रवाह होता है जिसमें प्राधिकरण सर्वर अनुप्रयोग को प्रमाणित करता है और टोकन जारी करता है। RFC 6749 के अनुच्छेद 4.4 में client-credentials अनुदान एक उदाहरण है। इसका होना यह नहीं दर्शाता कि हर API इसे स्वीकार करता है, या उपयोगकर्ता द्वारा प्रत्यायोजित कार्य को इससे बदला जा सकता है, क्योंकि वे प्रश्न सेवा स्वामी के लिए हैं। कोड लिखने से पहले पूछें कि सेवा कौन-सा बिना-निगरानी मॉडल समर्थित करती है।

VPN अभी भी कहाँ उपयुक्त है

एक VPN वह नेटवर्क पथ दे सकता है जो एक निजी API मांगता है, और यह वैध भूमिका है। यह कार्य को अनुप्रयोग के सामने प्रमाणित नहीं करता, और यह तय नहीं करता कि कार्य क्या कर सकता है। साझा एग्रेस पता भी कार्य नहीं बल्कि होस्ट की पहचान करता है, इसलिए उस पते के लिए अनुमत-सूची में एक प्रविष्टि उस पर चलने वाली हर प्रक्रिया को प्रवेश देती है।

यदि कार्य साझा रनर पर चलता है, तो यह अंतर कम नहीं बल्कि अधिक मायने रखता है। उसी होस्ट पर दूसरा वर्कफ़्लो मार्ग और पता विरासत में लेता है, और API दोनों में अंतर नहीं कर सकता। यह साझा पासवर्ड जैसी ही कमज़ोरी है, जिसे एक परत नीचे सरका दिया गया है। प्रतिबंध वहाँ रखें जहाँ अनुप्रयोग इसे लागू कर सके, और यदि अनुमत-सूची को और सीमित नहीं कर सकते तो रनर को अलग करें।

दोनों डिज़ाइनों की ईमानदारी से तुलना करें

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

यदि दोनों उत्तर हाँ हैं, तो डिज़ाइन को उधार लिए पासवर्ड के बजाय प्रत्यायोजन मॉडल चाहिए। उस निर्णय को वहाँ लिखें जहाँ अगला अनुरक्षक उसे पाए।

हस्तांतरण से पहले क्या सत्यापित करें

वास्तविक वर्कर से एक अनुमत क्रिया और एक अनिवार्य अस्वीकृति चलाएँ, और दोनों परिणाम रखें। फिर समाप्त हो चुका क्रेडेंशियल और नेटवर्क पथ अनुपलब्ध होने पर व्यवहार जाँचें, क्योंकि ये दो विफलताएँ हैं जो रात में किसी को जगाती हैं।

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

प्रिंसिपल, दायरा, रोटेशन का स्वामी और निष्पादन वातावरण उस परिणाम के आगे दर्ज करें। वही रिकॉर्ड अगले रोटेशन को घटना नहीं बल्कि दिनचर्या बनाता है। यह वह हिस्सा भी है जो लेखा-परीक्षक मांगता है।