Okta integration सेटअप

अवलोकन

Okta सामान्यीकृत (normalized) यूज़र लाइफ़साइकल, ऑथेंटिकेशन, MFA और प्रशासनिक गतिविधि का डेटा उपलब्ध करा सकता है। समीक्षा किए गए उदाहरणों में शामिल हैं:

account.locked — अकाउंट लॉक हो गया
mfa.factor.activated — अतिरिक्त MFA फ़ैक्टर सक्रिय करता है
auth.login.failed — लॉग इन करने में विफल रहता है

दोनों कनेक्शन विधियाँ एक ही दो स्ट्रीम पढ़ती हैं — यूज़र डायरेक्टरी (/api/v1/users) और सिस्टम लॉग (/api/v1/logs)। integration डेटा Signals में कैसे बदलता है देखें।

कनेक्शन विधि चुनें

	Okta (SSWS)	Okta (OAuth 2.0)
क्रेडेंशियल	एक API टोकन, जिसे आप Admin Console में बनाते हैं	एक क्लाइंट ID और एक प्राइवेट JWK, जिसे आप जनरेट और रजिस्टर करते हैं
सेटअप	तीन चरण, कोई कुंजी सामग्री जनरेट करने की आवश्यकता नहीं	नौ चरण, जिनमें एक RSA की पेयर शामिल है
आवश्यक एडमिन रोल	Read-only administrator, जो टोकन के स्वामी को असाइन किया जाता है	Read-only administrator, जो एप्लिकेशन को असाइन किया जाता है
टोकन की अवधि	बिना उपयोग के 30 दिनों के बाद निष्क्रिय हो जाता है	कोई समाप्ति नहीं; की पेयर को रोटेट करना आपकी ज़िम्मेदारी है
कब उपयोग करें	अधिकांश संगठनों के लिए यही अनुशंसित मार्ग है	आपकी सुरक्षा नीति लंबे समय तक मान्य API टोकन की अनुमति नहीं देती

दोनों विधियों के लिए समान एक्सेस आवश्यक है, इसलिए यह चयन क्रेडेंशियल प्रबंधन से संबंधित है, इससे यह तय नहीं होता कि प्लेटफ़ॉर्म क्या पढ़ सकता है।

विकल्प A — API टोकन (SSWS)

अनुशंसित।

Living Security को क्या चाहिए

क्रेडेंशियल	विवरण
API key	एक Okta API टोकन। कनेक्ट डायलॉग इस फ़ील्ड को API key लेबल करता है
Tenant subdomain	`<tenant>.okta.com` में `<tenant>` — केवल सबडोमेन, पूरा URL नहीं

पूर्वापेक्षाएँ

सर्विस अकाउंट यूज़र बनाने, एडमिनिस्ट्रेटर रोल असाइन करने और API टोकन बनाने के लिए आपका Okta Super Administrator होना आवश्यक है।

टोकन के स्वामित्व के लिए एक यूज़र बनाएँ

Okta API टोकन में उस यूज़र की अनुमतियाँ होती हैं जिसने उसे बनाया है, और यदि वह यूज़र निष्क्रिय कर दिया जाए तो टोकन काम करना बंद कर देता है। व्यक्तिगत एडमिन अकाउंट का उपयोग करने के बजाय एक समर्पित सर्विस अकाउंट बनाएँ, ताकि स्टाफ़ में बदलाव होने पर भी कनेक्शन बना रहे।

Admin Console में Directory → People पर जाएँ।
Add person पर क्लिक करें और svc-livingsecurity@yourcompany.com जैसा कोई यूज़र बनाएँ।
अकाउंट को सक्रिय करें।

Read-only administrator रोल असाइन करें

प्लेटफ़ॉर्म केवल डेटा पढ़ता है। रीड एक्सेस से अधिक अनुमति देने पर टोकन को ऐसी अनुमतियाँ मिलती हैं जिनका वह कभी उपयोग नहीं करता।

Security → Administrators पर जाएँ।
Add administrator पर क्लिक करें और पिछले चरण में बनाया गया यूज़र चुनें।
Read-only Administrator रोल असाइन करें।
सहेजें।

एडमिनिस्ट्रेटर रोल के बिना, Okta Management API को किए गए कॉल 200 OK के साथ सफल होते हैं और एक खाली सूची लौटाते हैं। रोल अनुपस्थित होने की जानकारी देने के लिए कोई 403 नहीं होता — स्ट्रीम बस खाली रहती हैं।

API टोकन बनाएँ

चरण 1 में बनाए गए सर्विस अकाउंट यूज़र के रूप में Admin Console में साइन इन करें। टोकन उसी अकाउंट की अनुमतियाँ प्राप्त करता है जो उसे बनाता है।
Security → API पर जाएँ और Tokens टैब खोलें।
Create token पर क्लिक करें, Living Security Platform जैसा कोई नाम दें, और Create token पर क्लिक करें।
टोकन का मान अभी कॉपी करें — Okta इसे केवल एक बार दिखाता है, दोबारा नहीं।

Okta किसी API टोकन को बिना उपयोग के 30 दिनों के बाद निष्क्रिय कर देता है। इस integration में सिंक दिन में कम से कम एक बार चलते हैं, इसलिए सक्रिय कनेक्शन अपने टोकन को सक्रिय बनाए रखता है। जो कनेक्शन एक महीने तक रुका रहे, उसके लिए नया टोकन आवश्यक होगा।

ऊपर दी गई पते की सूची केवल तभी मायने रखती है जब आपका Okta org network zone द्वारा API एक्सेस को प्रतिबंधित करता हो। अधिकांश org ऐसा नहीं करते।

अपना tenant subdomain खोजें

आपका Admin Console URL https://acme-admin.okta.com जैसा दिखता है। Tenant subdomain acme है — -admin प्रत्यय के बिना, .okta.com के बिना, और https:// के बिना।

अब आप Okta (SSWS) से कनेक्ट हो गए हैं।

समस्या निवारण

401 Unauthorized

टोकन अमान्य है, रद्द कर दिया गया है, या 30 दिनों की निष्क्रियता के बाद निष्क्रिय हो गया है। सर्विस अकाउंट यूज़र के रूप में नया टोकन बनाएँ और उसे कनेक्शन में दोबारा दर्ज करें।

कनेक्ट हो गया, लेकिन हर स्ट्रीम खाली है

टोकन के स्वामी के पास कोई एडमिनिस्ट्रेटर रोल नहीं है। सर्विस अकाउंट को Read-only Administrator असाइन करें (चरण 2) — रोल न होने पर API त्रुटि के बजाय खाली सूची के साथ 200 OK लौटाता है।

स्टाफ़ में बदलाव के बाद सिंक विफल हो जाते हैं

जिस यूज़र ने टोकन बनाया है, उसके निष्क्रिय होने पर टोकन काम करना बंद कर देता है। इसी कारण टोकन किसी व्यक्ति के बजाय सर्विस अकाउंट का होना चाहिए।

विकल्प B — OAuth 2.0 सर्विस एप्लिकेशन

इस विधि का उपयोग तब करें जब आपकी सुरक्षा नीति लंबे समय तक मान्य API टोकन की अनुमति नहीं देती। यह टोकन के स्थान पर एक क्लाइंट ID और आपके स्वामित्व वाली RSA की पेयर का उपयोग करती है। प्लेटफ़ॉर्म में यह Settings → Integrations → Catalog के अंतर्गत Okta (OAuth 2.0) टाइल है। Client Credentials का उपयोग करके Okta के साथ ऑथेंटिकेट करने के लिए आपको निम्नलिखित की आवश्यकता होगी:

Client ID - आपके Okta API Services एप्लिकेशन के लिए एक अद्वितीय पहचानकर्ता।
Private Key (JWK) - JSON Web Key फ़ॉर्मैट में RSA प्राइवेट की, जिसकी पब्लिक की आपके Okta एप्लिकेशन में रजिस्टर की गई है।
Okta Domain - केवल आपका Okta tenant subdomain (उदा. dev-12345678), पूरा होस्टनेम नहीं।
Scopes - Okta Management API scopes की स्पेस से अलग की गई सूची (उदा. okta.users.read okta.logs.read)।

यह गाइड आपको private_key_jwt ऑथेंटिकेशन के साथ Okta में एक API Services एप्लिकेशन बनाने की प्रक्रिया बताएगी।

पूर्वापेक्षाएँ:

आपके पास एक Okta अकाउंट होना चाहिए। developer.okta.com पर निःशुल्क डेवलपर अकाउंट के लिए साइन अप करें।

चरण 1: अपना Okta API Services एप्लिकेशन बनाना

अपने Okta Admin Console में लॉग इन करें।
बाएँ साइडबार में Applications > Applications पर जाएँ।
Create App Integration पर क्लिक करें।
साइन-इन विधि के रूप में API Services चुनें और Next पर क्लिक करें।

अपने एप्लिकेशन को एक नाम दें और Save पर क्लिक करें।
एप्लिकेशन के General टैब पर अपना Client ID खोजें — अंतिम चरण में आपको इसकी आवश्यकता होगी।
Client authentication को Public key / Private key पर सेट करें। okta.* scopes केवल इसी ऑथेंटिकेशन विधि के साथ समर्थित हैं।

Proof of possession (DPoP) को अक्षम करें — यह समर्थित नहीं है।

एप्लिकेशन को API Services के रूप में ही बनाया जाना चाहिए।

चरण 2: अपनी RSA की पेयर जनरेट और रजिस्टर करना

Okta key generator का उपयोग करें

Okta सीधे Admin Console में आपके लिए RSA की पेयर जनरेट कर सकता है:

Admin Console में अपना API Services एप्लिकेशन खोलें।
General टैब पर जाएँ और PUBLIC KEYS सेक्शन तक स्क्रॉल करें।
Add Key पर क्लिक करें, फिर Generate new key चुनें।
Save पर क्लिक करें — Okta की पेयर जनरेट करता है और Private Key (JWK) केवल एक बार दिखाता है।
प्राइवेट की JSON को तुरंत कॉपी करके सहेज लें — यह दोबारा नहीं दिखाई जाएगी।

पब्लिक की आपके एप्लिकेशन में स्वतः रजिस्टर हो जाती है।

डायलॉग बंद करने से पहले प्राइवेट JWK कॉपी कर लें। अंतिम चरण में इसे Living Security Platform के Private Key फ़ील्ड में पेस्ट करें।

अपनी स्वयं की की बनाएँ

Okta, API Services ऐप्स के लिए private_key_jwt का उपयोग करता है। आप एक RSA की पेयर जनरेट करते हैं, पब्लिक JWK को Okta में रजिस्टर करते हैं, और प्राइवेट JWK Living Security Platform को प्रदान करते हैं। निम्नलिखित Node.js स्क्रिप्ट (Node.js 18+ आवश्यक) का उपयोग करके प्राइवेट JWK जनरेट करें:

const { generateKeyPairSync } = require('crypto');
const { privateKey, publicKey } = generateKeyPairSync('rsa', { modulusLength: 2048 });

const privateJwk = privateKey.export({ format: 'jwk' });
const publicJwk  = publicKey.export({ format: 'jwk' });

// Assign a kid — must match between private and public JWK
const kid = require('crypto').randomUUID();
privateJwk.kid = kid;
publicJwk.kid  = kid;

console.log('=== PUBLIC JWK (upload to Okta) ===');
console.log(JSON.stringify(publicJwk, null, 2));
console.log('\n=== PRIVATE JWK (paste into the Living Security Platform) ===');
console.log(JSON.stringify(privateJwk));

पब्लिक JWK को Okta में रजिस्टर करें:

Admin Console में अपना API Services एप्लिकेशन खोलें।
General टैब पर जाएँ और PUBLIC KEYS सेक्शन तक स्क्रॉल करें।
Add Key पर क्लिक करें, ऊपर दी गई स्क्रिप्ट से प्राप्त public JWK JSON आउटपुट पेस्ट करें, और Save पर क्लिक करें।

प्राइवेट JWK वह है जिसे आप Living Security Platform में पेस्ट करते हैं। इसमें सभी की सामग्री (d, p, q, dp, dq, qi) और kid शामिल हैं। इसे गोपनीय रखें।

चरण 3: अपना Okta Domain खोजना

केवल अपना Okta tenant subdomain दर्ज करें — .okta.com से पहले का भाग।

Admin Console में, आपके ब्राउज़र के एड्रेस बार में https://dev-12345678-admin.okta.com जैसा URL दिखेगा।
आपका Okta Domain केवल सबडोमेन है (उदा., dev-12345678), dev-12345678.okta.com नहीं।
वैकल्पिक रूप से, अपना Okta डोमेन खोजने के लिए Admin Console में Settings > Account पर जाएँ, फिर सबडोमेन वाला भाग उपयोग करें।

चरण 4: अपने एप्लिकेशन को API scopes प्रदान करें

Okta को हर टोकन अनुरोध में कम से कम एक scope आवश्यक है। आपका एप्लिकेशन विशिष्ट scopes का अनुरोध कर सके, इससे पहले उन्हें प्रदान किया जाना चाहिए:

Admin Console में Applications > Applications पर जाएँ और अपना एप्लिकेशन खोलें।
Okta API Scopes टैब पर क्लिक करें।
वे scopes प्रदान करें जिनकी आपके integration को आवश्यकता है: okta.users.read और okta.logs.read।

उपलब्ध scopes की पूरी सूची Okta Management API reference में है।

चरण 5: अपने एप्लिकेशन को एडमिन रोल असाइन करें

केवल scopes प्रदान करना पर्याप्त नहीं है — यदि आपके एप्लिकेशन के पास कोई एडमिन रोल नहीं है, तो Okta Management API endpoints (उदा. /api/v1/users) चुपचाप खाली 200 [] प्रतिक्रिया लौटाते हैं। आपको कम से कम Read-Only Administrator असाइन करना होगा:

Admin Console में Security > Administrators पर जाएँ (या Applications > Applications > आपका ऐप > Admin roles पर जाएँ)।
Add administrator assignment पर क्लिक करें और अपना API Services एप्लिकेशन चुनें।

Read-Only Administrator रोल असाइन करें (या आपको आवश्यक scopes के आधार पर उससे उच्च रोल)।
Save पर क्लिक करें।

एडमिन रोल के बिना, API कॉल 200 OK के साथ सफल होते हैं लेकिन खाली परिणाम लौटाते हैं, और समस्या का संकेत देने के लिए कोई 403 त्रुटि नहीं होती।

चरण 6: Living Security Platform में क्रेडेंशियल दर्ज करें

जब आपके पास अपना Client ID, Private Key (JWK), Okta Domain और Scopes हों:

वह फ़ॉर्म खोलें जहाँ आपको Okta (Client Credentials) के साथ ऑथेंटिकेट करना है।
अपना Client ID दर्ज करें।
अपनी Private Key (JWK) पेस्ट करें — ऊपर दी गई स्क्रिप्ट से प्राप्त पूरा JSON ऑब्जेक्ट (सिंगल-लाइन या फ़ॉर्मैटेड)।
अपना Okta Domain केवल tenant subdomain के रूप में दर्ज करें (उदा., dev-12345678)।
Scopes को स्पेस से अलग की गई सूची के रूप में दर्ज करें (उदा., okta.users.read okta.logs.read)।
फ़ॉर्म सबमिट करें, और आप सफलतापूर्वक ऑथेंटिकेट हो जाएँगे।

अब आप Okta (Client Credentials) से कनेक्ट हो गए हैं।

इस दस्तावेज़ के कुछ अंश Nango से अनुकूलित किए गए हैं, और Elastic License 2.0 के अंतर्गत उपयोग किए गए हैं।

Integrations

Integration सेटअप

कैटलॉग

आउटबाउंड चैनल

अवलोकन

कनेक्शन विधि चुनें