दस्तावेज़ीकरण

शुरुआत करना

Authagonal हर टेनेंट को एक पूरी तरह से standards-compliant OIDC सर्वर देता है। हर टेनेंट को अपना खुद का जारीकर्ता URL, डिस्कवरी दस्तावेज़, और टोकन एंडपॉइंट्स मिलते हैं — टेनेंट के बीच कोई साझा इन्फ्रास्ट्रक्चर नहीं। आप 5 मिनट से भी कम समय में शून्य से एक कार्यशील लॉगिन फ़्लो तक पहुँच सकते हैं।

एक खाता बनाएँ

authagonal.io पर साइन अप करें और अपने खाते के लिए एक slug चुनें। यह slug आपका जारीकर्ता डोमेन बन जाता है: {slug}.authagonal.io। अपना खाता बनाने के बाद, शुरुआत करने के लिए अपना ईमेल पता सत्यापित करें।

साइनअप के दौरान अपने खाते के लिए एक अद्वितीय slug चुनें

एक क्लाइंट पंजीकृत करें

पोर्टल साइडबार में Clients पर जाएँ और नया क्लाइंट पर क्लिक करें। अपने एप्लिकेशन के लिए एक clientId और clientName दर्ज करें। फिर, क्लाइंट के URI टैब पर, कम से कम एक रीडायरेक्ट URI जोड़ें; प्रमाणीकरण के बाद उपयोगकर्ताओं को यहीं भेजा जाता है। उदाहरण के लिए: https://app.example.com/callback। नए क्लाइंट्स को डिफ़ॉल्ट रूप से client secret की आवश्यकता होती है, इसलिए बिना backend वाले ब्राउज़र ऐप के लिए सामान्य टैब पर सीक्रेट आवश्यक करें बंद करें।

पोर्टल में एक नया OAuth क्लाइंट पंजीकृत करें

आपका पहला लॉगिन

एकीकृत करने का सबसे तेज़ तरीका oidc-client-ts है, जो JavaScript और TypeScript एप्लिकेशन के लिए एक हल्की OIDC क्लाइंट लाइब्रेरी है।

import { UserManager } from 'oidc-client-ts';

const mgr = new UserManager({
  authority: 'https://acme.authagonal.io',
  client_id: 'my-app',
  redirect_uri: 'https://app.example.com/callback',
  response_type: 'code',
  scope: 'openid profile email',
});

// Redirect to login
mgr.signinRedirect();

// On callback page
const user = await mgr.signinRedirectCallback();
console.log(user.profile); // { sub, email, name, ... }

यदि आप किसी लाइब्रेरी के बिना न्यूनतम दृष्टिकोण पसंद करते हैं, तो आप सादे fetch के साथ मानक OAuth 2.0 authorization code flow का उपयोग कर सकते हैं:

// 1. Redirect the user to the authorization endpoint
const authorizeUrl = new URL('https://acme.authagonal.io/connect/authorize');
authorizeUrl.searchParams.set('client_id', 'my-app');
authorizeUrl.searchParams.set('redirect_uri', 'https://app.example.com/callback');
authorizeUrl.searchParams.set('response_type', 'code');
authorizeUrl.searchParams.set('scope', 'openid profile email');
authorizeUrl.searchParams.set('code_challenge', codeChallenge);
authorizeUrl.searchParams.set('code_challenge_method', 'S256');
window.location.href = authorizeUrl.toString();

// 2. On the callback page, exchange the code for tokens
const res = await fetch('https://acme.authagonal.io/connect/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'authorization_code',
    code: new URLSearchParams(window.location.search).get('code')!,
    redirect_uri: 'https://app.example.com/callback',
    client_id: 'my-app',
    code_verifier: codeVerifier,
  }),
});

const tokens = await res.json();
// tokens.id_token, tokens.access_token (refresh_token only when offline_access is requested and allowed)

आपके टेनेंट के लिए डिफ़ॉल्ट लॉगिन पेज

डैशबोर्ड

पोर्टल डैशबोर्ड आपको आपके टेनेंट का रीयल-टाइम अवलोकन देता है। यह सबसे महत्वपूर्ण मेट्रिक्स को सामने लाता है — उपयोगकर्ता वृद्धि, प्रमाणीकरण गतिविधि, और पोर्टल की हर सुविधा तक त्वरित नेविगेशन।

अवलोकन

डैशबोर्ड के शीर्ष पर आपको एक स्वागत संदेश और आपके टेनेंट के hosted लॉगिन का लॉगिन पृष्ठ खोलें लिंक दिखाई देगा। स्टेट कार्ड के नीचे, एक मासिक सक्रिय उपयोगकर्ता मीटर आपकी प्लान सीमा के मुकाबले उपयोग को ट्रैक करता है और 80% पार करने के बाद आपके प्लान विकल्पों से लिंक करता है। एक साइन-इन गतिविधि चार्ट और नवीनतम ऑडिट प्रविष्टियों की एक हाल की गतिविधि फ़ीड पेज को पूरा करते हैं।

स्टेट कार्ड और साइन-इन गतिविधि के साथ डैशबोर्ड होम स्क्रीन

गतिविधि मेट्रिक्स

छह स्टेट कार्ड एक नज़र में आपके टेनेंट का सारांश देते हैं:

• सक्रिय उपयोगकर्ता: आपके टेनेंट में उपयोगकर्ताओं की कुल संख्या
• साइन-इन (24घं): पिछले 24 घंटों में सफल साइन-इन
• MFA नामांकित: MFA नामांकित उपयोगकर्ताओं का प्रतिशत, नामांकित और कुल संख्या के साथ
• असफल प्रयास (24घं): पिछले 24 घंटों में असफल साइन-इन, जैसे गलत क्रेडेंशियल्स, लॉक किए गए खाते, या नीति अस्वीकृतियाँ
• SCIM सिंक: कनेक्टेड IdPs से प्रोविज़निंग गतिविधि, जो निष्क्रिय या ऑपरेशन की संख्या के रूप में दिखाई जाती है
• मासिक खर्च: इस माह अब तक का खर्च, महीने के अंत के अनुमानित आँकड़े के साथ

24-घंटे वाले कार्ड पिछले 24 घंटों की तुलना उससे पहले के 24 घंटों से करते हैं। साइन-इन गतिविधि चार्ट 14, 30, या 90 दिनों की अवधि में प्रति दिन सफल और असफल साइन-इन दर्शाता है। डैशबोर्ड हर मिनट रिफ़्रेश होता है।

पिछले 24 घंटों का सारांश देने वाले स्टेट कार्ड

त्वरित नेविगेशन

मेट्रिक्स के नीचे, नेविगेशन कार्ड सीधे Clients, SSO, Users, SCIM, Branding, Settings, Billing, Domains, और Audit Log से लिंक करते हैं। हर कार्ड एक संक्षिप्त विवरण दिखाता है ताकि नए टीम सदस्य खुद को जल्दी से परिचित कर सकें।

क्लाइंट्स

OAuth क्लाइंट उन एप्लिकेशन का प्रतिनिधित्व करते हैं जो आपके टेनेंट के माध्यम से उपयोगकर्ताओं का प्रमाणीकरण करते हैं। हर क्लाइंट का redirect URIs, स्कोप्स, ग्रांट प्रकार, टोकन जीवनकाल, और MFA policy के लिए अपना खुद का कॉन्फ़िगरेशन होता है।

क्लाइंट सूची

Clients पेज सभी पंजीकृत क्लाइंट्स की एक तालिका दिखाता है। हर पंक्ति clientId, डिस्प्ले नाम, रंगीन बैज के रूप में अनुमत ग्रांट प्रकार, और क्या PKCE सक्षम है, दिखाती है। पूर्ण कॉन्फ़िगरेशन संपादक खोलने के लिए किसी भी पंक्ति पर क्लिक करें।

ग्रांट प्रकार बैज और PKCE संकेतकों के साथ क्लाइंट सूची

एक क्लाइंट बनाना

एक नया एप्लिकेशन पंजीकृत करने के लिए नया क्लाइंट पर क्लिक करें। आपको दो फ़ील्ड प्रदान करने होंगे:

• clientId — क्लाइंट के लिए एक अद्वितीय पहचानकर्ता (उदा. my-spa)
• clientName — एक मानव-पठनीय डिस्प्ले नाम

एक नया OAuth क्लाइंट पंजीकृत करें

एक क्लाइंट हटाना

किसी क्लाइंट को हटाने के लिए, क्लाइंट तालिका में उसकी पंक्ति पर ट्रैश आइकन पर क्लिक करें और पुष्टि करने के लिए client ID टाइप करें। क्लाइंट स्थायी रूप से हटा दिया जाता है और अब उपयोगकर्ताओं को साइन इन नहीं करा सकता या टोकन रिफ़्रेश नहीं कर सकता। पहले से जारी किए गए एक्सेस टोकन रद्द नहीं होते और समाप्त होने तक मान्य रहते हैं।

क्लाइंट कॉन्फ़िगरेशन संदर्भ

हर क्लाइंट के पास पाँच टैब में व्यवस्थित कॉन्फ़िगरेशन विकल्पों का एक व्यापक सेट होता है: सामान्य, URI, स्कोप और ग्रांट, टोकन, और सुरक्षा।

सामान्य सेटिंग्स

URIs

URI फ़ील्ड एक टैग इनपुट का उपयोग करते हैं — एक मान टाइप करें और इसे जोड़ने के लिए Enter या comma दबाएँ। किसी भी टैग को हटाने के लिए उस पर X पर क्लिक करें।

URIs कॉन्फ़िगर करने के लिए टैग इनपुट फ़ील्ड

Scopes और Grant Types

Token Lifetimes

प्रति क्लाइंट टोकन जीवनकाल कॉन्फ़िगर करें

Logout URIs

क्लाइंट बैक-चैनल और फ़्रंट-चैनल दोनों logout URIs पंजीकृत कर सकते हैं। दोनों में से कोई एक या दोनों वैकल्पिक हैं — जो भी इस बात से मेल खाता हो कि आपका एप्लिकेशन अपना सत्र कैसे साफ़ करता है, उसे कॉन्फ़िगर करें।

MFA Policy

हर क्लाइंट की अपनी MFA policy होती है, जो क्लाइंट के <strong>सुरक्षा</strong> टैब पर सेट की जाती है। MFA policy ड्रॉपडाउन तीन विकल्प प्रदान करता है:

प्रति-क्लाइंट MFA policy

Enterprise SSO

Enterprise SSO आपके ग्राहकों को अपना खुद का आइडेंटिटी प्रोवाइडर लाने देता है। Authagonal डोमेन-आधारित रूटिंग के साथ SAML 2.0 और OIDC फ़ेडरेशन दोनों का समर्थन करता है, इसलिए उपयोगकर्ताओं को उनके ईमेल पते के आधार पर स्वचालित रूप से सही IdP पर निर्देशित किया जाता है।

डोमेन-आधारित SSO रूटिंग

SAML 2.0 कनेक्शन

एक SAML कनेक्शन बनाने के लिए, SSO पेज पर जाएँ और SAML टैब चुनें। निम्नलिखित प्रदान करें:

जब आप कनेक्शन सहेजते हैं, तो Authagonal मेटाडेटा document प्राप्त करता है और IdP का साइनिंग प्रमाणपत्र, SSO एंडपॉइंट URL, और name identifier format आयात करता है। प्रमाणपत्र रोटेशन को पकड़ने के लिए मेटाडेटा को समय-समय पर रीफ़्रेश किया जाता है।

एक SAML 2.0 SSO कनेक्शन बनाएँ

OIDC कनेक्शन

एक OIDC फ़ेडरेशन कनेक्शन बनाने के लिए, OIDC टैब चुनें और प्रदान करें:

एक OIDC फ़ेडरेशन कनेक्शन बनाएँ

डोमेन रूटिंग

डोमेन रूटिंग उपयोगकर्ताओं को उनके ईमेल डोमेन के आधार पर स्वचालित रूप से सही आइडेंटिटी प्रोवाइडर पर रीडायरेक्ट करता है। जब कोई उपयोगकर्ता लॉगिन पेज पर अपना ईमेल दर्ज करता है, तो Authagonal जाँचता है कि क्या डोमेन भाग (उदा. acme.com) किसी SSO कनेक्शन के allowedDomains से मेल खाता है। यदि मेल खाता है, तो उपयोगकर्ता को सहजता से उनके संगठन के IdP पर रीडायरेक्ट कर दिया जाता है।

डोमेन रूटिंग ईमेल डोमेन को आइडेंटिटी प्रोवाइडर्स से मैप करता है

JIT प्रोविज़निंग

जब कोई उपयोगकर्ता पहली बार SSO के माध्यम से साइन इन करता है और आपके टेनेंट में पहले से मौजूद नहीं होता है, तो Authagonal स्वचालित रूप से उनका खाता बना सकता है (Just-In-Time प्रोविज़निंग)। JIT प्रोविज़निंग डिफ़ॉल्ट रूप से बंद होती है: कनेक्शन बनाते समय JIT प्रोविज़निंग चालू करें को चेक करके इसे प्रति कनेक्शन चालू करें।

जब JIT प्रोविज़निंग अक्षम होता है, तो केवल वे उपयोगकर्ता जिन्हें पहले से प्रोविज़न किया गया है — SCIM, पोर्टल के Users पेज, या API के माध्यम से — उस कनेक्शन के माध्यम से साइन इन कर सकते हैं। अज्ञात उपयोगकर्ताओं को एक access_denied त्रुटि प्राप्त होती है और उन्हें अपने व्यवस्थापक से संपर्क करने के लिए निर्देशित किया जाता है।

संगठन-स्कोप्ड कनेक्शन

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

उपयोगकर्ता

Users पेज आपको अपने टेनेंट में सभी एंड उपयोगकर्ताओं का प्रबंधन करने देता है। आप उपयोगकर्ताओं को खोज सकते हैं, उनके विवरण देख सकते हैं, नए उपयोगकर्ताओं को आमंत्रित कर सकते हैं, और देख सकते हैं कि प्रत्येक उपयोगकर्ता को कैसे प्रोविज़न किया गया था।

खोज और पेजिनेशन

खोज बार किसी सटीक user ID या ईमेल से, या ईमेल, पहले नाम, या अंतिम नाम के prefix से मेल खाता है, और सभी, सक्रिय, और निष्क्रिय फ़िल्टर सूची को स्थिति के आधार पर सीमित करते हैं। खोज 300ms पर debounced है ताकि API को अभिभूत किए बिना आपके टाइप करते ही परिणाम अपडेट हों। परिणाम प्रति पेज 50 उपयोगकर्ताओं पर पेजिनेटेड होते हैं; पेजों के बीच जाने के लिए तालिका के नीचे नेविगेशन नियंत्रणों का उपयोग करें।

उपयोगकर्ता तालिका

उपयोगकर्ता तालिका प्रत्येक उपयोगकर्ता के लिए निम्नलिखित कॉलम दिखाती है:

खोज बार और पेजिनेशन के साथ उपयोगकर्ता सूची

उपयोगकर्ताओं को आमंत्रित करना

किसी को अपने टेनेंट में आमंत्रित करने के लिए उपयोगकर्ता को आमंत्रित करें पर क्लिक करें। उन्हें अपना पासवर्ड खुद सेट करने के लिए एक ईमेल मिलता है। फ़ॉर्म में ये फ़ील्ड होते हैं:

एक नए उपयोगकर्ता को आमंत्रित करें

पसंदीदा भाषा

हर उपयोगकर्ता की एक पसंदीदा भाषा होती है जो उनकी hosted UI और Authagonal द्वारा उन्हें भेजे जाने वाले transactional emails (सत्यापन, password reset, welcome, और अधिक) दोनों को संचालित करती है। आप इसे उपयोगकर्ता को आमंत्रित करते समय सेट कर सकते हैं और उपयोगकर्ता के विवरण पेज से इसे किसी भी समय बदल सकते हैं। यदि किसी उपयोगकर्ता की कोई पसंदीदा भाषा सेट नहीं है, तो Authagonal English पर वापस आ जाता है। चयनकर्ता सभी समर्थित locales प्रदान करता है: English, Chinese (Simplified), German, French, Spanish, Vietnamese, Portuguese, Japanese, Arabic, Hindi, और Afrikaans।

विवरण पेज पर उपयोगकर्ता की पसंदीदा भाषा सेट करें

उपयोगकर्ता विवरण

इसका विवरण पेज खोलने के लिए उपयोगकर्ता सूची में किसी भी पंक्ति पर क्लिक करें। वहाँ से आप प्रोफ़ाइल डेटा संपादित कर सकते हैं, भूमिकाओं (roles) का प्रबंधन कर सकते हैं, MFA रीसेट कर सकते हैं, कस्टम विशेषताएँ की समीक्षा कर सकते हैं, और उपयोगकर्ता को हटा सकते हैं।

प्रोफ़ाइल

ईमेल, पहला/अंतिम नाम, फ़ोन, कंपनी, भाषा, external ID संपादित करें, और उपयोगकर्ता के active flag को टॉगल करें। ईमेल या email-confirmed flag बदलने के लिए admin या owner की आवश्यकता होती है। ईमेल परिवर्तन टेनेंट भर में अद्वितीय रहने चाहिए; यदि पहले से लिया गया है तो API email_already_in_use लौटाता है।

भूमिकाएँ (Roles)

Roles पेज पर परिभाषित भूमिकाएँ असाइन और अनअसाइन करें। जब क्लाइंट roles scope का अनुरोध करता है, तो असाइन की गई भूमिकाएँ ID और एक्सेस टोकन्स में roles क्लेम के रूप में जारी की जाती हैं।

Multi-Factor Authentication

उपयोगकर्ता के लिए पंजीकृत हर MFA क्रेडेंशियल देखें (authenticator app (TOTP), WebAuthn/passkeys, और recovery codes), प्रत्येक अपने खुद के registered/last-used timestamps के साथ। व्यक्तिगत क्रेडेंशियल हटाएँ, या सभी MFA रीसेट करें; दोनों के लिए admin या owner की आवश्यकता होती है। रीसेट करने से उपयोगकर्ता को अगले लॉगिन पर फिर से नामांकित होना पड़ता है।

Custom Attributes

उपयोगकर्ता से जुड़ा मनमाना key/value डेटा। keys अद्वितीय होनी चाहिए। Attributes user profile API और SCIM के माध्यम से उजागर होते हैं, और एक कस्टम स्कोप के userClaims को कॉन्फ़िगर करके इन्हें एक्सेस-टोकन क्लेम्स से मैप किया जा सकता है।

संगठन

वह संगठन जिससे यह उपयोगकर्ता संबंधित है। यह आपकी अपनी पसंद का एक फ़्री-टेक्स्ट पहचानकर्ता है, जो उनके टोकनों में और profile स्कोप के अंतर्गत /connect/userinfo पर org_id क्लेम के रूप में जारी होता है। Authagonal इसे कभी स्वयं व्युत्पन्न नहीं करता: इसे आपका प्रोविज़निंग ऐप सेट करता है, या वह SCIM क्रेडेंशियल जिसने उपयोगकर्ता को बनाया, या इसे यहाँ हाथ से सेट किया जाता है।

फ़ील्ड के बगल में मौजूद लिंक उन सभी को सूचीबद्ध करता है जिनका यही मान है, और वही फ़िल्टर API पर GET /api/v1/users?organizationId= के रूप में उपलब्ध है। पूरी डायरेक्टरी को पेज-दर-पेज देखे बिना यह जानने के लिए इसका उपयोग करें कि कौन किस ग्राहक का है।

उपयोगकर्ता हटाएँ

उपयोगकर्ता और उनके सभी MFA क्रेडेंशियल को स्थायी रूप से हटा देता है। पुष्टि के लिए उपयोगकर्ता का ईमेल टाइप करें — इसे पूर्ववत नहीं किया जा सकता।

ग्रुप्स

ग्रुप्स आपको उपयोगकर्ताओं को व्यवस्थित करने और टोकन्स में ग्रुप सदस्यता शामिल करने देते हैं। ग्रुप्स को पोर्टल में मैन्युअल रूप से बनाया जा सकता है या किसी बाहरी आइडेंटिटी प्रोवाइडर से SCIM के माध्यम से स्वचालित रूप से प्रोविज़न किया जा सकता है।

ग्रुप सूची

ग्रुप्स SCIM पेज के समूह टैब पर निम्नलिखित जानकारी के साथ सूचीबद्ध होते हैं:

स्रोत संकेतकों के साथ ग्रुप सूची

एक ग्रुप बनाना

नया समूह पर क्लिक करें और ग्रुप के लिए एक प्रदर्शन नाम दर्ज करें। ग्रुप नाम वर्णनात्मक और आपके टेनेंट के भीतर अद्वितीय होने चाहिए (उदा. "Engineering", "Billing Admins", "Beta Testers")।

ग्रुप विवरण और सदस्य

विवरण दृश्य खोलने के लिए किसी भी ग्रुप पर क्लिक करें। यहाँ आप सभी वर्तमान सदस्यों को देख सकते हैं और सदस्यता का प्रबंधन कर सकते हैं:

• Add members: किसी उपयोगकर्ता को ईमेल या नाम से खोजें और उसे ग्रुप में जोड़ें।
• Remove members: किसी भी सदस्य के बगल में remove बटन पर क्लिक करें और पुष्टि करें। ग्रुप के माध्यम से दी गई सभी भूमिकाएँ रद्द कर दी जाती हैं।

विवरण दृश्य में ग्रुप सदस्यता का प्रबंधन करें

Tokens में ग्रुप्स

जब किसी क्लाइंट पर टोकन में समूह सक्षम होता है और groups scope का अनुरोध किया जाता है, तो जारी किए गए टोकन में एक groups क्लेम शामिल होता है जो उपयोगकर्ता के ग्रुप्स के प्रदर्शन नामों को सूचीबद्ध करता है:

{
  "sub": "user-123",
  "email": "[email protected]",
  "groups": ["Engineering", "Beta Testers"]
}

भूमिकाएँ (Roles)

भूमिकाएँ (Roles) आपके एप्लिकेशन में role-based access control (RBAC) का समर्थन करती हैं। Authagonal में भूमिकाएँ परिभाषित करें, उन्हें उपयोगकर्ताओं को असाइन करें, और अपने एप्लिकेशन लॉजिक में प्राधिकरण लागू करने के लिए टोकन्स में roles क्लेम का उपयोग करें।

भूमिकाओं का प्रबंधन

Roles पेज inline editing के साथ सभी परिभाषित भूमिकाओं की एक तालिका दिखाता है। प्रत्येक भूमिका में होता है:

एक भूमिका बनाना

नई भूमिका पर क्लिक करें और एक नाम और विवरण प्रदान करें। भूमिका नाम संक्षिप्त होने चाहिए और आपके एप्लिकेशन भर में एक सुसंगत naming convention का पालन करना चाहिए (उदा. हाइफ़न के साथ lowercase: billing-admin)।

Inline Editing

भूमिकाएँ सीधे तालिका में inline editing का समर्थन करती हैं। edit मोड में प्रवेश करने के लिए किसी भी भूमिका पर pencil आइकन पर क्लिक करें — नाम और विवरण फ़ील्ड संपादन योग्य हो जाते हैं। मानों को संशोधित करें, फिर सहेजने के लिए checkmark आइकन पर क्लिक करें। परिवर्तन तुरंत प्रभावी हो जाते हैं।

एक भूमिका हटाना

किसी भी भूमिका को हटाने के लिए उस पर delete आइकन पर क्लिक करें। भूमिका को स्थायी रूप से हटाए जाने से पहले आपसे पुष्टि करने के लिए कहा जाएगा। किसी भूमिका को हटाने से मौजूदा टोकन्स पूर्वव्यापी रूप से अमान्य नहीं होते — हटाने के बाद जारी किए गए नए टोकन्स में भूमिका अनुपस्थित होगी।

roles तालिका में भूमिकाओं की inline editing

Tokens में भूमिकाएँ

जब क्लाइंट roles scope का अनुरोध करता है, तो किसी उपयोगकर्ता को असाइन की गई भूमिकाएँ ID और एक्सेस टोकन में एक roles क्लेम के रूप में शामिल होती हैं। आपका एप्लिकेशन प्राधिकरण निर्णय लेने के लिए इस क्लेम को पढ़ सकता है:

{
  "sub": "user-123",
  "email": "[email protected]",
  "roles": ["admin", "billing-admin"]
}

SCIM प्रोविज़निंग

SCIM 2.0 (System for Cross-domain Identity Management) Okta, Azure AD, OneLogin और JumpCloud जैसे एंटरप्राइज़ आइडेंटिटी प्रोवाइडर से स्वचालित उपयोगकर्ता और समूह प्रोविज़निंग सक्षम करता है। कॉन्फ़िगर होने पर, उपयोगकर्ता खाते और समूह सदस्यताएँ अपस्ट्रीम IdP से आपके Authagonal टेनेंट में स्वचालित रूप से सिंक हो जाती हैं।

डाउनस्ट्रीम प्रोविज़निंग के साथ SCIM उपयोगकर्ता लाइफसाइकल सिंक

सेटअप चरण

किसी क्लाइंट के लिए SCIM प्रोविज़निंग सक्षम करने हेतु इन चरणों का पालन करें:

1. क्लाइंट एप्लिकेशन चुनें — वह OAuth क्लाइंट चुनें जिसके साथ SCIM प्रोविज़निंग संबद्ध होगी।
2. SCIM टोकन जनरेट करें — एक विवरण और दिनों में समाप्ति अवधि दें, फिर टोकन जनरेट करें।
3. टोकन तुरंत कॉपी करें — रॉ टोकन मान केवल एक बार दिखाया जाता है। डायलॉग बंद करने से पहले इसे कॉपी कर लें।
4. अपना IdP कॉन्फ़िगर करें — अपने आइडेंटिटी प्रोवाइडर की SCIM सेटिंग्स में base URL और bearer टोकन दर्ज करें।
5. उपयोगकर्ता सिंक का परीक्षण करें — अपने IdP से एक परीक्षण सिंक ट्रिगर करें और सत्यापित करें कि उपयोगकर्ता Authagonal पोर्टल में दिखाई देते हैं।

SCIM Base URL

अपने आइडेंटिटी प्रोवाइडर को निम्नलिखित base URL के साथ कॉन्फ़िगर करें:

https://{slug}.authagonal.io/scim/v2

{slug} को अपने टेनेंट slug से बदलें।

टोकन जनरेशन के साथ SCIM सेटअप पेज

टोकन प्रबंधन

SCIM टोकन आपके IdP से प्रोविज़निंग अनुरोधों को प्रमाणित करते हैं। आप प्रति क्लाइंट कई टोकन प्रबंधित कर सकते हैं:

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

सक्रिय और रद्द किए गए टोकन संकेतकों के साथ टोकन प्रबंधन

कनेक्टिविटी का परीक्षण

ServiceProviderConfig एंडपॉइंट को क्वेरी करके सत्यापित करें कि आपका SCIM इंटीग्रेशन काम कर रहा है:

curl -H "Authorization: Bearer YOUR_TOKEN" \
  https://acme.authagonal.io/scim/v2/ServiceProviderConfig

एक सफल प्रतिक्रिया एक JSON दस्तावेज़ लौटाती है जो समर्थित SCIM सुविधाओं का वर्णन करती है: PATCH और फ़िल्टरिंग समर्थित हैं, जबकि बल्क ऑपरेशन, पासवर्ड बदलना, सॉर्टिंग और ETags समर्थित नहीं हैं।

एक क्रेडेंशियल क्या देख सकता है

एक SCIM क्रेडेंशियल केवल उन्हीं उपयोगकर्ताओं और समूहों को देखता है जिन्हें उसने प्रोविज़न किया है। किसी दूसरे कनेक्टर द्वारा बनाए गए उपयोगकर्ता को पढ़ना, अपडेट करना या हटाना 404 लौटाता है, सूचीकरण केवल उसके अपने लौटाता है, और किसी समूह की सदस्यता में केवल वही उपयोगकर्ता नामित किए जा सकते हैं जिन्हें उसी कनेक्टर ने प्रोविज़न किया हो। किसी अन्य तरीके से बनाए गए खाते, चाहे किसी प्रशासक द्वारा, स्वयं-सेवा साइनअप द्वारा या SSO जस्ट-इन-टाइम प्रोविज़निंग द्वारा, SCIM के लिए पूरी तरह अदृश्य होते हैं।

वह सीमा प्रति क्लाइंट है, प्रति टोकन नहीं। एक ही क्लाइंट के विरुद्ध जारी किए गए दो क्रेडेंशियल दो सीक्रेट वाली एक ही पहचान हैं, और हर एक वह बदल सकता है जो दूसरे ने बनाया है। परस्पर अविश्वसनीय कनेक्टरों को एक-एक अलग क्लाइंट दें। externalId का दायरा भी इसी तरह तय होता है, इसलिए दो कनेक्टर बिना टकराव के अलग-अलग लोगों के लिए ext-001 का उपयोग कर सकते हैं।

डीप्रोविज़निंग

DELETE /scim/v2/Users/{id} खाते को निष्क्रिय करता है और उसे हटाया गया चिह्नित करता है। रिकॉर्ड रखा जाता है, जैसा RFC 7644 अनुमति देता है, लेकिन वह हर आगामी ऑपरेशन पर 404 लौटाता है और सूचियों से छोड़ दिया जाता है। उनके MFA नामांकन और समूह सदस्यताएँ मिटा दी जाती हैं, उनकी externalId मैपिंग मुक्त कर दी जाती है, और जारी किए गए सभी टोकन रद्द कर दिए जाते हैं, ताकि पहुँच अगले टोकन की समाप्ति पर नहीं, बल्कि तुरंत समाप्त हो जाए।

यदि वही व्यक्ति बाद में दोबारा नियुक्त किया जाता है और फिर से बनाया जाता है, तो उसे नया user id मिलता है। पहचानकर्ताओं का पुनः उपयोग कभी नहीं किया जाता: यह id आपके द्वारा अब तक जारी किए गए हर टोकन में subject है, इसलिए इसे दोबारा इस्तेमाल करने पर, उस पर भरोसा करने वाले हर एप्लिकेशन में, नए जुड़ने वाले व्यक्ति को चुपचाप पिछले धारक का इतिहास मिल जाएगा।

सिंक किए गए उपयोगकर्ताओं को संगठन से टैग करना

SCIM में किसी कनेक्टर के पास यह बताने का कोई तरीका नहीं है कि वह आपके किस ग्राहक को सिंक कर रहा है। कोर SCIM कोई संगठन एट्रिब्यूट परिभाषित नहीं करता, इसलिए एक सामान्य उपयोगकर्ता निर्माण आपको व्यक्ति का नाम और ईमेल बताता है और यह कुछ नहीं बताता कि वह किसका है। यदि कई ग्राहक आपके टेनेंट में प्रोविज़न करते हैं, तो उनके उपयोगकर्ता ऐसे आते हैं कि उनमें अंतर नहीं किया जा सकता।

इसका उत्तर अनुरोध नहीं, बल्कि क्रेडेंशियल देता है। जब आप SCIM टोकन बनाते हैं, तो संगठन के अंतर्गत अपने टेनेंट के संगठनों में से एक चुनें (आपके टेनेंट में संगठन होने के बाद यह picker दिखाई देता है)। उस टोकन के माध्यम से प्रोविज़न किया गया हर उपयोगकर्ता उस संगठन का सक्रिय सदस्य बन जाता है और उसके बाद उसे अपने टोकनों में org_id क्लेम के रूप में रखता है। एक ही क्लाइंट के विरुद्ध प्रति ग्राहक एक क्रेडेंशियल जारी करें, और उनके सिंक किए गए उपयोगकर्ता हर ग्राहक के लिए अलग क्लाइंट पंजीकरण के बिना सही ढंग से आरोपित होकर आते हैं। इसे खाली छोड़ दें तो उपयोगकर्ता बिना टैग के रहते हैं।

टैग उपयोगकर्ता के बनाए जाने पर लगाया जाता है और बाद के किसी अपडेट पर कभी नहीं, इसलिए एक नियमित इंक्रीमेंटल सिंक किसी मौजूदा खाते को चुपचाप स्थानांतरित नहीं कर सकता। यदि आप एक प्रोविज़निंग ऐप भी चलाते हैं, तो क्रेडेंशियल पर लगा स्पष्ट टैग जीतता है: /try की प्रतिक्रिया केवल उसी संगठन को भरती है जो अब भी खाली है।

समर्थित स्कीमा

हम कोर SCIM 2.0 User और Group स्कीमा (RFC 7643) लागू करते हैं। समर्थित उपयोगकर्ता एट्रिब्यूट हैं userName, name.givenName, name.familyName, displayName, emails, active, externalId और preferredLanguage / locale।

enterprise user एक्सटेंशन लागू नहीं किया गया है, इसलिए department, manager, employeeNumber, costCenter, division और organization को संग्रहीत करने के बजाय स्वीकार करके अनदेखा कर दिया जाता है, चाहे create हो, replace हो या PATCH। Entra और Okta दोनों इनमें से कुछ को डिफ़ॉल्ट रूप से मैप करते हैं, इसलिए आपको इन्हें अपनी एट्रिब्यूट मैपिंग से हटाने की आवश्यकता नहीं है। किसी उपयोगकर्ता को अपने किसी ग्राहक से आरोपित करने के लिए, इसके बजाय SCIM क्रेडेंशियल पर संगठन सेट करें: enterprise organization एट्रिब्यूट आपके ग्राहक के आइडेंटिटी प्रोवाइडर द्वारा दावा किया जाता है, और वह जानबूझकर उनका org_id नहीं बनता।

OAuth स्कोप

स्कोप क्लाइंट्स को उपयोगकर्ता के डेटा या अनुमतियों के विशिष्ट हिस्से का अनुरोध करने देते हैं। Authagonal मानक OIDC स्कोप और आपके APIs के लिए आपके द्वारा परिभाषित कस्टम स्कोप दोनों का समर्थन करता है।

अंतर्निहित स्कोप

कस्टम स्कोप

Scopes पेज पर अपने स्वयं के स्कोप परिभाषित करें। प्रत्येक स्कोप एक अनुमति या संसाधन का वर्णन करता है जिसका एक क्लाइंट अनुरोध कर सकता है (उदाहरण के लिए, billing.read, orders.write)।

टोकन्स पर कस्टम क्लेम्स

कस्टम क्लेम्स के दो हिस्से होते हैं। source प्रति-उपयोगकर्ता डेटा है: प्रत्येक AuthUser में एक customAttributes dictionary होती है जिसे आप पोर्टल से (Users → user → Custom Attributes), SCIM के माध्यम से, या एक TCC प्रोविज़निंग hook के माध्यम से पॉपुलेट कर सकते हैं। release प्रति-स्कोप है: प्रत्येक स्कोप की userClaims सूची उन keys को नाम देती है जिन्हें वह server छोड़ने की अनुमति देता है।

जब एक क्लाइंट स्कोप का अनुरोध करता है, तो Authagonal ग्रांट किए गए स्कोप के माध्यम से चलता है, उनकी userClaims सूचियों का union करता है, और उपयोगकर्ता के customAttributes से केवल उन्हीं keys को emit करता है। अज्ञात keys चुपचाप गिरा दी जाती हैं — एक क्लाइंट नाम का अनुमान लगाकर किसी विशेषता को नहीं पढ़ सकता। मानक OIDC क्लेम्स (sub, email, name, आदि) spec का पालन करते हैं और whitelist के अधीन नहीं हैं।

# 1. On the user (Portal → Users → {user} → Custom Attributes)
department = "engineering"
employee_id = "E-1042"
seat_tier = "enterprise"

# 2. On a custom scope (Portal → Scopes → projects.read)
name        = "projects.read"
userClaims  = ["department", "seat_tier"]   # <-- whitelist

# 3. Client requests scope=openid projects.read
# Decoded access token (relevant fields only):
{
  "sub": "u-9b…",
  "scope": "openid projects.read",
  "department": "engineering",
  "seat_tier":  "enterprise"
  // employee_id is NOT emitted; it's not in the whitelist for any granted scope.
}

क्लाइंट्स को स्कोप असाइन करना

Clients → Scopes & Grants टैब पर अनुमत स्कोप जोड़ें। एक क्लाइंट केवल उन्हीं स्कोप का अनुरोध कर सकता है जो उसे ग्रांट किए गए हैं; अज्ञात स्कोप invalid_scope के साथ अस्वीकार कर दिए जाते हैं।

ब्रांडिंग

अपने टेनेंट के लॉगिन पेजों का रूप-रंग कस्टमाइज़ करें। ब्रांडिंग सेटिंग्स आपको प्रमाणीकरण अनुभव को अपने उत्पाद की दृश्य पहचान से मिलाने देती हैं — लोगो और रंगों से लेकर उन्नत CSS ओवरराइड तक।

रूप-रंग

लाइव रंग पूर्वावलोकन के साथ रूप-रंग सेटिंग्स

संपर्क जानकारी

लॉगिन पेज टॉगल

नियंत्रित करें कि आपके टेनेंट के लॉगिन पेज पर कौन से तत्व दिखाई दें:

कस्टम ब्रांडिंग लागू किए गए उदाहरण लॉगिन पेज

कस्टम CSS

लॉगिन पेज के रूप-रंग पर पूर्ण नियंत्रण के लिए, अपनी ब्रांडिंग सेटिंग्स में एक CSS फ़ाइल URL दें। फ़ाइल डिफ़ॉल्ट स्टाइल के बाद लोड होती है, इसलिए आपके नियमों को प्राथमिकता मिलती है। URL लॉगिन पेज वाले ही origin पर होना चाहिए; अन्य origins से stylesheets लोड नहीं की जातीं।

डार्क मोड

लॉगिन ऐप लाइट, डार्क और सिस्टम थीम के साथ आता है। Branding पेज पर डार्क मोड सेटिंग डिफ़ॉल्ट चुनती है: off, auto (सिस्टम वरीयता का पालन करता है, यही डिफ़ॉल्ट है) या force। उपयोगकर्ता फिर भी लॉगिन पेज पर एक टॉगल से चुन सकते हैं; यह विकल्प सेशनों के बीच बना रहता है। system पर सेट होने पर, SPA prefers-color-scheme को लाइव ट्रैक करता है।

लाइट मान :root पर घोषित होते हैं; डार्क ओवरराइड .dark तक सीमित होते हैं। customCssUrl के माध्यम से सेट की गई टेनेंट ब्रांडिंग हमेशा जीतती है — इसलिए आपके रंग उपयोगकर्ता की थीम की परवाह किए बिना बने रहते हैं।

सेटिंग्स

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

पासवर्ड नीति

उपयोगकर्ता → सेटिंग्स के अंतर्गत, अपने टेनेंट के सभी उपयोगकर्ताओं के लिए पासवर्ड जटिलता आवश्यकताएँ परिभाषित करें:

पासवर्ड नीति कॉन्फ़िगरेशन

MFA नीति

टेनेंट-व्यापी MFA नीति, जो उपयोगकर्ता → सेटिंग्स के अंतर्गत सेट की जाती है, डिफ़ॉल्ट मल्टी-फैक्टर प्रमाणीकरण व्यवहार सेट करती है। अलग-अलग क्लाइंट इस सेटिंग को ओवरराइड कर सकते हैं।

सेशन और लॉकआउट

सेशन अवधि और खाता लॉकआउट व्यवहार को नियंत्रित करें:

सेशन और लॉकआउट कॉन्फ़िगरेशन

वेबहुक

वेबहुक आपको प्रमाणीकरण इवेंट पर रियल टाइम में प्रतिक्रिया देने देते हैं। दो इवेंट (onUserAuthenticated, onTokenIssued) प्रवर्तनीय हैं — डिफ़ॉल्ट रूप से वे एसिंक्रोनस रूप से फ़ायर होते हैं और उपयोगकर्ता को ब्लॉक नहीं करते, लेकिन आप प्रति इवेंट प्रवर्तन का विकल्प चुन सकते हैं ताकि एक non-2xx प्रतिक्रिया या {"allow": false} बॉडी कार्रवाई को अस्वीकार कर दे। शेष इवेंट सूचनाएँ हैं — हमेशा fire-and-forget, कभी ब्लॉक नहीं करतीं।

अतिरिक्त वेबहुक सेटिंग्स:

वेबहुक इवेंट कॉन्फ़िगरेशन

वेबहुक का सत्यापन

एक बार कोई वेबहुक URL कॉन्फ़िगर हो जाने पर, Authagonal एक प्रति-टेनेंट साइनिंग सीक्रेट मिंट करता है (एक whsec_… मान जो Settings → Webhooks के अंतर्गत केवल-पढ़ने के लिए दिखाया जाता है)। प्रत्येक आउटबाउंड डिलीवरी एक X-Authagonal-Signature: t=<unix>,v1=<hex> हेडर ले जाती है, जहाँ v1 रॉ रिक्वेस्ट बॉडी पर परिकलित HMAC-SHA256(secret, "{t}.{body}") है। इसे अपने एंडपॉइंट पर पुनः परिकलित करें और constant-time तुलना करें ताकि पुष्टि हो सके कि अनुरोध वास्तव में Authagonal से आया था और इसके साथ छेड़छाड़ नहीं हुई थी — और उन डिलीवरी को अस्वीकार करें जिनका t रीप्ले रोकने के लिए बहुत पुराना है।

import crypto from 'node:crypto';

// rawBody MUST be the exact bytes Authagonal sent: verify before any JSON re-serialization.
function verifyAuthagonalWebhook(signatureHeader, rawBody, signingSecret) {
  const parts = Object.fromEntries(signatureHeader.split(',').map((p) => p.split('=')));
  const { t, v1 } = parts;

  // Replay protection: reject deliveries older than 5 minutes.
  if (Math.abs(Date.now() / 1000 - Number(t)) > 300) return false;

  const expected = crypto
    .createHmac('sha256', signingSecret)
    .update(`${t}.${rawBody}`)
    .digest('hex');

  return v1.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(v1), Buffer.from(expected));
}

मेंटेनेंस विंडो

आपके टेनेंट के डेटा को स्टोरेज shards के बीच स्थानांतरित करने जैसे विघटनकारी ऑपरेशन के लिए एक पसंदीदा मेंटेनेंस विंडो सेट करें। एक UTC घंटा (0–23) चुनें; पोर्टल सुविधा के लिए आपके स्थानीय टाइमज़ोन में समतुल्य समय भी प्रदर्शित करता है।

साइनअप और एक्सेस

आपके टेनेंट में कौन उपयोगकर्ता बन सकता है, और वे किन शर्तों पर साइन इन कर सकते हैं।

निष्क्रिय उपयोगकर्ता रिटेंशन

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

ऑडिट एक्सपोर्ट और रिमोट बैकअप

अपना डेटा अनुरोध पर नहीं, बल्कि एक निर्धारित समय-सारणी पर बाहर निकालने के दो तरीके। ऑडिट एक्सपोर्ट ऑडिट इवेंट्स के हर पूरे हो चुके दिन को आपके बताए गए URL पर भेजता है, हस्ताक्षरित, ताकि आप पुष्टि कर सकें कि यह हमसे आया है, और इसे किसी SIEM या अनुपालन आर्काइव में डाला जा सके। रिमोट बैकअप आपके दैनिक और साप्ताहिक बैकअप की प्रतियाँ आपके नियंत्रण वाले किसी गंतव्य पर भेजते हैं, बिना किसी प्रमाणीकरण के, basic authentication के साथ, या bearer टोकन के साथ। ऑडिट एक्सपोर्ट ऑडिट लॉग पेज के निर्यात टैब पर और रिमोट बैकअप बैकअप पेज पर कॉन्फ़िगर होते हैं; दोनों आपके पास रहते हैं, हमारे रखे बैकअप से स्वतंत्र।

सैंडबॉक्स एनवायरनमेंट

एनवायरनमेंट पेज सैंडबॉक्स एनवायरनमेंट का प्रबंधन करता है: नामित, पृथक एनवायरनमेंट जिनके अपने उपयोगकर्ता, क्लाइंट, signing keys, MFA नामांकन और grants होते हैं, और हर एक अलग URL पर उपलब्ध होता है। Branding, प्लान और बिलिंग live के साथ साझा होते हैं। लाइव उपयोगकर्ताओं को प्रभावित किए बिना कॉन्फ़िगरेशन परिवर्तन, SSO इंटीग्रेशन और वेबहुक एंडपॉइंट का परीक्षण करने के लिए इनका उपयोग करें। आप डिफ़ॉल्ट रूप से अधिकतम 5 बना सकते हैं, और सक्रिय सैंडबॉक्स उपयोगकर्ता आपके MAU में गिने जाते हैं।

हर एनवायरनमेंट {name}-{slug}.authagonal.io पर उपलब्ध है।

सैंडबॉक्स एनवायरनमेंट नियंत्रण

बिलिंग

पोर्टल के बिलिंग पेज के माध्यम से अपनी सब्सक्रिप्शन और बिलिंग प्रबंधित करें। यह पेज आपको आपके वर्तमान प्लान का अवलोकन देता है और भुगतान विधियों, इनवॉइस और प्लान परिवर्तनों को प्रबंधित करने के लिए Stripe बिलिंग पोर्टल तक पहुँच प्रदान करता है।

सब्सक्रिप्शन जानकारी

बिलिंग पेज आपकी वर्तमान सब्सक्रिप्शन का विवरण एक नज़र में प्रदर्शित करता है। आपको आपकी सब्सक्रिप्शन स्थिति दर्शाने वाला एक स्टेटस बैज दिखाई देगा — active, trialing, past_due, canceled, या unpaid — आपके प्लान नाम, वर्तमान बिलिंग अवधि (आरंभ और समाप्ति तिथियाँ), और क्या आपकी सब्सक्रिप्शन वर्तमान अवधि के अंत में रद्द होने के लिए सेट है, के साथ।

सब्सक्रिप्शन प्रबंधित करें

नई विंडो में Stripe बिलिंग पोर्टल खोलने के लिए Manage Subscription बटन पर क्लिक करें। वहाँ से आप अपनी भुगतान विधियाँ अपडेट कर सकते हैं, इनवॉइस देख और डाउनलोड कर सकते हैं, अपना प्लान बदल सकते हैं, या अपनी सब्सक्रिप्शन रद्द कर सकते हैं।

यदि अभी तक कोई सब्सक्रिप्शन मौजूद नहीं है, तो इसके बजाय एक Setup Billing कॉल-टू-एक्शन दिखाया जाता है, जो आपको प्लान चुनने और भुगतान विवरण दर्ज करने में मार्गदर्शन करता है।

बिलिंग पेज आपकी वर्तमान सब्सक्रिप्शन का विवरण प्रदर्शित करता है और Stripe तक पहुँच प्रदान करता है

कस्टम डोमेन

डिफ़ॉल्ट {slug}.authagonal.io के बजाय अपने स्वयं के डोमेन (उदा. auth.yourdomain.com) से अपने प्रमाणीकरण पेज सर्व करें। कस्टम डोमेन आपके उपयोगकर्ताओं को एक सहज, ब्रांडेड प्रमाणीकरण अनुभव देते हैं।

डोमेन जोड़ना

ऐड डोमेन फ़ॉर्म में वह होस्टनेम दर्ज करें जिसका आप उपयोग करना चाहते हैं (उदा. auth.yourdomain.com)। जोड़े जाने के बाद, डोमेन आपकी डोमेन सूची में pending_verification स्थिति के साथ दिखाई देगा।

DNS सत्यापन

पोर्टल द्वारा डोमेन के लिए दिखाए गए दो CNAME रिकॉर्ड बनाएँ, दोनों {slug}.authagonal.io की ओर इंगित करते हुए: एक स्वयं hostname पर, जो ट्रैफ़िक सर्व करता है और proxied हो सकता है, और एक _authagonal-challenge. के बाद hostname पर, जो स्वामित्व सिद्ध करता है और DNS-only (proxied नहीं) होना चाहिए। रिकॉर्ड लागू हो जाने के बाद, सत्यापित करने के लिए DNS जाँचें पर क्लिक करें। लंबित डोमेन की स्वचालित रूप से भी दोबारा जाँच की जाती है।

auth.yourdomain.com.                        CNAME  acme.authagonal.io.
_authagonal-challenge.auth.yourdomain.com.  CNAME  acme.authagonal.io.

TLS प्रमाणपत्र

एक बार आपका डोमेन सत्यापित हो जाने पर, आपको एक TLS प्रमाणपत्र की आवश्यकता होती है ताकि उपयोगकर्ता HTTPS पर सुरक्षित रूप से कनेक्ट कर सकें। Authagonal दो विकल्पों का समर्थन करता है:

स्वचालित (cert-manager) — Authagonal cert-manager का उपयोग करके TLS प्रमाणपत्र स्वचालित रूप से प्रोविज़न और नवीनीकृत करता है। यह अधिकांश उपयोगकर्ताओं के लिए अनुशंसित विकल्प है। किसी अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता नहीं है।

अपना खुद का लाएँ (BYO) — PEM फ़ॉर्मेट में अपना स्वयं का प्रमाणपत्र और निजी कुंजी अपलोड करें। यह विकल्प तब उपयोगी है जब आपके संगठन को किसी विशिष्ट सर्टिफ़िकेट अथॉरिटी से प्रमाणपत्र की आवश्यकता हो। प्रमाणपत्र समाप्ति को ट्रैक किया जाता है ताकि आप इसके समाप्त होने से पहले नवीनीकरण कर सकें।

डोमेन स्थिति

प्रत्येक डोमेन अपनी वर्तमान स्थिति दर्शाने वाला एक स्टेटस बैज प्रदर्शित करता है: pending_verification (DNS अभी तक पुष्ट नहीं), verified (DNS पुष्ट, TLS लंबित), या active (पूर्णतः चालू)।

डोमेन सूची प्रत्येक कस्टम डोमेन और उसकी वर्तमान स्थिति प्रदर्शित करती है

PEM फ़ॉर्मेट में अपना स्वयं का TLS प्रमाणपत्र और निजी कुंजी अपलोड करें

संगठन

संगठन टेनेंट के भीतर एक ग्राहक होता है। आइसोलेशन की सीमा टेनेंट ही रहता है: एक टेबल प्रीफ़िक्स और एक साइनिंग की, और टेनेंट का हर होस्ट अपना खुद का issuer। संगठन इसके भीतर आइडेंटिटी को बाँटता है, इसलिए हर ग्राहक के लिए अलग टेनेंट बनाए बिना एक टेनेंट कई ग्राहक संगठनों को सेवा दे सकता है।

संगठन कस्टम डोमेन के साथ काम करते हैं (एक डोमेन किसी एक संगठन से पिन किया जा सकता है) और प्रोविज़निंग ऐप्स के साथ भी (एक प्रोविज़निंग ऐप किसी नए उपयोगकर्ता को किसी संगठन से टैग कर सकता है)। "एक टेनेंट, कई ब्रांडेड ग्राहक" वाले जिस एंड-टू-एंड पैटर्न के लिए यह फ़ीचर बना है, उसके लिए मल्टी-कस्टमर ऐप्स गाइड देखें।

मॉडल और ids

हर संगठन का एक स्थिर, अपरिवर्तनीय id होता है (रूप org_<32 hex>) जो org_id टोकन क्लेम के रूप में जारी होता है, और एक अपरिवर्तनीय, टेनेंट-में-अद्वितीय slug जो org_slug के रूप में जारी होता है और organization authorize पैरामीटर में स्वीकार किया जाता है। Ids और slugs एक ही लुकअप नेमस्पेस साझा करते हैं। किसी दूसरे संगठन के id के बराबर slug को ठीक वैसे ही टकराव मानकर अस्वीकार किया जाता है जैसे सामान्य डुप्लिकेट slug को।

सदस्यताएँ

सदस्यता उपयोगकर्ता और संगठन के बीच का many-to-many जोड़ है: हर (संगठन, उपयोगकर्ता) जोड़ी के लिए एक पंक्ति। एक उपयोगकर्ता की कई हो सकती हैं। किसी संगठन के रूप में साइन इन करने को अधिकृत करने वाली चीज़ सदस्यता पंक्ति है, पुराना प्रति-उपयोगकर्ता संगठन टैग नहीं।

सदस्यता की roles टेनेंट के मौजूदा role कैटलॉग से ली जाती हैं और roles क्लेम में जोड़ी जाती हैं। लेकिन केवल तब जब अनुरोध ने संगठन को स्पष्ट रूप से चुना हो (Token org selection देखें) और केवल active सदस्यता पंक्ति से। एक संगठन में रखा गया role कभी किसी दूसरे संगठन के लिए जारी टोकन तक नहीं पहुँचता।

संगठन में आमंत्रित करना

POST /api/v1/users/invite वैकल्पिक organizationId और organizationRoles स्वीकार करता है। एक कॉल invited सदस्यता के साथ अकाउंट बनाती है और संगठन की ब्रांडिंग वाला आमंत्रण ईमेल भेजती है। यदि संगठन का पिन किया हुआ कस्टम डोमेन है, तो लिंक उसी पर खुलता है। व्यक्ति के स्वीकार करने पर सदस्यता active हो जाती है। किसी संगठन को नाम देने के लिए owner या admin होना ज़रूरी है।

संगठन में SCIM प्रोविज़निंग

SCIM टोकन को किसी संगठन से जोड़ा जा सकता है (POST /api/v1/scim/tokens पर organizationId, या टोकन बनाते समय संगठन picker)। Id टेनेंट के किसी संगठन का नाम होना चाहिए। उस टोकन से बना हर उपयोगकर्ता active सदस्य बनता है और संगठन को org_id के रूप में साथ रखता है। यह बाइंडिंग केवल निर्माण के समय लागू होती है, और यह सदस्यता तय करती है, एक्सेस नहीं: एक क्लाइंट पर दो टोकन अब भी एक-दूसरे के उपयोगकर्ता देखते हैं। किसी भी रास्ते से उपयोगकर्ता को हटाने पर उसकी सदस्यताएँ हट जाती हैं।

पॉलिसी फ़्लैग

enabled (डिफ़ॉल्ट चालू): अक्षम संगठन अपने लिए कोई टोकन जारी नहीं करता। यह authorize पर और हर refresh पर जाँचा जाता है, इसलिए किसी को अक्षम करने से केवल नए लॉगिन ही नहीं रुकते, चालू सेशन भी अपने अगले rotation पर रुक जाते हैं।

requireMembershipForTokens (डिफ़ॉल्ट चालू): क्या इस संगठन के लिए टोकन जारी होने हेतु उपयोगकर्ता के पास active सदस्यता होना ज़रूरी है। यह केवल स्पष्ट चयन पर लागू होता है (संगठन को नाम देने वाला अनुरोध, उसे साथ रखने वाला refresh, संगठन-स्कोप्ड कनेक्शन, या ठीक एक तक सीमित क्लाइंट)। अकाउंट के अपने पुराने टैग से केवल विरासत में मिला संगठन इस फ़्लैग से कभी गेट नहीं होता।

allowAutoMembership (डिफ़ॉल्ट बंद) उपयोगकर्ता को बिना आमंत्रण के जुड़ने देता है, जब उसका पुष्ट ईमेल पता संगठन के किसी सत्यापित डोमेन पर हो। यह authorize पर और हर refresh पर लागू होता है। नीचे Email domains and automatic सदस्यता देखें।

ईमेल डोमेन और स्वचालित सदस्यता

संगठन एक ईमेल डोमेन क्लेम करता है और DNS TXT रिकॉर्ड से साबित करता है कि वह उसे नियंत्रित करता है। allowAutoMembership चालू होने पर, जिस उपयोगकर्ता का पुष्ट ईमेल पता उस डोमेन पर है, वह संगठन के रूप में पहली बार साइन इन करते ही सदस्य बन जाता है।

1. इसे क्लेम करें। डोमेन के साथ POST /api/v1/organizations/{id}/domains। रिस्पॉन्स 201 होता है, जिसमें recordName (_authagonal-org.acme.com) और recordValue (authagonal-org-verify=<token>) होते हैं। टोकन यादृच्छिक है और हर क्लेम के लिए अलग।
2. रिकॉर्ड प्रकाशित करें। डोमेन के DNS में उसी नाम और ठीक उसी मान वाला TXT रिकॉर्ड जोड़ें।
3. इसे सत्यापित करें। POST /api/v1/organizations/{id}/domains/{domain}/verify रिकॉर्ड को खोजता है। मिलान होने पर 200 और verified: true लौटता है। न मिलने पर 409 verification_failed लौटता है, कभी verified: false के साथ 200 नहीं, ताकि सफलता के लिए पोल करने वाला क्लाइंट चूक को सफलता न समझ ले।
4. इसे हटाएँ। DELETE /api/v1/organizations/{id}/domains/{domain} 204 लौटाता है। मौजूदा सदस्यताएँ बनी रहती हैं, केवल आगे के auto-join रुकते हैं।

POST /api/v1/organizations/org_7fa2c9e1.../domains
Content-Type: application/json

{ "domain": "acme.com" }

201 Created
{
  "domain": "acme.com",
  "verified": false,
  "verifiedAt": null,
  "createdAt": "2026-10-03T01:02:03Z",
  "recordName": "_authagonal-org.acme.com",
  "recordValue": "authagonal-org-verify=Qm9...base64url"
}

अस्वीकृतियाँ: 400 domain_invalid (केवल DNS नाम नहीं), 409 domain_exists (इस संगठन पर पहले से है), 409 domain_taken (टेनेंट के किसी दूसरे संगठन के पास है), 404 organization_not_found और 404 domain_not_found। एक डोमेन प्रति टेनेंट अधिकतम एक संगठन का होता है, और यह verify के समय फिर से जाँचा जाता है।

Auto-सदस्यता नियम

Selector ऐसे उपयोगकर्ता को प्रवेश देता है जिसकी कोई active सदस्यता नहीं है, जब इनमें से सभी शर्तें पूरी हों:

• संगठन स्पष्ट रूप से चुना गया हो: साथ लाया गया refresh grant, संगठन-स्कोप्ड कनेक्शन, organization पैरामीटर (डोमेन पिन इसे उपलब्ध कराता है), या ठीक एक संगठन तक सीमित क्लाइंट। अकाउंट का अपना पुराना टैग कभी auto-join नहीं करता।
• संगठन enabled हो और allowAutoMembership चालू हो।
• उपयोगकर्ता का ईमेल पुष्ट हो, क्योंकि कोई भी [email protected] के रूप में रजिस्टर कर सकता है।
• ईमेल में अंतिम @ के बाद का हिस्सा, lowercase करके, संगठन के किसी सत्यापित डोमेन के ठीक बराबर हो। सबडोमेन मैचिंग नहीं होती: सत्यापित acme.com [email protected] को प्रवेश नहीं देता। हर सबडोमेन को अलग से क्लेम और सत्यापित करें।

सदस्यता गेट चलने से पहले यह क्या लिखता है: पंक्ति न हो तो बिना roles की नई active सदस्यता बनती है; invited पंक्ति roles बनाए रखते हुए active हो जाती है; active पंक्ति को छुआ नहीं जाता; suspended पंक्ति कभी promote नहीं होती।

Token org selection

अनुरोध किस संगठन पर resolve होता है, यह ठीक एक जगह तय होता है, इसलिए उत्तर /connect/authorize पर, हर refresh पर और device grant पर एक जैसा रहता है। प्राथमिकता, सबसे ऊपर वाली पहले:

डोमेन पिनिंग

कस्टम डोमेन को एक संगठन से पिन किया जा सकता है, जिससे वह डोमेन संगठन का अपना प्रवेश द्वार बन जाता है। पिन को tenant-resolution middleware GET /connect/authorize (क्वेरी स्ट्रिंग में जोड़कर) और POST /connect/par (इसमें भेजी गई body को बदला जाता है, क्योंकि PAR अपने पैरामीटर संग्रहीत payload से पढ़ता है) दोनों के लिए लागू करता है। पूरी प्रक्रिया के लिए कस्टम डोमेन देखें।

PUT /api/v1/custom-domains/auth.acme.com/organization
Content-Type: application/json

{ "organizationId": "org_7fa2c9e1..." }

संगठन-स्कोप्ड कनेक्शन

SAML या OIDC कनेक्शन किसी एक संगठन का हो सकता है। उससे साइन इन करने पर वह संगठन चुना जाता है और, यदि उपयोगकर्ता की कोई सदस्यता नहीं है, तो active सदस्यता बनती है। invited पंक्ति स्वीकार हो जाती है: वह active बन जाती है और अपने roles तथा आमंत्रणकर्ता बनाए रखती है, इसलिए जो आमंत्रित व्यक्ति अपने IdP से साइन इन करता है उसे ईमेल की कभी ज़रूरत नहीं पड़ती। suspended सदस्य suspended ही रहता है और टोकन जारी करते समय अस्वीकार किया जाता है। यह allowAutoMembership या डोमेन पर निर्भर नहीं करता, क्योंकि संगठन पहले ही कनेक्शन द्वारा चुना जा चुका है।

लॉगिन पेज पर संगठन का नाम

लॉगिन पेज ऐप के नाम के नीचे Signing in to {name} दिखाता है। नाम उसी संगठन से आता है जिससे पेज की ब्रांडिंग आती है: पहले पिन किए गए डोमेन का संगठन, फिर authorize अनुरोध में नामित संगठन, फिर क्लाइंट का एकमात्र सीमित संगठन। जब कोई संगठन न हो, या संगठन का नाम ऐप के नाम के बराबर हो, तब यह छिपा रहता है, ताकि हेडर कभी "Acme / Signing in to Acme" न पढ़े।

Branding override

संगठन का brandingJson लॉगिन पेज के लिए टेनेंट की ब्रांडिंग पर फ़ील्ड दर फ़ील्ड मर्ज होता है: मौजूद और non-null key ओवरराइड करती है, अनुपस्थित या null key विरासत में लेती है, और अज्ञात key को अनदेखा किया जाता है। ख़राब JSON टेनेंट की अपनी ब्रांडिंग पर लौट आता है और एक चेतावनी लॉग होती है, पेज लोड कभी विफल नहीं होता।

Branding टैब सभी 21 मर्ज-योग्य फ़ील्ड संपादित करता है: रूप-रंग (appName, logoUrl, primaryColor, customCssUrl), लाइट और डार्क मोड के रंग, ईमेल के रंग, supportEmail, showForgotPassword, poweredBy और languages। हर फ़ील्ड या तो टेनेंट का मान विरासत में लेता है, जो संकेत के रूप में दिखता है, या उसे ओवरराइड करता है, और Clear कंट्रोल उस key को हटा देता है।

पुराने संगठन टैग से Backfill

संगठनों के अस्तित्व में आने से पहले, उपयोगकर्ता के पास बिना किसी रिकॉर्ड वाला फ़्री-टेक्स्ट संगठन टैग हो सकता था। POST /api/v1/organizations/backfill उसे असली संगठनों और सदस्यताओं में माइग्रेट करता है, हर अलग पुराने मान के अनुसार समूहित करके। जब तक body { "dryRun": false } न हो, यह केवल dry run होता है।

• सीमित: प्रति कॉल अधिकतम 50,000 उपयोगकर्ता स्कैन करता है। truncated रिस्पॉन्स का मतलब है इसे फिर चलाएँ। दोबारा चलाने पर पहले से माइग्रेट हो चुके उपयोगकर्ता छोड़ दिए जाते हैं।
• Idempotent: पहले से माइग्रेट हुआ कोई अलग पुराना मान आंतरिक stamp से मिलाया जाता है, संगठन के (संपादन-योग्य) प्रदर्शन नाम से नहीं, इसलिए बाद में बने संगठन का नाम बदलने से अगले रन में डुप्लिकेट नहीं बनता।

{
  "dryRun": true,
  "organizationsCreated": 3,
  "membershipsCreated": 41,
  "usersSkipped": 0,
  "organizations": [
    { "legacyValue": "acme-corp", "slug": "acme-corp", "users": 22 }
  ],
  "truncated": false
}

पोर्टल UI वॉकथ्रू

संगठन पेज टेनेंट के हर संगठन को सूचीबद्ध करता है, एक बार में 50, और लोड करें बटन के साथ, और नया संगठन (केवल slug + नाम, पॉलिसी फ़्लैग, डोमेन और ब्रांडिंग बाद में सेट होते हैं) तथा विरासत संगठन फ़ील्ड से भरें फ़्लो देता है, जो ऊपर का backfill पहले preview के रूप में चलाता है, फिर लागू करें।

संगठन सूची टेनेंट के हर ग्राहक संगठन को उसके slug, नाम और निर्माण तिथि के साथ दिखाती है

हर संगठन के विवरण पेज पर तीन टैब हैं: सामान्य (नाम, केवल-पढ़ने योग्य slug, तीन पॉलिसी टॉगल, ईमेल डोमेन जोड़ने, सत्यापित करने, हटाने और TXT रिकॉर्ड कॉपी करने के लिए ईमेल डोमेन कार्ड, और slug टाइप करके पुष्टि वाला डिलीट), Branding (हर ओवरराइड-योग्य फ़ील्ड, जो टेनेंट का मान विरासत में लेता है या उसे ओवरराइड करता है), और सदस्य (ईमेल से जोड़ें, खाता न होने पर आमंत्रण का विकल्प मिलता है, प्रति पंक्ति स्थिति बदलें और हटाएँ, और लोड करें के साथ)।

Members टैब हर सदस्यता को उसकी स्थिति और बदलने या हटाने के प्रति-पंक्ति कंट्रोल के साथ दिखाता है

Branding टैब इस संगठन के लिए टेनेंट की लॉगिन-पेज ब्रांडिंग को फ़ील्ड दर फ़ील्ड ओवरराइड करता है

Domains पेज में डोमेन → संगठन selector है: हर डोमेन कार्ड में इनलाइन ड्रॉपडाउन है जो टेनेंट के संगठनों को सूचीबद्ध करता है, साथ में "टेनेंट (कोई नहीं)" विकल्प जो पिन हटा देता है, और बदलते ही तुरंत लागू हो जाता है। डोमेन जोड़ते समय भी यही selector दिखाई देता है।

डोमेन कार्ड पर इनलाइन संगठन selector उस कस्टम डोमेन को एक संगठन से पिन करता है

ऑडिट इवेंट

organization.created · organization.updated · organization.deleted · organization.member.added · organization.member.invited · organization.member.joined · organization.member.updated · organization.member.removed · organization.domain_added · organization.domain_verified · organization.domain_removed · organization.backfill · domain.organization_set

पेजिंग

संगठन सूची और सदस्य सूची cursor-पेज्ड हैं और { items, nextCursor } लौटाती हैं। limit दें (डिफ़ॉल्ट 50, 1 से 200 तक सीमित) और पहले पेज के बाद पिछले रिस्पॉन्स का nextCursor बिना बदले cursor के रूप में दें। Null nextCursor आख़िरी पेज है। Cursor संगठन id (या सदस्यों के लिए user id) पर एक अपारदर्शी keyset स्थिति है, इसलिए कॉल के बीच पंक्तियाँ जोड़ने या हटाने से कोई पेज खिसकता या दोहराया नहीं जाता। जो cursor सूची ने जारी नहीं किया, वह 400 invalid_cursor है।

AI असिस्टेंट से संगठन प्रबंधित करना

होस्टेड पोर्टल MCP तेरह संगठन टूल देता है, सभी के लिए टेनेंट admin भूमिका ज़रूरी है: संगठनों की सूची, get, create, update और delete; सदस्यों की सूची, जोड़ना, अपडेट और हटाना; ईमेल डोमेन जोड़ना, सत्यापित करना और हटाना; और किसी उपयोगकर्ता के संगठनों की सूची। ये ऊपर के API जैसे ही ऑपरेशन कॉल करते हैं, इसलिए कोई टूल अपने route से अलग नहीं हो सकता। अपना पोर्टल AI असिस्टेंट से चलाएँ देखें।

प्रति होस्ट एक issuer

टेनेंट का हर होस्ट अपना खुद का OIDC issuer है। जब अनुरोध का होस्ट टेनेंट की डोमेन टेबल से resolve हुआ हो, तब issuer और discovery द्वारा विज्ञापित हर एंडपॉइंट URL https://{host} होता है, इसलिए हर active कस्टम डोमेन अपना iss घोषित करता है और टेनेंट का canonical होस्ट अपरिवर्तित रहता है। साइनिंग keys प्रति टेनेंट होती हैं, इसलिए हर होस्ट वही key सेट परोसता है। इसी से एक टेनेंट कई ग्राहकों को सँभाल पाता है, हर एक अपने ब्रांडेड डोमेन पर, जो अपने संगठन से पिन है। कस्टम डोमेन देखें।

ईमेल कॉन्फ़िगरेशन

कॉन्फ़िगर करें कि आपका टेनेंट ट्रांज़ैक्शनल ईमेल कैसे भेजता है, जैसे सत्यापन, पासवर्ड रीसेट, और आमंत्रण ईमेल। डिफ़ॉल्ट साझा प्रेषक, Resend के माध्यम से सत्यापित कस्टम डोमेन, या अपने स्वयं के SMTP सर्वर में से चुनें।

स्थानीयकृत ईमेल

ट्रांज़ैक्शनल ईमेल प्राप्तकर्ता की पसंदीदा भाषा में भेजे जाते हैं। सत्यापन, पासवर्ड-रीसेट, account-exists, स्वागत, आमंत्रण, खाता हटाना, सहायता, और बिलिंग ईमेल ग्यारह लोकेल में टेम्पलेट किए गए हैं: अंग्रेज़ी, जर्मन, फ़्रेंच, स्पेनिश, पुर्तगाली, वियतनामी, सरलीकृत चीनी, जापानी, अरबी, हिंदी, और अफ़्रीकान्स। जब प्राप्तकर्ता की भाषा के लिए कोई टेम्पलेट मौजूद नहीं होता, तो ईमेल अंग्रेज़ी पर फ़ॉलबैक करता है।

भाषा भेजने के समय प्राप्तकर्ता की संग्रहीत प्राथमिकता से तय की जाती है। वह प्राथमिकता कई स्थानों से आ सकती है:

• साइन-अप और पंजीकरण — होस्टेड साइन-इन स्क्रीन पर उपयोगकर्ता द्वारा चुनी गई भाषा से कैप्चर किया गया।
• पोर्टल Users पेज — उपयोगकर्ता बनाते या संपादित करते समय एडमिन द्वारा सेट किया गया।
• SCIM प्रोविज़निंग: जब उपयोगकर्ता SCIM के माध्यम से सिंक किए जाते हैं तो IdP के preferredLanguage (या locale) से मैप किया गया।
• स्व-सेवा खाता पेज — उपयोगकर्ता द्वारा स्वयं /login/account पर चुना गया।

ईमेल प्रोवाइडर

प्रेषक पहचान

प्रेषक ईमेल और नाम सभी प्रोवाइडर मोड में साझा होते हैं। कस्टम डोमेन (Resend) और कस्टम SMTP प्रोवाइडर के लिए प्रेषक ईमेल आवश्यक है; खाली होने पर प्रेषक नाम branding app नाम पर फ़ॉलबैक करता है।

Resend Custom Domain

अपने सेंडिंग डोमेन को Resend के साथ एक बार सत्यापित करें, फिर इसे इस टेनेंट के लिए From पते के रूप में उपयोग करें। DNS रिकॉर्ड (SPF, DKIM) सेटिंग्स → ईमेल पर कस्टम भेजने वाला डोमेन पैनल में दिखाए जाते हैं; जब आप <strong>सत्यापन जाँचें</strong> पर क्लिक करते हैं तो Resend उनकी जाँच करता है।

कस्टम SMTP

अपना स्वयं का SMTP सर्वर लाएँ — आंतरिक रिले, Resend द्वारा कवर न किए गए विक्रेताओं, या नियामक पिनिंग के लिए उपयोगी।

कस्टम सेंडिंग डोमेन

कस्टम डोमेन (Resend) प्रोवाइडर का उपयोग करते समय, आप अपना स्वयं का डोमेन पंजीकृत कर सकते हैं ताकि ईमेल @authagonal.io के बजाय आपके ब्रांड से आएँ (उदा. [email protected])।

1. सेटिंग्स → ईमेल पर जाएँ और कस्टम डोमेन (Resend) प्रोवाइडर चुनें।
2. अपना डोमेन नाम दर्ज करें और डोमेन पंजीकृत करें पर क्लिक करें।
3. दिखाए गए DNS रिकॉर्ड (DKIM, SPF, और return path) को अपने डोमेन के DNS में जोड़ें।
4. Check Verification पर क्लिक करें — एक बार DNS प्रसारित हो जाने पर (आमतौर पर 1–10 मिनट), डोमेन स्थिति verified में बदल जाएगी।

परीक्षण

अपना कॉन्फ़िगरेशन सत्यापित करने के लिए Settings → Email में Send Test Email बटन का उपयोग करें। वर्तमान में सहेजी गई सेटिंग्स का उपयोग करके आपके एडमिन ईमेल पते पर एक परीक्षण ईमेल भेजा जाएगा।

ऑडिट लॉग

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

लॉग कॉलम

ट्रैक की गई कार्रवाइयाँ

निम्नलिखित प्रशासनिक कार्रवाइयाँ ऑडिट लॉग में दर्ज की जाती हैं:

ऑडिट लॉग सभी प्रशासनिक कार्रवाइयों का पूर्ण रिकॉर्ड प्रदान करता है

बैकअप

Authagonal स्वचालित रूप से आपके टेनेंट डेटा का प्रति घंटा शेड्यूल पर बैकअप लेता है। बैकअप में सभी उपयोगकर्ता, समूह, भूमिकाएँ, क्लाइंट, SSO कनेक्शन, SCIM टोकन, ब्रांडिंग, और सेटिंग्स शामिल होते हैं। आप बैकअप इतिहास देख सकते हैं और Backups पेज से नवीनतम पूर्ण बैकअप डाउनलोड कर सकते हैं।

बैकअप कैसे काम करते हैं

• दिन में एक बार प्रति घंटे के incremental बैकअप को मिलाकर एक नया पूर्ण बैकअप बनाया जाता है, और रविवार को दैनिक पूर्ण बैकअप को मिलाकर एक साप्ताहिक बैकअप बनाया जाता है। सात दैनिक और चार साप्ताहिक बैकअप रखे जाते हैं।
• इंक्रीमेंटल बैकअप प्रति घंटा चलते हैं, जो केवल पिछले बैकअप के बाद से बदली गई पंक्तियों को कैप्चर करते हैं।
• बैकअप आपके टेनेंट द्वारा उपयोग की जाने वाली समान मैनेज्ड आइडेंटिटी के साथ Azure Blob Storage में संग्रहीत होते हैं।
• हटाए गए रिकॉर्ड tombstones के माध्यम से ट्रैक किए जाते हैं और ऑडिट पूर्णता के लिए बैकअप में शामिल किए जाते हैं।

बैकअप डाउनलोड करना

सबसे हाल के पूर्ण बैकअप को सभी बाद के इंक्रीमेंटल बैकअप के साथ मर्ज करके एक ZIP फ़ाइल प्राप्त करने के लिए Download Latest पर क्लिक करें। प्रत्येक टेबल को एक JSONL फ़ाइल के रूप में निर्यात किया जाता है (प्रति पंक्ति एक JSON ऑब्जेक्ट)।

प्रोविज़निंग ऐप्स

प्रोविज़निंग ऐप्स आपकी अपनी सेवाएँ हैं, जिन्हें Authagonal हर बार किसी उपयोगकर्ता के बनने पर कॉल करता है, ताकि वे खाता तैयार कर सकें, लाइसेंस दे सकें, तय कर सकें कि उपयोगकर्ता किस संगठन का है, या साइनअप को सीधे अस्वीकार कर सकें।

यह कैसे काम करता है

जब कोई उपयोगकर्ता बनाया जाता है, तो Authagonal आपके प्रोविज़निंग ऐप के कॉलबैक URL को TCC (Try/Confirm/Cancel) पैटर्न से कॉल करता है। किसी भी ऐप को कमिट करने से पहले हर ऐप को Try चरण में स्वीकृति देनी होती है, ताकि कई डाउनस्ट्रीम सिस्टम सहमत हो सकें, या कोई एक वीटो कर सके, और आधे बने खाते पीछे न छूटें।

प्रोविज़निंग कब चलती है

प्रोविज़निंग हर उस पथ पर चलती है जो उपयोगकर्ता बनाता है, केवल सेल्फ-सर्विस साइनअप पर नहीं। जिन ऐप और उपयोगकर्ता संयोजनों की प्रोविज़निंग पहले हो चुकी है, उन्हें छोड़ दिया जाता है, इसलिए ऐप हर उपयोगकर्ता को एक ही बार देखता है।

Try अनुरोध

Authagonal यह JSON <code>{callbackUrl}/try</code> पर POST करता है। जिन फ़ील्ड्स का कोई मान नहीं होता, उन्हें null के रूप में भेजने के बजाय छोड़ दिया जाता है।

SSO से आने वाला उपयोगकर्ता वह सामान्य स्थिति है जिसकी योजना बनानी चाहिए: उनके पास अभी कोई संगठन नहीं होता, और federated_connection बताता है कि वे आपके किस ग्राहक से आए हैं।

{
  "transactionId": "8f14e45fceea167a5a36dedd4bea2543",
  "userId": "0f6b1c8e-3d2a-4f51-9e77-2c1a4b5d6e7f",
  "email": "[email protected]",
  "firstName": "Ada",
  "lastName": "Lovelace",
  "customAttributes": {
    "federated_connection": "acme-okta"
  }
}

Try प्रतिक्रिया

आपका ऐप 200 और एक JSON बॉडी के साथ उत्तर देता है। यह बॉडी केवल पावती नहीं है: यही वह तरीका है जिससे कोई डाउनस्ट्रीम ऐप वह संगठन और एट्रिब्यूट सौंपता है जो अंततः उपयोगकर्ता के टोकन पर आते हैं।

{
  "approved": true,
  "organizationId": "org_acme",
  "customAttributes": { "org_role": "member" }
}

उपयोगकर्ताओं को सही संगठन से चिह्नित करना

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

// POST {callbackUrl}/try
app.post('/provisioning/try', async (req, res) => {
  const { email, customAttributes } = req.body;

  // An SSO user carries the connection that vouched for them. That is the
  // customer, and it stays right when one customer has several domains.
  const connection = customAttributes?.federated_connection;

  const org = connection
    ? await orgByConnection(connection)
    : await orgByPendingInvite(email);

  if (!org) return res.json({ approved: false, reason: 'No organization for this user' });

  // Stamped on the user and emitted as org_id on every token from now on.
  res.json({ approved: true, organizationId: org.id });
});

प्रोविज़निंग ऐप जोड़ना

प्रोविज़निंग ऐप जोड़ने के लिए, एक ऐप नाम, एक Callback URL, एक वैकल्पिक API Key, और एक वैकल्पिक Try टाइमआउट (सेकंड, डिफ़ॉल्ट 60, सीमा 5 से 300; Confirm और Cancel एक निश्चित छोटे टाइमआउट का उपयोग करते हैं) दें। API key प्रत्येक वेबहुक अनुरोध के Authorization हेडर में Bearer टोकन के रूप में भेजी जाती है, जो आपके ऐप को Authagonal से अनुरोधों को प्रमाणित करने की अनुमति देती है।

परीक्षण

अपने कॉलबैक URL पर एक परीक्षण अनुरोध भेजने के लिए किसी भी प्रोविज़निंग ऐप के बगल में Test पर क्लिक करें। परीक्षण परिणाम HTTP स्टेटस कोड और रिस्पॉन्स बॉडी प्रदर्शित करते हैं, जो आपको सत्यापित करने में मदद करते हैं कि आपका ऐप वेबहुक को सही ढंग से प्राप्त और संसाधित कर रहा है।

वेबहुक डिलीवरी और रिस्पॉन्स हैंडलिंग सत्यापित करने के लिए प्रोविज़निंग ऐप्स का परीक्षण करें

प्लान सीमाएँ

प्रोविज़निंग ऐप्स की अधिकतम संख्या प्रति टेनेंट कॉन्फ़िगर करने योग्य है, जिसकी डिफ़ॉल्ट सीमा 6 है। यदि आपके वर्कफ़्लो को अतिरिक्त प्रोविज़निंग लक्ष्यों की आवश्यकता हो तो इस सीमा को एक एडमिन द्वारा समायोजित किया जा सकता है।

टीम

Team पेज पोर्टल एडमिनिस्ट्रेटर का प्रबंधन करता है: वे लोग जो मैनेजमेंट पोर्टल के माध्यम से आपके टेनेंट तक पहुँच और उसे कॉन्फ़िगर कर सकते हैं। हर टीम सदस्य की एक भूमिका (मालिक, एडमिन, डेवलपर या सपोर्ट) होती है जो तय करती है कि वे क्या बदल सकते हैं।

एडमिन सूची

एडमिन सूची प्रत्येक टीम सदस्य का नाम, ईमेल पता, भूमिका, और उन्हें जोड़े जाने की तिथि प्रदर्शित करती है। वर्तमान उपयोगकर्ता की पंक्ति के बगल में एक "आप" संकेतक दिखाया जाता है ताकि आप आसानी से अपना खाता पहचान सकें।

एडमिन को आमंत्रित करना

नए टीम सदस्य को आमंत्रित करने के लिए, उनका ईमेल पता, नाम, और भूमिका दें। उन्हें एक ईमेल मिलता है जिसमें अपना पासवर्ड सेट करने और अपना खाता सक्रिय करने का लिंक होता है; लिंक 7 दिनों तक मान्य रहता है।

आमंत्रण फ़ील्ड

एडमिन आमंत्रण एक लंबित खाता बनाते हैं और आमंत्रित व्यक्ति को एक सक्रियण लिंक ईमेल करते हैं।

एडमिन को हटाना

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

Team पेज से पोर्टल एडमिनिस्ट्रेटर प्रबंधित करें

सपोर्ट

पोर्टल छोड़े बिना Authagonal टीम के साथ एक सपोर्ट टिकट खोलें। प्रत्येक टिकट एक थ्रेडेड बातचीत है, इसलिए आप और हमारी टीम पहली रिपोर्ट से समाधान तक एक ही पृष्ठ पर रहते हैं।

आपके टिकट

सपोर्ट पेज आपके द्वारा उठाए गए हर टिकट को सूचीबद्ध करता है, नवीनतम गतिविधि पहले। एक नज़र में यह देखने के लिए स्टेटस बैज का उपयोग करें कि क्या आप पर प्रतीक्षारत है और क्या हम पर।

विषय, स्थिति, प्राथमिकता, और अंतिम गतिविधि के साथ आपके सपोर्ट टिकट

• प्रत्येक पंक्ति विषय, वर्तमान स्थिति (open, pending, resolved, या closed), प्राथमिकता, और अंतिम गतिविधि का समय दिखाती है।
• एक टिकट खोलने के लिए New ticket पर क्लिक करें, फिर उसे एक विषय, प्राथमिकता, और अपना पहला संदेश दें।
• रंग-कोडित स्टेटस बैज उन टिकटों के लिए सूची को स्कैन करना आसान बनाते हैं जिन्हें आपके ध्यान की आवश्यकता है।

एक टिकट थ्रेड

किसी टिकट को खोलने पर पूरी बातचीत दिखती है। उत्तर क्रम में पोस्ट होते हैं, और हमारी टीम के नए संदेश पेज रीलोड किए बिना दिखाई देते हैं।

आपके और Authagonal टीम के बीच एक टिकट थ्रेड

• आपके और Authagonal टीम के बीच थ्रेडेड संदेश कालानुक्रमिक क्रम में दिखाए जाते हैं।
• लॉग, स्क्रीनशॉट, या कॉन्फ़िगरेशन साझा करने के लिए इनलाइन Reply करें और फ़ाइलें संलग्न करें।
• थ्रेड लाइव अपडेट होता है, इसलिए हमारी टीम का उत्तर भेजते ही दिखाई दे जाता है।
• यदि आप इसके बजाय किसी सूचना ईमेल का उत्तर देते हैं, तो आपका संदेश स्वचालित रूप से थ्रेड में जोड़ दिया जाता है।

आपके उपयोगकर्ताओं के लिए सपोर्ट डेस्क

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

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

इसे चालू करना

पोर्टल में ग्राहक सहायता खोलें, उसके सेटिंग्स टैब पर जाएँ और ग्राहक सहायता सक्षम करें चालू करें। यह टैब owners और admins के लिए उपलब्ध है। जब तक आप ऐसा नहीं करते, आपके उपयोगकर्ताओं को कुछ भी दिखाई नहीं देता।

आपके उपयोगकर्ता क्या देखते हैं

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

अनाम टिकट सक्षम होने पर, जो व्यक्ति साइन इन नहीं कर सकता वह भी टिकट उठा सकता है। वह एक ईमेल पता और अपना संदेश देता है, और बदले में उसे बातचीत का एक निजी लिंक मिलता है। अंदर आने का यही एकमात्र रास्ता है, इसलिए इसे एक क्रेडेंशियल की तरह मानें: इसका अंदाज़ा नहीं लगाया जा सकता, और जिसके पास यह होगा वह उस एक थ्रेड को पढ़ भी सकता है और उसका जवाब भी दे सकता है।

ऑपरेटर इनबॉक्स

आपकी टीम पोर्टल के साइड मेनू में ग्राहक सहायता से जवाब देती है। यह हमारे साथ चल रहे आपके अपने टिकटों से अलग जगह है, और यह tenant:support भूमिका तथा उससे ऊपर वालों के लिए उपलब्ध है, इसलिए आप किसी एजेंट को बाकी पोर्टल दिए बिना इस डेस्क तक पहुँच दे सकते हैं।

उपयोगकर्ता अपनी भाषा में लिखते हैं

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

टाइमज़ोन

टिकट यह दर्ज करता है कि उपयोगकर्ता ने उसे किस टाइमज़ोन से उठाया था। इसके बाद हर संदेश आपके समय के बगल में उसका स्थानीय समय भी दिखाता है, ताकि 14:32 पर दिया गया जवाब वैसे ही 02:32 के रूप में पढ़ा जाए जैसा वह उस व्यक्ति के लिए वास्तव में था जो उसका इंतज़ार कर रहा था। जब टाइमज़ोन अज्ञात हो, जैसे ईमेल से आए किसी टिकट में, या जब वह आपके ही टाइमज़ोन जैसा हो, तब कुछ नहीं दिखाया जाता।

वेबहुक

टिकट इवेंट्स को घटित होते ही पाने के लिए एक सपोर्ट वेबहुक URL सेट करें, ताकि अलर्ट उठाया जा सके या टिकटों को अपने सिस्टम में मिरर किया जा सके। पेलोड हस्ताक्षरित होते हैं, इसलिए आप पुष्टि कर सकते हैं कि वे हमसे आए हैं।

इम्पोर्ट और माइग्रेट

किसी मौजूदा identity सिस्टम को अपने Authagonal टेनेंट में माइग्रेट करें। दो स्रोत समर्थित हैं — Duende IdentityServer (एक SQL Server डेटाबेस) और Auth0 (Management API)। प्रत्येक एक read-only प्रीव्यू चलाता है ताकि कमिट करने से पहले आप ठीक-ठीक समीक्षा कर सकें कि क्या कॉपी किया जाएगा।

Duende IdentityServer से इम्पोर्ट करें

किसी मौजूदा Duende IdentityServer SQL Server डेटाबेस से क्लाइंट, स्कोप, उपयोगकर्ता, और भूमिकाओं को अपने Authagonal टेनेंट में माइग्रेट करें। इम्पोर्ट दो चरणों में चलता है — प्रीव्यू और कमिट — ताकि कोई भी बदलाव होने से पहले आप समीक्षा कर सकें कि क्या कॉपी किया जाएगा।

क्या इम्पोर्ट होता है

इम्पोर्टर Duende की ConfigurationDb और ASP.NET Identity तालिकाओं से पढ़ता है और मैप की गई पंक्तियों को आपके टेनेंट में लिखता है। persisted ग्रांट्स, device codes, और साइनिंग keys जैसे अल्पकालिक artifacts को छोड़ दिया जाता है।

कमिट से पहले प्रीव्यू

अपनी Duende ConfigurationDb / IdentityDb connection string पेस्ट करें और पूर्वावलोकन चलाएं पर क्लिक करें। प्रीव्यू एक read-only कनेक्शन खोलता है और हर उस पंक्ति को गिनता है जो इम्पोर्ट की जाएगी। कोई write नहीं होता।

• क्लाइंट, स्कोप, उपयोगकर्ता, भूमिकाओं, और भूमिका असाइनमेंट के लिए एंटिटी गणना।
• जब लक्ष्य टेनेंट में पहले से क्लाइंट (मेल खाने वाले ClientIds ओवरराइट हो जाते हैं), भूमिकाएँ, या स्कोप (मेल खाने वाले नाम छोड़ दिए जाते हैं) होते हैं तो टकराव (collision) चेतावनियाँ।
• अज्ञात तालिकाओं और बिना मैप किए गए कॉलम के लिए चेतावनियाँ ताकि आपको पता रहे कि क्या छोड़ा जाएगा।

गणना और चेतावनियों के साथ प्रीव्यू पैनल

Password Hashes

Duende पासवर्ड को ASP.NET Identity V3 (PBKDF2) का उपयोग करके संग्रहीत करता है। Authagonal का PasswordHasher उस प्रारूप को सीधे सत्यापित करता है और पहले सफल साइन-इन पर मूल प्रारूप में rehash करता है — उपयोगकर्ता बिना किसी reset प्रवाह के अपने मौजूदा पासवर्ड बनाए रखते हैं।

उपयोगकर्ता ID सुलह

यदि इस टेनेंट में पहले से मौजूद किसी उपयोगकर्ता का ईमेल किसी आने वाले रिकॉर्ड के समान है, तो इम्पोर्ट उस खाते के userId को इम्पोर्ट करने से पहले स्रोत sub में बदल देता है, ताकि इम्पोर्ट की गई भूमिकाएँ, लॉगिन, और क्लेम मौजूदा खाते से जुड़ जाएँ और वे ऐप जो पहले से उपयोगकर्ता को उसके स्रोत sub द्वारा संदर्भित करते हैं, cutover के बाद भी resolve होते रहें। खाते का मौजूदा पासवर्ड और प्रोफ़ाइल संरक्षित रहते हैं; स्रोत भूमिकाएँ उसके ऊपर merge हो जाती हैं। प्रीव्यू हर उस खाते की सूची देता है जिसे आपके कमिट करने से पहले reconcile किया जाएगा।

इम्पोर्ट चलाना

प्रीव्यू की समीक्षा करने के बाद आयात शुरू करें पर क्लिक करें। कमिट चरण क्लाइंट, स्कोप, उपयोगकर्ता, भूमिकाओं, और external-login संदर्भों को आपके टेनेंट स्टोर में लिखता है। मेल खाने वाले clientId वाले क्लाइंट ओवरराइट हो जाते हैं; मेल खाने वाले scope name, email, या role name वाली पंक्तियों को छोड़ दिया जाता है, इसलिए इम्पोर्टर को पुनः चलाना सुरक्षित है।

क्या इम्पोर्ट नहीं होता

• Persisted grants, device codes, server-side sessions — अल्पकालिक, स्वचालित रूप से पुनः जनरेट होते हैं।
• Signing keys — Authagonal अपनी स्वयं की प्रति-टेनेंट कुंजियाँ जारी करता है।
• कस्टम कॉलम और तालिकाएँ — Duende के मानक स्कीमा के बाहर की कोई भी चीज़ एक चेतावनी के रूप में सामने आती है ताकि आपको पता रहे कि डेटा छोड़ दिया गया था।
• अक्षम किए गए क्लाइंट — अक्षम अवस्था में इम्पोर्ट होते हैं; तैयार होने पर उन्हें Clients पेज से पुनः सक्षम करें।

Auth0 से इम्पोर्ट करें

Authagonal को अपने Auth0 टेनेंट की Management API से कनेक्ट करें और अपने एप्लिकेशन, API, भूमिकाओं, उपयोगकर्ताओं, और enterprise connections को ले आएँ। इम्पोर्ट किए गए उपयोगकर्ता और एप्लिकेशन ID संरक्षित रहते हैं, ताकि मौजूदा sub और client_id संदर्भ cutover के बाद भी resolve होते रहें।

आपको क्या चाहिए होगा

Auth0 में Management API के लिए अधिकृत एक Machine-to-Machine application बनाएँ, जिसे ये read स्कोप दिए गए हों: read:users, read:clients, read:resource_servers, read:roles, read:connections, read:client_grants। इसके domain, client ID, और client सीक्रेट को इम्पोर्ट फ़ॉर्म में पेस्ट करें — इनका उपयोग केवल इम्पोर्ट के लिए किया जाता है।

क्या इम्पोर्ट होता है

Passwords

Auth0 की Management API कभी password hashes नहीं लौटाती। यदि आपके पास Auth0 का support-assisted bulk password export (NDJSON) है, तो उसे प्रदान करें — bcrypt hashes यथावत इम्पोर्ट होते हैं और आपके उपयोगकर्ता बिना किसी reset के अपने पासवर्ड बनाए रखते हैं। वह फ़ाइल आपका पूरा उपयोगकर्ता सेट भी वहन करती है, जो Auth0 की 1,000-उपयोगकर्ता API सूचीकरण सीमा को हटा देती है। इसके बिना, उपयोगकर्ता प्रोफ़ाइल के रूप में इम्पोर्ट होते हैं और पहले साइन-इन पर एक नया पासवर्ड सेट करते हैं।

API संदर्भ

प्रत्येक टेनेंट https://{slug}.authagonal.io पर एक मानक-अनुरूप OIDC सर्वर उपलब्ध कराता है। सभी एंडपॉइंट OAuth 2.0 और OpenID Connect विनिर्देशों का पालन करते हैं। यह संदर्भ हर उस एंडपॉइंट को कवर करता है जिससे आपके एप्लिकेशन को इंटरैक्ट करने की आवश्यकता हो सकती है।

PKCE के साथ Authorization Code Flow

OIDC डिस्कवरी और JWKS

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

GET /.well-known/openid-configuration

OpenID Provider Configuration दस्तावेज़ लौटाता है। प्रतिक्रिया में वह सारा मेटाडेटा शामिल होता है जो आपके क्लाइंट को इस टेनेंट के साथ इंटरैक्ट करने के लिए चाहिए।

GET /.well-known/openid-configuration/jwks

टोकन हस्ताक्षरों को सत्यापित करने के लिए उपयोग किया जाने वाला JSON Web Key Set लौटाता है। प्रतिक्रिया में EC P-256 सार्वजनिक कुंजियों का एक keys array होता है (टोकन ES256 से हस्ताक्षरित होते हैं), जिनमें से प्रत्येक में kty (EC), use, kid, alg, crv, x, और y फ़ील्ड शामिल होते हैं।

curl https://acme.authagonal.io/.well-known/openid-configuration

Authorization एंडपॉइंट

GET /connect/authorize

एक authorization code flow आरंभ करता है। उपयोगकर्ता के पास एक सक्रिय सत्र होना चाहिए, अन्यथा उन्हें लॉगिन पेज पर रीडायरेक्ट कर दिया जाएगा। सफल होने पर, उपयोगकर्ता को एक authorization code के साथ वापस आपके एप्लिकेशन पर रीडायरेक्ट किया जाता है।

सफलता प्रतिक्रिया: code और state क्वेरी पैरामीटर के साथ redirect_uri पर 302 रीडायरेक्ट।

त्रुटि प्रतिक्रिया: error, error_description, और state क्वेरी पैरामीटर के साथ 302 रीडायरेक्ट।

Pushed Authorization Requests (PAR)

RFC 9126। हर authorize पैरामीटर को URL पर रखने के बजाय, आपका क्लाइंट सामान्य क्लाइंट प्रमाणीकरण के साथ उन्हें /connect/par पर POST करता है और एक अल्पकालिक अपारदर्शी request_uri वापस पाता है। फिर ब्राउज़र /connect/authorize?client_id=...&request_uri=... पर जाता है — और कुछ भी ब्राउज़र इतिहास, सर्वर लॉग, या Referer हेडर में नहीं पहुँचता, और सर्वर पहले ही क्लाइंट auth के तहत पैरामीटर की अखंडता जाँच चुका होता है।

POST /connect/par

क्लाइंट प्रमाणीकरण /connect/token के समान है: client_id/client_secret के साथ HTTP Basic, या form-एन्कोडेड क्रेडेंशियल। Public क्लाइंट बिना सीक्रेट के पोस्ट करते हैं। body में वही पैरामीटर होते हैं जो आप सामान्यतः /connect/authorize पर भेजते हैं; request_uri स्वयं अस्वीकृत कर दिया जाता है (PAR को chain करना विनिर्देश के §2.1 द्वारा निषिद्ध है)। 201 Created लौटाता है।

प्रतिक्रिया

फ़ॉलो-अप GET /connect/authorize?client_id=…&request_uri=… पर, अन्य सभी पैरामीटर pushed payload से लिए जाते हैं और कोई भी अतिरिक्त क्वेरी पैरामीटर अनदेखा कर दिया जाता है। authorize कॉल पर client_id उस क्लाइंट से मेल खाना चाहिए जिसने अनुरोध push किया था। एक बार उपयोग होने पर (या expires_in बीत जाने पर), request_uri स्टोर से हटा दिया जाता है।

# 1. Push parameters (server returns request_uri + expires_in)
curl -X POST https://acme.authagonal.io/connect/par \
  -u "my-app:CLIENT_SECRET" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "response_type=code" \
  -d "redirect_uri=https://app.example.com/callback" \
  -d "scope=openid profile email" \
  -d "state=$(openssl rand -hex 16)" \
  -d "code_challenge=YOUR_CODE_CHALLENGE" \
  -d "code_challenge_method=S256"

# 2. Send the user to /authorize with only client_id + request_uri
# https://acme.authagonal.io/connect/authorize?client_id=my-app&request_uri=urn:ietf:params:oauth:request_uri:abc123...

Token एंडपॉइंट

POST /connect/token

क्रेडेंशियल को टोकन के लिए एक्सचेंज करता है। अनुरोधों को Content-Type: application/x-www-form-urlencoded का उपयोग करना चाहिए। क्लाइंट प्रमाणीकरण HTTP Basic auth (Authorization: Basic base64(client_id:client_secret)) के माध्यम से या form body पैरामीटर (client_id + client_secret) के रूप में प्रदान किया जा सकता है।

Authorization Code Grant

Refresh Token Grant

Client Credentials Grant

Device Code Grant

Token प्रतिक्रिया:

curl -X POST https://acme.authagonal.io/connect/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=AUTHORIZATION_CODE" \
  -d "redirect_uri=https://app.example.com/callback" \
  -d "client_id=my-app" \
  -d "code_verifier=YOUR_CODE_VERIFIER"

UserInfo एंडपॉइंट

GET /connect/userinfo

प्रमाणित उपयोगकर्ता के बारे में क्लेम लौटाता है। openid स्कोप के साथ एक वैध एक्सेस टोकन की आवश्यकता होती है।

curl https://acme.authagonal.io/connect/userinfo \
  -H "Authorization: Bearer ACCESS_TOKEN"

Token Introspection (RFC 7662)

POST /connect/introspect

एक टोकन को सत्यापित करता है और उसका मेटाडेटा लौटाता है। क्लाइंट क्रेडेंशियल (Basic auth या form body पैरामीटर) की आवश्यकता होती है।

सक्रिय टोकन प्रतिक्रिया:

निष्क्रिय टोकन प्रतिक्रिया: { "active": false }

curl -X POST https://acme.authagonal.io/connect/introspect \
  -u "my-app:CLIENT_SECRET" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "token=ACCESS_OR_REFRESH_TOKEN"

Token Revocation (RFC 7009)

POST /connect/revocation

पहले जारी किए गए टोकन को रद्द करता है। क्लाइंट क्रेडेंशियल की आवश्यकता होती है।

RFC 7009 विनिर्देश के अनुसार, एंडपॉइंट हमेशा 200 OK लौटाता है, यहाँ तक कि अमान्य या पहले से रद्द किए गए टोकन के लिए भी।

Device Authorization (RFC 8628)

POST /connect/deviceauthorization

इनपुट-सीमित उपकरणों (CLI, स्मार्ट TV, IoT उपकरण) के लिए device authorization flow आरंभ करता है। डिवाइस उपयोगकर्ता को एक कोड दिखाता है, जो फिर ब्राउज़र वाले एक अलग डिवाइस पर अनुरोध को स्वीकृत करता है।

प्रतिक्रिया:

स्वीकृति प्रवाह: उपयोगकर्ता verification_uri पर जाता है, user_code दर्ज करता है, और अनुरोध स्वीकृत करता है। इस बीच, डिवाइस device_code के साथ टोकन एंडपॉइंट को poll करता है।

पोलिंग त्रुटि कोड:

curl -X POST https://acme.authagonal.io/connect/deviceauthorization \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=my-cli" \
  -d "scope=openid profile email"

End Session / Logout

GET POST /connect/endsession

वर्तमान उपयोगकर्ता सत्र को साइन आउट करता है, पंजीकृत back-channel या front-channel logout URI वाले हर क्लाइंट को सूचित करता है, और उस सत्र से जुड़े ग्रांट्स रद्द करता है। वर्तमान सत्र से मेल खाने वाले id_token_hint के बिना, उपयोगकर्ता से पहले साइन-आउट की पुष्टि करने के लिए कहा जाता है।

यदि एक वैध post_logout_redirect_uri प्रदान किया जाता है और एक पंजीकृत URI से मेल खाता है, तो उपयोगकर्ता को 302 रीडायरेक्ट प्राप्त होता है। अन्यथा, एक JSON प्रतिक्रिया पुष्टि करती है कि सत्र समाप्त कर दिया गया है।

SCIM 2.0 API संदर्भ

Authagonal स्वचालित उपयोगकर्ता और समूह प्रोविज़निंग के लिए SCIM 2.0 प्रोटोकॉल का समर्थन करता है। Okta, Azure AD, और OneLogin जैसे आइडेंटिटी प्रोवाइडर आपके Authagonal टेनेंट को आपकी कॉर्पोरेट डायरेक्टरी के साथ सिंक में रखने के लिए इस API का उपयोग कर सकते हैं।

Base URL: https://{slug}.authagonal.io/scim/v2

प्रमाणीकरण: सभी अनुरोधों के लिए एक Bearer टोकन आवश्यक है। पोर्टल में SCIM पेज पर एक SCIM टोकन जनरेट करें: वह क्लाइंट चुनें जिसके लिए आपका IdP प्रोविज़न करता है, फिर टोकन बनाएं।

सामान्य हेडर:

List एंडपॉइंट count (डिफ़ॉल्ट 100, अधिकतम 200; 0 केवल कुल संख्या लौटाता है) लेते हैं, और filter पैरामीटर (उदा. userName eq "[email protected]") के माध्यम से फ़िल्टरिंग करते हैं। Users cursor से पेज होते हैं: पिछली प्रतिक्रिया का nextCursor पास करें। Groups या तो startIndex (1-आधारित) या cursor स्वीकार करते हैं।

Users

GET /scim/v2/Users: वैकल्पिक पेजिनेशन और फ़िल्टरिंग के साथ उपयोगकर्ताओं की सूची बनाएँ।

GET /scim/v2/Users/{id}: किसी एक उपयोगकर्ता को उसके Authagonal उपयोगकर्ता ID द्वारा प्राप्त करें।

POST /scim/v2/Users: एक नया उपयोगकर्ता बनाएँ। 201 Created लौटाता है।

PUT /scim/v2/Users/{id}: किसी उपयोगकर्ता संसाधन का पूर्ण प्रतिस्थापन। सभी फ़ील्ड प्रदान किए जाने चाहिए।

PATCH /scim/v2/Users/{id}: SCIM PatchOp का उपयोग करके आंशिक अपडेट।

DELETE /scim/v2/Users/{id}: उपयोगकर्ता को soft delete करता है (खाता निष्क्रिय करता है और सभी टोकन रद्द करता है)। 204 No Content लौटाता है।

curl -X POST https://acme.authagonal.io/scim/v2/Users \
  -H "Authorization: Bearer SCIM_TOKEN" \
  -H "Content-Type: application/scim+json" \
  -d '{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
    "userName": "[email protected]",
    "name": {
      "givenName": "Jane",
      "familyName": "Smith"
    },
    "displayName": "Jane Smith",
    "active": true,
    "externalId": "ext-12345"
  }'

Groups

GET /scim/v2/Groups: वैकल्पिक पेजिनेशन और फ़िल्टरिंग के साथ सभी समूहों की सूची बनाएँ।

GET /scim/v2/Groups/{id}: किसी एक समूह को ID द्वारा प्राप्त करें, उसकी सदस्य सूची सहित।

POST /scim/v2/Groups: एक नया समूह बनाएँ। 201 Created लौटाता है।

PUT /scim/v2/Groups/{id}: किसी समूह संसाधन का पूर्ण प्रतिस्थापन (उसकी सदस्य सूची सहित)।

PATCH /scim/v2/Groups/{id}: आंशिक अपडेट: सदस्य जोड़ें, हटाएँ या बदलें, या displayName और externalId बदलें।

DELETE /scim/v2/Groups/{id}: समूह को hard delete करता है। 204 No Content लौटाता है।

curl -X PATCH https://acme.authagonal.io/scim/v2/Groups/GROUP_ID \
  -H "Authorization: Bearer SCIM_TOKEN" \
  -H "Content-Type: application/scim+json" \
  -d '{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
      {
        "op": "add",
        "path": "members",
        "value": [
          { "value": "USER_ID_1" },
          { "value": "USER_ID_2" }
        ]
      }
    ]
  }'

Portal API (ऑटोमेशन)

Portal API आपके अपने बैकएंड को वह सब कुछ ऑटोमेट करने देता है जो आप पोर्टल में कर सकते हैं — उपयोगकर्ता, क्लाइंट, ग्रुप, रोल, स्कोप, SSO कनेक्शन और सेटिंग्स प्रबंधित करना — एक machine-to-machine क्रेडेंशियल का उपयोग करके। यह वही API है जिसे पोर्टल UI कॉल करता है।

Base URL: https://portal-api.<your-domain>/api/v1. अनुरोध एक Bearer एक्सेस टोकन के साथ प्रमाणित होते हैं; टेनेंट को URL से नहीं, टोकन से लिया जाता है।

एक API क्रेडेंशियल बनाना

पोर्टल में, Clients → Create API credential खोलें, एक एक्सेस स्तर चुनें, और उसे एक नाम दें। Authagonal Portal API के लिए तैयार एक OAuth client_credentials क्लाइंट जनरेट करता है और एक client ID व सीक्रेट लौटाता है।

एक्सेस स्तर

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

अपने टेनेंट के टोकन एंडपॉइंट — https://<your-tenant>.<your-domain>/connect/token — पर क्रेडेंशियल को एक एक्सेस टोकन के बदले प्राप्त करें, फिर टोकन को Portal API पर Bearer header के रूप में भेजें। टोकन एक घंटे के लिए मान्य होते हैं।

# 1. Exchange the credential for an access token (your tenant's token endpoint)
curl -X POST https://acme.authagonal.io/connect/token \
  -d grant_type=client_credentials \
  -d client_id=api-3f2a... \
  -d client_secret=YOUR_CLIENT_SECRET \
  -d scope=tenant:admin

# Response: { "access_token": "ey...", "token_type": "Bearer", "expires_in": 3600 }

# 2. Call the Portal API with the access token
curl https://portal-api.authagonal.io/api/v1/users \
  -H "Authorization: Bearer $ACCESS_TOKEN"

एंडपॉइंट्स

सभी पाथ base URL के सापेक्ष हैं और एक Bearer एक्सेस टोकन की आवश्यकता होती है। प्रत्येक समूह के बगल में दिया गया स्कोप उसके लिए आवश्यक न्यूनतम क्रेडेंशियल एक्सेस स्तर है। पेजिंग resource के अनुसार भिन्न होती है: उपयोगकर्ता और ऑडिट लॉग count (1 से 200, डिफ़ॉल्ट 50) और after लेते हैं, जिसे पिछली प्रतिक्रिया के continuationToken पर सेट किया जाता है; समूह startIndex और count लेते हैं; संगठन limit और cursor लेते हैं; क्लाइंट, भूमिकाएँ और स्कोप हर पंक्ति लौटाते हैं।

GET/api/v1/clientsOAuth क्लाइंट सूचीबद्ध करें।

GET/api/v1/clients/{id}ID द्वारा एक क्लाइंट प्राप्त करें।

POST/api/v1/clientsएक क्लाइंट बनाएँ। क्लाइंट रिकॉर्ड के साथ 201 लौटाता है। सीक्रेट यहाँ नहीं लौटाए जाते: POST /api/v1/clients/{clientId}/secrets से एक सीक्रेट बनाएँ, जो उसे एक बार दिखाता है।

PUT/api/v1/clients/{id}एक क्लाइंट अपडेट करें (redirect URIs, ग्रांट प्रकार, टोकन जीवनकाल, PKCE/PAR आवश्यकताएँ)।

DELETE/api/v1/clients/{id}एक क्लाइंट हटाएँ।

POST/api/v1/clients/api-credentialएक machine-to-machine Portal API क्रेडेंशियल बनाएँ।

GET/api/v1/usersउपयोगकर्ताओं की सूची. count, search (ईमेल या नाम उपसर्ग), किसी एक संगठन पर फ़िल्टर करने के लिए organizationId, और कर्सर पेजिंग के लिए after का समर्थन करता है.

GET/api/v1/users/countटेनेंट के लिए कुल उपयोगकर्ता संख्या।

GET/api/v1/users/stats/mfaMFA एनरोलमेंट आँकड़े।

GET/api/v1/users/{id}एक उपयोगकर्ता प्राप्त करें।

POST/api/v1/users/inviteईमेल द्वारा एक उपयोगकर्ता को आमंत्रित करें। एक लंबित खाता बनाता है और एक लिंक ईमेल करता है जहाँ आमंत्रित व्यक्ति अपना पासवर्ड खुद सेट करता है। वैकल्पिक organizationId और organizationRoles एक संगठन सदस्यता भी जोड़ते हैं।

PUT/api/v1/users/{id}उपयोगकर्ता अपडेट करें (प्रोफ़ाइल, ईमेल, isActive, emailConfirmed, organizationId)। email या emailConfirmed बदलने के लिए tenant:admin आवश्यक है।

DELETE/api/v1/users/{id}एक उपयोगकर्ता हटाएँ।

GET/api/v1/users/{id}/mfaGet a user's enrolled MFA methods.

DELETE/api/v1/users/{id}/mfaReset a user's MFA enrollment. Needs tenant:admin.

GET/api/v1/rolesरोल सूचीबद्ध करें।

POST/api/v1/rolesएक रोल बनाएँ।

DELETE/api/v1/roles/{id}एक रोल हटाएँ।

POST/api/v1/roles/assignकिसी उपयोगकर्ता को एक रोल असाइन करें।

POST/api/v1/roles/unassignकिसी उपयोगकर्ता से एक रोल हटाएँ।

GET/api/v1/groupsग्रुप सूचीबद्ध करें।

GET/api/v1/groups/{id}एक ग्रुप उसके सदस्यों सहित प्राप्त करें।

POST/api/v1/groupsएक ग्रुप बनाएँ।

POST/api/v1/groups/{id}/membersएक ग्रुप में सदस्य जोड़ें।

DELETE/api/v1/groups/{groupId}/members/{userId}एक ग्रुप से एक सदस्य हटाएँ।

DELETE/api/v1/groups/{id}एक ग्रुप हटाएँ।

GET/api/v1/group-role-mappingsग्रुप-से-रोल मैपिंग सूचीबद्ध करें (ग्रुप सदस्यता द्वारा टोकन जारी करते समय ग्रांट किए गए रोल)।

GET/api/v1/scopesAPI स्कोप सूचीबद्ध करें।

POST/api/v1/scopesएक स्कोप बनाएँ।

DELETE/api/v1/scopes/{name}एक स्कोप हटाएँ।

GET/api/v1/saml/connectionsSAML कनेक्शन सूचीबद्ध करें।

POST/api/v1/saml/connectionsएक SAML कनेक्शन बनाएँ।

DELETE/api/v1/saml/connections/{id}एक SAML कनेक्शन हटाएँ।

GET/api/v1/oidc/connectionsOIDC कनेक्शन सूचीबद्ध करें।

POST/api/v1/oidc/connectionsएक OIDC कनेक्शन बनाएँ।

DELETE/api/v1/oidc/connections/{id}एक OIDC कनेक्शन हटाएँ।

GET/api/v1/sso/domainsSSO कनेक्शन पर रूट किए गए डोमेन सूचीबद्ध करें (home-realm डिस्कवरी)।

GET/api/v1/brandingटेनेंट ब्रांडिंग प्राप्त करें (रंग, लोगो, समर्थित भाषाएँ)।

PUT/api/v1/brandingटेनेंट ब्रांडिंग अपडेट करें।

GET/api/v1/settingsटेनेंट सेटिंग्स प्राप्त करें (वेबहुक, सार्वजनिक sign-up, टोकन नीति)।

PUT/api/v1/settingsटेनेंट सेटिंग्स अपडेट करें।

POST/api/v1/settings/webhook-secret/regenerateवेबहुक साइनिंग सीक्रेट रोटेट करें।

POST/api/v1/settings/test-emailवर्तमान ईमेल कॉन्फ़िगरेशन के साथ एक परीक्षण ईमेल भेजें।

GET/api/v1/custom-domainsकस्टम लॉगिन डोमेन और उनकी सत्यापन स्थिति सूचीबद्ध करें।

POST/api/v1/custom-domainsएक कस्टम डोमेन जोड़ें।

POST/api/v1/custom-domains/{domain}/verifyएक कस्टम डोमेन के लिए DNS सत्यापन ट्रिगर करें।

DELETE/api/v1/custom-domains/{domain}एक कस्टम डोमेन हटाएँ।

GET/api/v1/email/domains/{domainId}किसी प्रेषक ईमेल डोमेन के DNS रिकॉर्ड और सत्यापन स्थिति प्राप्त करें।

GET/api/v1/auditटेनेंट ऑडिट लॉग क्वेरी करें।

उदाहरण: एक उपयोगकर्ता को आमंत्रित करें

curl -X POST https://portal-api.authagonal.io/api/v1/users/invite \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "[email protected]",
    "firstName": "Ada",
    "lastName": "Lovelace"
  }'

# 200 OK
# { "userId": "8f3a...", "email": "[email protected]" }

संगठन API

नीचे के सभी routes के लिए TenantAdmin पॉलिसी ज़रूरी है और, जहाँ अलग से न बताया गया हो, ये /api/v1/organizations के अंतर्गत हैं। क्रेडेंशियल बनाने के तरीके के लिए पोर्टल API देखें। दोनों list routes cursor-पेज्ड हैं: limit दें (डिफ़ॉल्ट 50, 1 से 200) और पिछला nextCursor cursor के रूप में दें। वे { items, nextCursor } लौटाते हैं, और गलत cursor 400 invalid_cursor है। संगठन ऑब्जेक्ट में केवल-पढ़ने योग्य domains सूची होती है।

लॉगिन स्क्रीन

ये वे होस्टेड स्क्रीन हैं जो आपके अंतिम उपयोगकर्ता आपके टेनेंट के auth server पर देखते हैं। Authagonal हर स्क्रीन उपयोग के लिए तैयार भेजता है, इसलिए आपको कोई UI बनाए बिना एक संपूर्ण, सुरक्षित sign-in अनुभव मिलता है। यह पेज प्रत्येक स्क्रीन के बारे में बताता है और दिखाता है कि कौन-सी पोर्टल सेटिंग्स इसे नियंत्रित करती हैं।

साइन इन

• ईमेल-पहले, दो-चरण प्रवाह: उपयोगकर्ता अपना ईमेल दर्ज करता है और Continue पर क्लिक करता है, फिर पासवर्ड फ़ील्ड दिखाई देता है।
• "Continue with {provider}" single sign-on बटन SSO कनेक्शन मौजूद होने पर स्वतः दिखाई देते हैं।
• Forgot password और create account लिंक, जिनमें से प्रत्येक को दिखाया या छिपाया जा सकता है।
• स्वचालित sign-in प्रयासों को रोकने के लिए वैकल्पिक Cloudflare Turnstile captcha।

पोर्टल admin में नियंत्रित

• Branding लोगो, रंग, ऐप नाम, सपोर्ट ईमेल और कस्टम CSS सेट करती है।
• forgot-password और registration लिंक दिखाएँ या छिपाएँ (Branding)।
• SSO connections सोशल sign-in बटन जोड़ते हैं (SSO पेज)।
• सत्र जीवनकाल और लॉकआउट थ्रेशोल्ड (सेटिंग्स → सेशन)।

रजिस्ट्रेशन

• पहला और अंतिम नाम (वैकल्पिक), ईमेल, और एक पासवर्ड एकत्र करता है।
• उपयोगकर्ता के टाइप करते ही एक लाइव password-policy चेकलिस्ट अपडेट होती है, इसलिए सबमिट करने से पहले आवश्यकताएँ स्पष्ट होती हैं।
• वैकल्पिक Cloudflare Turnstile captcha।
• उन उपयोगकर्ताओं के लिए एक "Sign in" लिंक जिनके पास पहले से एक खाता है।

पोर्टल admin में नियंत्रित

• registration लिंक दिखाएँ या छिपाएँ (Branding)। पंजीकरण को पूरी तरह बंद करने के लिए, सार्वजनिक साइन-अप की अनुमति दें बंद करें (सेटिंग्स → सेशन)।
• आपके टेनेंट की password policy चेकलिस्ट को संचालित करती है।
• Branding पूरी स्क्रीन को स्टाइल करती है।

पासवर्ड भूल गए

• उपयोगकर्ता अपना ईमेल दर्ज करता है, फिर एक तटस्थ "check your email" पुष्टि देखता है।
• स्क्रीन कभी प्रकट नहीं करती कि कोई खाता मौजूद है या नहीं, जो अकाउंट एन्युमरेशन जाँच को विफल करती है।
• एक "Back to sign in" लिंक उपयोगकर्ता को sign-in स्क्रीन पर लौटाता है।

पोर्टल admin में नियंत्रित

• forgot-password लिंक दिखाएँ या छिपाएँ (Branding)।
• आपके टेनेंट की email delivery रीसेट संदेश भेजती है।
• Branding पूरी स्क्रीन को स्टाइल करती है।

पासवर्ड रीसेट करें

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

पोर्टल admin में नियंत्रित

• आपके टेनेंट की password policy चेकलिस्ट को संचालित करती है।
• Branding पूरी स्क्रीन को स्टाइल करती है।

MFA चैलेंज

• authenticator app, passkey, और recovery code के बीच एक method switcher।
• एक 6-अंकीय TOTP फ़ील्ड जो सभी अंक दर्ज होते ही स्वतः सबमिट हो जाता है।
• उन उपयोगकर्ताओं के लिए recovery-code प्रविष्टि जिन्होंने अपने authenticator तक पहुँच खो दी है।
• हार्डवेयर-समर्थित सत्यापन के लिए एक passkey बटन।

पोर्टल admin में नियंत्रित

• MFA policy प्रति एप्लिकेशन सेट की जाती है (Clients → Security)।
• किसी भी enrolled factor वाले उपयोगकर्ता को नीति की परवाह किए बिना हमेशा चैलेंज किया जाता है।

MFA सेटअप

• enrolled methods की स्थिति दिखाता है ताकि उपयोगकर्ता जान सके कि क्या पहले से कॉन्फ़िगर है।
• QR code के माध्यम से Authenticator सेटअप, एक मैनुअल key फ़ॉलबैक, और एक पुष्टि चरण।
• हार्डवेयर-समर्थित प्रमाणीकरण के लिए Passkey एनरोलमेंट।
• खाता रिकवरी के लिए Recovery-code जनरेशन।
• जब MFA आवश्यक के बजाय स्वयं-सेवा हो तो एक वैकल्पिक skip।

पोर्टल admin में नियंत्रित

• MFA policy प्रति एप्लिकेशन सेट की जाती है; Required लॉगिन पर सेटअप को बाध्य करता है (Clients → Security)।
• Branding पूरी स्क्रीन को स्टाइल करती है।

डिवाइस प्राधिकरण

• डिवाइस पर दिखाए गए कोड के लिए एक केंद्रित user-code प्रविष्टि फ़ील्ड।
• डिवाइस को अधिकृत करने के लिए एक approve चरण।
• जब उपयोगकर्ता अभी प्रमाणित नहीं हुआ है तो एक sign-in interstitial।
• डिवाइस अधिकृत होने के बाद एक approved पुष्टि।

पोर्टल admin में नियंत्रित

• एप्लिकेशन पर device-code grant सक्षम करें (क्लाइंट → स्कोप और ग्रांट)।
• device-code lifetime सेट करें (Clients → Tokens)।

सहमति

• अनुरोध करने वाले क्लाइंट का लोगो और नाम दिखाता है।
• प्रत्येक अनुमति के लिए मित्रवत, मानव-पठनीय लेबल के साथ एक प्रति-स्कोप सूची।
• एक्सेस ग्रांट या अस्वीकार करने के लिए Allow और Deny बटन।
• एक consent hint footer जो समझाता है कि निर्णय का क्या अर्थ है।

पोर्टल admin में नियंत्रित

• प्रति एप्लिकेशन सहमति आवश्यक करें चालू करें (क्लाइंट → सामान्य)।
• लोगो, नाम और URL एप्लिकेशन के अपने मेटाडेटा से आते हैं।
• Branding सहमति कार्ड को रंगती है।

कनेक्टेड ऐप्स (ग्रांट्स)

• उपयोगकर्ता द्वारा अधिकृत प्रत्येक ऐप को उसके नाम, स्कोप और ग्रांट की तारीख के साथ सूचीबद्ध करता है।
• किसी ऐप का एक्सेस Revoke करें, इसके प्रभावी होने से पहले एक पुष्टि चरण के साथ।
• जब उपयोगकर्ता ने किसी ऐप को अधिकृत नहीं किया हो तो एक मित्रवत empty state।

पोर्टल admin में नियंत्रित

• सूची consent-required एप्लिकेशन द्वारा भरी जाती है।
• Branding पूरी स्क्रीन को स्टाइल करती है।

खाता

/login/account पर एक होस्टेड स्वयं-सेवा खाता पेज जहाँ साइन-इन उपयोगकर्ता बिना किसी पोर्टल एक्सेस की आवश्यकता के अपनी प्रोफ़ाइल और पसंदीदा भाषा प्रबंधित करते हैं।

• पहला और अंतिम नाम, कंपनी और फ़ोन संपादित करें; ईमेल पता केवल-पढ़ने के लिए दिखाया जाता है।
• समर्थित locales में से एक पसंदीदा भाषा चुनें; UI तुरंत चयन का पूर्वावलोकन दिखाता है और सहेजने पर इसे बनाए रखता है।
• सहेजी गई भाषा उपयोगकर्ता के होस्टेड UI और उन्हें प्राप्त होने वाले transactional ईमेल की भाषा को संचालित करती है।

पोर्टल admin में नियंत्रित

• Branding पूरी स्क्रीन को स्टाइल करती है।
• वही पसंदीदा भाषा पोर्टल के Users पेज पर एक admin द्वारा संपादन योग्य है।

प्रमाणीकरण प्रवाह

प्रमाणीकरण प्रवाह यह कवर करते हैं कि अंतिम उपयोगकर्ता आपके Authagonal टेनेंट के साथ कैसे इंटरैक्ट करते हैं — लॉगिन करना, रजिस्टर करना, पासवर्ड रीसेट करना और MFA सेट अप करना। इन एंडपॉइंट्स का उपयोग होस्टेड लॉगिन पेज द्वारा किया जाता है और यदि आप एक कस्टम लॉगिन UI बना रहे हैं तो इन्हें सीधे कॉल किया जा सकता है।

लॉगिन

POST /api/auth/login

ईमेल और पासवर्ड के साथ एक उपयोगकर्ता को प्रमाणित करता है। सफलता पर, एक सत्र कुकी साइन करता है और उपयोगकर्ता प्रोफ़ाइल लौटाता है। यदि MFA कॉन्फ़िगर है, तो प्रतिक्रिया इंगित करती है कि सत्र पूरी तरह स्थापित होने से पहले एक second factor आवश्यक है।

अनुरोध बॉडी:

{
  "email": "[email protected]",
  "password": "correct-horse-battery-staple"
}

सफलता प्रतिक्रिया:

MFA required प्रतिक्रिया: जब उपयोगकर्ता के पास MFA enrolled होता है, तो प्रतिक्रिया में mfaRequired: true के साथ एक challengeId और उपलब्ध MFA विधियों को सूचीबद्ध करने वाला एक methods array शामिल होता है।

MFA setup required प्रतिक्रिया: जब एप्लिकेशन की MFA policy आवश्यक (Required) होती है लेकिन उपयोगकर्ता ने अभी तक enroll नहीं किया है, तो प्रतिक्रिया में enrollment प्रवाह के लिए एक setupToken के साथ mfaSetupRequired: true शामिल होता है।

त्रुटि प्रतिक्रियाएँ:

SSO check: यदि उपयोगकर्ता के ईमेल डोमेन में एक SSO कनेक्शन कॉन्फ़िगर है, तो login एंडपॉइंट एक redirectUrl के साथ sso_required लौटाता है। क्लाइंट को उपयोगकर्ता को SSO प्रदाता पर रीडायरेक्ट करना चाहिए।

Account lockout: maxFailedAttempts लगातार विफल लॉगिन प्रयासों के बाद, खाता lockoutDurationMinutes के लिए लॉक हो जाता है। दोनों मान टेनेंट सेटिंग्स में कॉन्फ़िगर करने योग्य हैं।

रजिस्ट्रेशन

POST /api/auth/register

एक नया उपयोगकर्ता खाता बनाता है और एक सत्यापन ईमेल भेजता है। जब तक <strong>Require verified email to sign in</strong> (सेटिंग्स &rarr; सेशन) चालू है, जो कि डिफ़ॉल्ट है, उपयोगकर्ता को लॉगिन करने से पहले अपना ईमेल सत्यापित करना होगा।

अनुरोध बॉडी:

{
  "email": "[email protected]",
  "password": "a-strong-password-here",
  "firstName": "Jane",
  "lastName": "Smith"
}

सफलता: नए खाते के userId के साथ 201 Created। पहले से लिए गए ईमेल के साथ रजिस्टर करने पर भी 201 लौटता है: हम कभी प्रकट नहीं करते कि कोई ईमेल मौजूद है या नहीं (अकाउंट एन्युमरेशन रोकने के लिए), और इसके बजाय वास्तविक खाताधारक को ईमेल द्वारा सूचित करते हैं।

त्रुटि प्रतिक्रियाएँ:

पासवर्ड रीसेट

POST /api/auth/forgot-password

एक पासवर्ड रीसेट ईमेल का अनुरोध करता है। ईमेल एन्युमरेशन रोकने के लिए, एंडपॉइंट हमेशा एक सफलता प्रतिक्रिया लौटाता है, चाहे ईमेल मौजूद हो या नहीं।

{
  "email": "[email protected]"
}

POST /api/auth/reset-password

ईमेल लिंक से टोकन का उपयोग करके उपयोगकर्ता का पासवर्ड रीसेट करता है।

{
  "token": "RESET_TOKEN_FROM_EMAIL",
  "newPassword": "new-strong-password"
}

एक सफल पासवर्ड रीसेट के दुष्प्रभाव:

• विफल लॉगिन प्रयास काउंटर शून्य पर रीसेट हो जाता है
• सभी मौजूदा रिफ़्रेश टोकन्स रद्द कर दिए जाते हैं
• एक नया security stamp जनरेट होता है (सभी मौजूदा सत्र को अमान्य करते हुए)

MFA सेटअप और सत्यापन

Authagonal तीन MFA विधियों का समर्थन करता है: TOTP (authenticator apps), WebAuthn (security keys और biometrics), और एकल-उपयोग recovery codes।

TOTP सेटअप

POST /api/auth/mfa/totp/setup: एक <code>setupToken</code>, एक QR code data URI और एक मैनुअल entry key लौटाता है। उपयोगकर्ता अपने authenticator app (Google Authenticator, Authy, 1Password, आदि) से QR code स्कैन करता है, फिर enrollment की पुष्टि करता है।

POST /api/auth/mfa/totp/confirm: setup से मिले <code>setupToken</code> को authenticator app के एक 6-अंकीय कोड के साथ भेजकर TOTP enrollment की पुष्टि करता है।

{
  "setupToken": "SETUP_TOKEN_FROM_SETUP_RESPONSE",
  "code": "123456"
}

WebAuthn सेटअप

POST /api/auth/mfa/webauthn/setup — WebAuthn API के लिए क्रेडेंशियल creation options लौटाता है। ब्राउज़र इन options के साथ navigator.credentials.create() कॉल करता है।

POST /api/auth/mfa/webauthn/confirm: ब्राउज़र से attestation प्रतिक्रिया सबमिट करके WebAuthn enrollment की पुष्टि करता है।

Recovery Codes

POST /api/auth/mfa/recovery/generate: 10 एकल-उपयोग 10-वर्ण recovery codes (फ़ॉर्मैट <code>XXXXX-XXXXX</code>) जनरेट करता है। प्रत्येक कोड MFA को बायपास करने के लिए ठीक एक बार उपयोग किया जा सकता है। पहले एक authenticator app या passkey नामांकित होना चाहिए।

MFA सत्यापन

POST /api/auth/mfa/verify: एक सफल पासवर्ड लॉगिन के बाद MFA चैलेंज पूरा करता है।

MFA स्थिति

GET /api/auth/mfa/status: उपयोगकर्ता की वर्तमान में enrolled MFA विधियाँ लौटाता है।

SSO लॉगिन प्रवाह

Authagonal SAML 2.0 और OIDC-आधारित दोनों SSO कनेक्शन का समर्थन करता है। डोमेन-आधारित रूटिंग स्वतः पता लगाता है कि उपयोगकर्ता के ईमेल पते के आधार पर किस SSO प्रदाता का उपयोग करना है।

SSO Check

GET /api/auth/[email protected]

SAML प्रवाह

उपयोगकर्ता को GET /saml/{connectionId}/login पर रीडायरेक्ट किया जाता है जो आइडेंटिटी प्रोवाइडर को एक SAML AuthnRequest भेजता है। IdP उपयोगकर्ता को प्रमाणित करता है और एक SAML प्रतिक्रिया वापस Assertion Consumer Service (ACS) एंडपॉइंट पर पोस्ट करता है। Authagonal एसर्शन को मान्य करता है, उपयोगकर्ता बनाता या अपडेट करता है, और एक सत्र कुकी साइन करता है।

आपके IdP को कॉन्फ़िगर करने के लिए SAML मेटाडेटा GET /saml/{connectionId}/metadata पर उपलब्ध है।

OIDC प्रवाह

उपयोगकर्ता को GET /oidc/{connectionId}/login पर रीडायरेक्ट किया जाता है जो PKCE के साथ अपस्ट्रीम आइडेंटिटी प्रोवाइडर पर रीडायरेक्ट करता है। उपयोगकर्ता के प्रमाणित होने के बाद, /oidc/callback पर callback authorization code का आदान-प्रदान करता है, ID टोकन को मान्य करता है, और उपयोगकर्ता बनाता या अपडेट करता है।

JIT Provisioning: SAML और OIDC दोनों प्रवाह just-in-time प्रोविज़निंग का समर्थन करते हैं, जो हर कनेक्शन पर डिफ़ॉल्ट रूप से बंद होती है (JIT प्रोविज़निंग चालू करें)। जब यह चालू हो और उपयोगकर्ता टेनेंट में पहले से मौजूद न हो, तो उन्हें आइडेंटिटी प्रोवाइडर के क्लेम्स से स्वतः बनाया जाता है। यदि वे मौजूद हैं, तो उनकी प्रोफ़ाइल विशेषताएँ प्रदाता से नवीनतम मानों से मेल खाने के लिए अपडेट की जाती हैं।

Backend-for-Frontend (BFF)

एक BFF, OAuth टोकन को ब्राउज़र से पूरी तरह बाहर रखता है। आपका single-page app एक httpOnly सेशन कुकी के अलावा कुछ नहीं रखता, और आपके अपने बैकएंड पर मौजूद एक confidential client, OpenID Connect फ़्लो चलाता है तथा टोकन सर्वर साइड पर रखता है।

जो कुछ भी एक single-page app पढ़ सकता है, उसे cross-site scripting चुरा सकता है, और इसमें मेमोरी में रखा एक्सेस टोकन तथा localStorage में रखा रिफ़्रेश टोकन, दोनों शामिल हैं। ब्राउज़र में टोकन रखने से उनका जीवनकाल भी सीमित करना पड़ता है, क्योंकि स्क्रिप्ट्स की पहुँच में मौजूद लंबे जीवनकाल वाला रिफ़्रेश टोकन एक स्थायी जोखिम है। IETF की OAuth 2.0 for Browser-Based Apps best current practice ठीक इसी वजह से यह पैटर्न सुझाती है।

बदले में आपको एक ऐसा सेशन मिलता है जो पेज रीलोड के बाद भी बना रहता है और कहीं कोई टोकन दिखाई नहीं देता, रिफ़्रेश आपके लिए सर्वर साइड पर संभाला जाता है, back-channel logout के ज़रिए तुरंत revocation मिलता है, और एक प्रमाणीकृत प्रॉक्सी मिलती है ताकि आपकी API को कभी ऐसा टोकन पार्स न करना पड़े जिससे ब्राउज़र छेड़छाड़ कर सकता था।

क्लाइंट बनाएँ

पोर्टल में क्लाइंट खोलें और BFF ऐप बनाएँ चुनें। वह base URL दें जिससे आपका ऐप सर्व होता है, उदाहरण के लिए https://app.acme.com, और Authagonal आपके लिए एक सही ढंग से कॉन्फ़िगर किया गया confidential client पंजीकृत कर देता है, बजाय इसके कि उसे जोड़ने का काम आप पर छोड़ दे:

इसे अपने बैकएंड में जोड़ें

दो रनटाइम समर्थित हैं और दोनों एक ही core protocol साझा करते हैं: .NET के लिए Authagonal.Bff और Node के लिए @authagonal/bff, जिसमें Express तथा Next.js के लिए अडैप्टर भी शामिल हैं। इनमें से किसी को भी उन मानों की ओर इंगित करें जो पोर्टल ने अभी आपको दिए हैं। Node पैकेज को आपका अपना एक cookieSecret भी चाहिए, जिसका उपयोग वह अपनी कुकीज़ को एन्क्रिप्ट करने के लिए करता है।

// dotnet add package Authagonal.Bff
builder.Services.AddAuthagonalBff(o =>
{
    o.Authority    = "https://acme.authagonal.io";       // your tenant auth host
    o.ClientId     = builder.Configuration["Bff:ClientId"]!;
    o.ClientSecret = builder.Configuration["Bff:ClientSecret"]!;
    o.Scope        = ["openid", "profile", "email", "offline_access"];
    o.PostLogoutRedirectUri = "https://app.acme.com/";
});

// Trust X-Forwarded-Proto from your ingress. With no options, UseForwardedHeaders() changes nothing.
builder.Services.Configure<ForwardedHeadersOptions>(o =>
{
    o.ForwardedHeaders = ForwardedHeaders.XForwardedProto;
    o.KnownNetworks.Clear();
    o.KnownProxies.Clear();
});

var app = builder.Build();

app.UseForwardedHeaders();   // required behind a proxy or ingress, see the note below
app.MapAuthagonalBff();
app.MapFallbackToFile("index.html");   // your SPA
app.Run();

// npm install @authagonal/bff
import express from 'express';
import { authagonalBff } from '@authagonal/bff/express';

const app = express();

app.use(authagonalBff({
  authority: 'https://acme.authagonal.io',
  clientId: process.env.BFF_CLIENT_ID,
  clientSecret: process.env.BFF_CLIENT_SECRET,
  cookieSecret: process.env.BFF_COOKIE_SECRET,   // encrypts the session and login cookies
  scope: ['openid', 'profile', 'email', 'offline_access'],
  postLogoutRedirectUri: 'https://app.acme.com/',
}));

app.listen(8080);

एंडपॉइंट्स

डिफ़ॉल्ट रूप से /bff के अंतर्गत माउंट होते हैं। इन्हें आपके SPA के समान ओरिजिन से सर्व किया जाना चाहिए, क्योंकि सेशन कुकी httpOnly और same-origin है: इन्हें किसी अलग API डोमेन के बजाय उसी hostname के पीछे रखें।

ब्राउज़र से

हर non-navigation अनुरोध में एक स्थिर anti-forgery हेडर होना चाहिए। यह कुकी के SameSite एट्रिब्यूट के साथ मिलकर cross-site request forgery से बचाव करता है: कोई cross-site form post कस्टम हेडर सेट नहीं कर सकता, इसलिए उसके बिना आया अनुरोध अस्वीकार कर दिया जाता है।

const me = await fetch('/bff/user', {
  headers: { 'X-Authagonal-Bff': '1' },
}).then(r => r.json());

if (!me.isAuthenticated) {
  // Navigate, do not fetch: this is a redirect to your identity provider.
  window.location.href = '/bff/login?returnUrl=' + encodeURIComponent(location.pathname);
}

लॉगिन और लॉगआउट नेविगेट करके करें, fetch करके नहीं: location.href = '/bff/login'। वे रूट आपके आइडेंटिटी प्रोवाइडर पर रीडायरेक्ट के साथ जवाब देते हैं, और रीडायरेक्ट की ऐसी श्रृंखला को fetch उपयोगी ढंग से फ़ॉलो नहीं कर सकता।

अपनी API को कॉल करना

BFF आपकी API को अपने base path के अंतर्गत फ़ॉरवर्ड कर सकता है और रास्ते में सेशन का एक्सेस टोकन जोड़ सकता है। ब्राउज़र एक कुकी भेजता है, आपकी API को एक bearer टोकन मिलता है जिसे वह सामान्य ढंग से मान्य करती है, और उस टोकन के बारे में कुछ भी पेज को दिखाई नहीं देता और न ही पेज उसे गढ़ सकता है। एक upstream रजिस्टर करें, और /bff/api/** पर आने वाले अनुरोध प्रमाणीकृत होकर उस तक पहुँचते हैं। सूची खाली छोड़ दें, तो प्रॉक्सी पूरी तरह अक्षम रहती है।

o.Upstreams.Add(new BffUpstream
{
    Prefix        = "/orders",                        // matches /bff/api/orders/**
    TargetBaseUrl = "https://api.internal.acme.com",
    StripPrefix   = false,                            // keep /orders in the forwarded path
});

WebSockets

एक WebSocket handshake कोई कस्टम हेडर या bearer टोकन नहीं ले जा सकता, इसलिए न anti-forgery हेडर काम आता है और न प्रॉक्सी। tickets सक्षम करें, और फिर SPA GET /bff/ws-ticket कॉल कर सकता है, अल्पकालिक single-use ticket को connect URL पर रख सकता है, और आपकी API उसे भुना सकती है। हर connect से ठीक पहले एक ticket बनाएँ: यह पहले ही उपयोग पर हट जाता है और कुछ सेकंड में समाप्त हो जाता है।

ब्राउज़र को टोकन सौंपना, वह भी जानबूझकर

BFF का पूरा मक़सद ही यह है कि ब्राउज़र कोई टोकन न रखे, इसलिए यह opt-in है और बहुत सीमित है। यह उस एक स्थिति के लिए मौजूद है जहाँ कुकी मॉडल नहीं पहुँच सकता: किसी दूसरे ओरिजिन पर मौजूद एक resource server, जैसे कोई ऐप जिसे आप iframe में एम्बेड करते हैं, जिसे bearer के साथ कॉल करना ज़रूरी हो। सक्षम होने पर, GET /bff/token?resource=… एक exchanged टोकन लौटाता है: सेशन का टोकन, जिसे अनुमति-सूची में शामिल एक ही resource तक सीमित किया गया है और किसी भी अनुमति-सूची वाले context parameter से बाँधा गया है। ब्राउज़र सेशन का अपना टोकन कभी नहीं देखता, और उसे जो मिलता है वह अल्पकालिक तथा एकल-audience वाला होता है। अनुमति-सूची से बाहर के resource का नाम लेने वाला अनुरोध अस्वीकार कर दिया जाता है, और यही इसे सर्वसामान्य टोकन-मिंट बनने से रोकता है।

एक ही BFF से कई टेनेंट्स को सर्व करना

एक tenant query parameter सेट करें और फिर एक ही deployment कई टेनेंट्स को सर्व करता है: /bff/login?slug=acme टेनेंट चुनता है, एक resolver उस टेनेंट का authority और client credentials देता है, key correlation कुकी के साथ सेशन तक पहुँचती है, और back-channel logout टेनेंट को टोकन के issuer से हल करता है। डिफ़ॉल्ट resolver, single-tenant व्यवहार को byte के स्तर तक अपरिवर्तित रखता है, इसलिए जब तक आप इसका उपयोग नहीं करते, इसकी कोई क़ीमत नहीं चुकानी पड़ती।

एक से अधिक इंस्टेंस चलाना

सेशन IBffSessionStore के पीछे रहते हैं, जो डिफ़ॉल्ट रूप से एक in-process कैश होता है। एक ही इंस्टेंस के लिए यह ठीक है और कई इंस्टेंस के लिए ग़लत: जिस उपयोगकर्ता का अगला अनुरोध किसी दूसरे रेप्लिका पर पहुँचता है, वह साइन आउट हो जाता है। BFF जोड़ने से पहले एक साझा स्टोर रजिस्टर करें, उदाहरण के लिए IDistributedCache के माध्यम से Redis।

जानने लायक विकल्प

पूरा सेट, .NET वाली वर्तनी में। Node पैकेज core विकल्पों को camelCase में लेता है, इसलिए BasePath वहाँ basePath है और SessionLifetime वहाँ sessionLifetimeSeconds है। PersistentCookie, CorrelationLifetime (Node में 15 मिनट पर स्थिर) और LoginPassthroughParams केवल .NET में हैं।

अपना पोर्टल किसी AI असिस्टेंट से चलाएँ

किसी AI असिस्टेंट को अपने टेनेंट से जोड़ें और उससे वही काम कराएँ जो आप वरना खुद क्लिक करके करते: ऐसा उपयोगकर्ता ढूँढ़ना जो साइन इन नहीं कर पा रहा, यह जाँचना कि उसके पास अब भी दूसरा फ़ैक्टर है या नहीं, किसी को आमंत्रित करना, यह देखना कि admin भूमिका किसके पास है।

यह एक सामान्य OAuth कनेक्शन है, API key नहीं। हर व्यक्ति खुद के रूप में साइन इन करता है और एक्सेस को स्वीकृति देता है, इसलिए असिस्टेंट ठीक वही कर सकता है जो वह व्यक्ति पोर्टल में कर सकता है, उससे ज़्यादा कुछ नहीं। ऐसा कुछ भी नया नहीं बनता जो लीक हो सके, और किसी एक असिस्टेंट को रद्द करने से बाकी सब अछूते रहते हैं।

इसे चालू करना

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

https://portal-api.authagonal.io/api/v1/mcp/{your-tenant}

असिस्टेंट क्या कर सकता है

ठीक वही जो उसे जोड़ने वाला व्यक्ति कर सकता है, और यह हर कॉल पर उसी के अपने टोकन के आधार पर तय होता है। tenant:support एजेंट को डायग्नोस्टिक और रोज़मर्रा के टूल मिलते हैं; admin टूल उससे केवल छिपाए नहीं जाते, सीधे नाम लेने पर भी मना कर दिए जाते हैं। पोर्टल के भीतर जो कुछ भी प्रतिबंधित है वह प्रतिबंधित ही रहता है: किसी उपयोगकर्ता का ईमेल पता बदलने के लिए वहाँ admin भूमिका चाहिए, और यहाँ भी वही चाहिए।

चूँकि यह एक सामान्य ग्रांट है, आप इसे सामान्य तरीके से ही प्रबंधित करते हैं: अपने खाते के अधिकृत ऐप्स पेज पर असिस्टेंट को हटाएँ और वह अब refresh नहीं कर सकता, इसलिए उसका वर्तमान access टोकन समाप्त होने पर वह काम करना बंद कर देता है। असिस्टेंट द्वारा किया गया हर बदलाव आपके ऑडिट लॉग में उसी व्यक्ति के नाम से दर्ज होता है जिसकी ओर से उसने काम किया, इसलिए ट्रेल वही है जिसे आप पहले से पढ़ते आए हैं।

टूल

इस रिलीज़ में तैंतीस। कौन-से चालू करने हैं यह आपका AI क्लाइंट तय करता है, इसलिए यदि आप असिस्टेंट से सिर्फ़ पढ़ने का काम कराना चाहते हैं तो उसे केवल पढ़ने वाले टूल दे सकते हैं।

अभी क्या शामिल नहीं है

उपयोगकर्ताओं को हटाना, SSO कनेक्शन बनाना या संपादित करना, बिलिंग, बैकअप और client सीक्रेट्स, ये सब इस रिलीज़ में नहीं हैं। हटाने का काम आपकी डेटा-मिटाने की कतार के साथ का है, उसके बगल में नहीं; SSO कनेक्शन इतना बड़ा है कि एक गलत संपादन पूरे कार्यबल को बाहर कर देता है, इसलिए वे फ़िलहाल केवल पढ़ने के लिए हैं; और जो टूल client सीक्रेट लौटाए वह उसे असिस्टेंट के ट्रांसक्रिप्ट में डाल देगा। हमें बताइए कि इनमें से आपको कौन-सा चाहिए और किस क्रम में।

MCP सर्वर प्रमाणीकरण

यदि आप कोई Model Context Protocol सर्वर एक्सपोज़ करते हैं, तो Authagonal उसके पीछे ऑथराइज़ेशन सर्वर बन सकता है। एक AI असिस्टेंट कनेक्ट करता है, उसके पीछे मौजूद व्यक्ति साइन इन करके एक्सेस देता है, और आपके सर्वर को एक सामान्य bearer टोकन मिलता है जिसे आप किसी भी दूसरे API की तरह वैलिडेट करते हैं।

इसका विकल्प है असिस्टेंट के कॉन्फ़िगरेशन में चिपकाई गई एक API key, जो ऐसा क्रेडेंशियल है जिसके पीछे कोई उपयोगकर्ता नहीं होता, जिसकी कोई समाप्ति नहीं होती, जिसमें कोई सहमति चरण नहीं होता, और जिसमें सबके लिए रोटेट किए बिना किसी एक कनेक्टर को रद्द करने का कोई तरीका नहीं होता। इसे OAuth के रूप में करने का मतलब है कि ग्रांट किसी नामित व्यक्ति का होता है, आपके ऑडिट लॉग में दिखता है, और बाकी किसी चीज़ को छुए बिना पोर्टल से रद्द किया जा सकता है।

कनेक्शन कैसे बनता है

पूरा आदान-प्रदान डिस्कवरी से चलता है, इसलिए स्पेसिफिकेशन का पालन करने वाले क्लाइंट को आपके सर्वर के URL के अलावा कुछ भी कॉन्फ़िगर करने की ज़रूरत नहीं होती।

उस क्रम में कुछ भी Authagonal-विशिष्ट नहीं है: यह MCP authorization स्पेसिफिकेशन है, जो resource मेटाडेटा के लिए RFC 9728, ऑथराइज़ेशन सर्वर की डिस्कवरी के लिए RFC 8414, पंजीकरण के लिए RFC 7591 और resource का नाम देने के लिए RFC 8707 पर बना है। स्पेसिफिकेशन का पालन करने वाला कनेक्टर हमें विशेष मामला बनाए बिना काम करता है।

कनेक्टर्स को खुद को पंजीकृत करने दें

जिस कनेक्टर से आपका कभी सामना ही नहीं हुआ, वह हाथ से बनाए गए किसी क्लाइंट का उपयोग नहीं कर सकता, इसलिए वह रनटाइम पर एक क्लाइंट पंजीकृत करता है। यह डिफ़ॉल्ट रूप से बंद है। Settings में dynamic client registration चालू करें और पंजीकरण एंडपॉइंट आपके डिस्कवरी दस्तावेज़ में दिखने लगता है; इसे बंद छोड़ दें तो एंडपॉइंट का प्रचार नहीं होता और वह मना कर देता है। इसे सक्षम करने से पंजीकरण केवल आपके टेनेंट के लिए खुलता है, किसी और के लिए कभी नहीं।

आपका MCP सर्वर क्या लागू करता है

दो छोटी चीज़ें, और उसके बाद यह एक सामान्य resource server है। पहला, protected-resource मेटाडेटा प्रकाशित करें जो आपके टेनेंट को ऑथराइज़ेशन सर्वर के रूप में नाम देता हो। इसे well-known पथ पर सर्व करें और, यदि आपका MCP एंडपॉइंट किसी सब-पाथ पर है, तो पाथ-सफ़िक्स वाले रूप में भी सर्व करें, क्योंकि क्लाइंट दोनों आज़माते हैं।

GET https://your-app.example/.well-known/oauth-protected-resource

{
  "resource": "https://your-app.example/mcp",
  "authorization_servers": ["https://acme.authagonal.io"],
  "bearer_methods_supported": ["header"],
  "scopes_supported": ["mcp"]
}

दूसरा, जब कोई कॉल बिना वैध टोकन के आए, तो 401 के साथ उत्तर दें और उसमें एक WWW-Authenticate हेडर रखें जो उसी मेटाडेटा की ओर इशारा करता हो। यही हेडर इनकार को कनेक्शन में बदलता है: इसके बिना क्लाइंट के पास यह पता लगाने का कोई तरीका नहीं होता कि प्रमाणीकरण कहाँ करना है, और वह बस विफल हो जाता है।

// Validate the connector's token like any other resource server.
builder.Services.AddAuthentication().AddJwtBearer("McpBearer", o =>
{
    o.Authority = "https://acme.authagonal.io";              // your tenant
    o.TokenValidationParameters.ValidAudience = "https://your-app.example/mcp";
});

// Unauthenticated? Point the connector at the metadata rather than just refusing.
http.Response.Headers.WWWAuthenticate =
    "Bearer resource_metadata=\"https://your-app.example/.well-known/oauth-protected-resource\"";
return Results.Unauthorized();

स्कोप, प्लान और रद्दीकरण

अपने Scopes पेज पर बिना भूमिका प्रतिबंधों के mcp नाम का एक स्कोप परिभाषित करें, और स्व-पंजीकरण करने वाला कनेक्टर उसका अनुरोध कर सकता है; वह सहमति स्क्रीन पर दिखता है ताकि उपयोगकर्ता देख सके कि वह किसे स्वीकृति दे रहा है। टोकन का subject वह व्यक्ति है जिसने साइन इन किया, इसलिए आपका सर्वर हर कनेक्टर को एक जैसा मानने के बजाय यह तय कर सकता है कि यह विशेष व्यक्ति क्या कर सकता है। स्व-पंजीकृत कनेक्टर roles या groups स्कोप का अनुरोध नहीं कर सकता, इसलिए उन्हें टोकन में अपेक्षित करने के बजाय अपनी ओर से देखें।

चूँकि यह एक सामान्य OAuth ग्रांट है, रद्दीकरण भी सामान्य तरीके से काम करता है: उपयोगकर्ता अपने खाते के अधिकृत ऐप्स पेज पर कनेक्टर को हटाता है, जिससे उसका ग्रांट और refresh टोकन हट जाता है और वह नवीनीकरण नहीं कर सकता। उसके मौजूदा access टोकन /connect/introspect और /connect/userinfo द्वारा तुरंत अस्वीकार कर दिए जाते हैं; जो सर्वर JWT को केवल स्थानीय रूप से सत्यापित करता है, वह उसे समाप्त होने तक स्वीकार करता है। ऑडिट लॉग हर साइन-इन को उस क्लाइंट के साथ दर्ज करता है जिसके लिए वह था।

एक कस्टम लॉगिन UI बनाएँ

Authagonal की होस्टेड login, registration, password-reset और MFA स्क्रीन को अपने स्वयं के UI से बदलें, जबकि Authagonal प्रमाणीकरण, MFA, SSO, सत्र और टोकन जारी करना संभालता रहे। दो मार्ग: हमारी React component library का उपयोग करें, या किसी भी framework से सीधे auth API कॉल करें। यह opt-in है: पहले सेटिंग्स → सेशन के अंतर्गत कस्टम लॉगिन UI सक्षम करें।

पूर्वापेक्षा: आपके root पर एक कस्टम डोमेन

login सत्र एक first-party cookie है, इसलिए आपके UI और Authagonal auth server को एक registrable डोमेन साझा करना होगा। एक कस्टम auth डोमेन को उसी root पर Authagonal की ओर इंगित करें जिस पर आपका ऐप चलता है — उदा. auth login.acme.com पर, ऐप app.acme.com पर। Custom login UI सेटिंग तब तक अक्षम रहती है जब तक एक सक्रिय कस्टम डोमेन मौजूद न हो।

/api/auth कॉल के लिए किसी क्लाइंट CORS सेटिंग की आवश्यकता नहीं है: कस्टम लॉगिन UI चालू होने के बाद, आपके auth डोमेन वाले ही registrable domain पर कोई भी origin स्वचालित रूप से स्वीकार किया जाता है। अपने UI के ओरिजिन (उदा. https://app.acme.com) को क्लाइंट के अनुमत CORS Origins (क्लाइंट → URI) में केवल तभी जोड़ें जब ब्राउज़र टोकन exchange भी करता हो।

React: @authagonal/login

npm i @authagonal/login auth logic और UI को एक पैकेज के रूप में भेजता है — वही जिस पर Authagonal का होस्टेड login बना है। अपनी altitude चुनें:

• पूर्ण ऐप — App को drop in करें और इसे branding के माध्यम से theme करें।
• पेज compose करें — अपने स्वयं के layout के अंदर LoginPage, MfaChallengePage, ResetPasswordPage… का उपयोग करें।
• Primitives + logic — AuthLayout/Button/Input और API client (login, mfaVerify, forgotPassword, …) के साथ अपनी स्वयं की स्क्रीन बनाएँ।

import { AuthLayout, Input, Button, login, ApiRequestError } from '@authagonal/login';

// returnUrl: the /connect/authorize URL your login page was opened with
function MyLogin({ returnUrl }: { returnUrl: string }) {
  async function onSubmit(email: string, password: string) {
    try {
      const res = await login(email, password, returnUrl);  // POST /api/auth/login (sets the session cookie)
      if (res.mfaRequired) {/* render your MFA step, then mfaVerify(res.challengeId!, 'totp', code) */}
      else if (res.mfaSetupRequired) {/* enrol first: mfaTotpSetup(res.setupToken) */}
      else window.location.href = returnUrl;                 // resume /connect/authorize
    } catch (e) {
      if (e instanceof ApiRequestError) {/* show e.message; e.error is the error code */}
    }
  }
  return <AuthLayout>{/* your own markup + <Input/> <Button/> */}</AuthLayout>;
}

कोई भी framework: auth API कॉल करें

React पर नहीं हैं? सीधे auth-flow एंडपॉइंट्स (/api/auth के अंतर्गत) कॉल करें, फिर मानक OIDC /connect/authorize प्रवाह को सौंप दें। credentials: 'include' भेजें ताकि सत्र कुकी संग्रहीत हो।

# 1. Authenticate (browser fetch; credentials:'include' so the session cookie is stored)
curl -i -X POST https://login.acme.com/api/auth/login \
  -H "Content-Type: application/json" \
  -H "Origin: https://app.acme.com" \
  --data '{"email":"[email protected]","password":"..."}'
# (handle {"mfaRequired":true} → POST /api/auth/mfa/verify, then continue)

# 2. Hand off to the OAuth flow: top-level navigation to the authorize endpoint with PKCE:
# https://login.acme.com/connect/authorize?client_id=my-app&redirect_uri=...&response_type=code
#   &scope=openid%20profile%20email&code_challenge=...&code_challenge_method=S256
# The session cookie (same-site) authenticates the user; you get back a code → exchange at /connect/token.

एक टेनेंट, कई ग्राहक

एक integrator, एक टेनेंट और N ब्रांडेड ग्राहकों के लिए एक पैटर्न, जिनमें हर एक का अपना लॉगिन डोमेन और अपने उपयोगकर्ता हों, और हर ग्राहक के लिए अलग टेनेंट न बनाना पड़े। डिक्लेरेटिव प्रोविज़निंग और संगठन इसी को इंजीनियरिंग कार्य के बजाय कॉन्फ़िग बदलाव बनाने के लिए हैं।

संरचना

• हर ग्राहक के लिए एक संगठन, एक ही टेनेंट के भीतर।
• हर ग्राहक के लिए एक ब्रांडेड लॉगिन डोमेन, हर एक उस ग्राहक के संगठन से पिन किया हुआ। उस पर साइन इन करने से केवल उसी संगठन के लिए टोकन बन सकता है।
• एप्लिकेशन भी प्रति ग्राहक होस्ट पर परोसा जाता है, सब एक ही डिप्लॉयमेंट से। ग्राहकों के बीच कोड, बिल्ड या इमेज में कुछ भी अलग नहीं होता।
• Relying party अपनी authority उस होस्ट से चुनती है जिस पर वह चल रही है, बिल्ड-टाइम स्थिरांक से नहीं। वही bundle इस पर निर्भर करते हुए कि उसे किस ग्राहक के होस्ट ने परोसा, खुद को अलग लॉगिन डोमेन से जोड़ लेता है।

चरण दर चरण

ग्राहक को प्रोविज़न करें। नए संगठन और उसके डोमेन को नाम देने वाले spec के साथ डिक्लेरेटिव प्रोविज़निंग एंडपॉइंट को कॉल करें। कॉल idempotent और सेक्शन-स्कोप्ड है।

{
  "organizations": [
    { "slug": "acme", "name": "Acme Pty Ltd" }
  ],
  "customDomains": [
    { "domain": "login.acme.example", "organizationSlug": "acme" }
  ]
}

ग्राहक के DNS को टेनेंट की ओर इंगित करें। ग्राहक के अपने ज़ोन से एक CNAME, जो नियंत्रण और इरादा दोनों साबित करता है। कोई TXT टोकन नहीं।

_authagonal-challenge.login.acme.example.  CNAME  <slug>.<platformDomain>.

एप्लिकेशन को ग्राहक के होस्ट की ओर इंगित करें। Relying party अपनी OIDC authority हर अनुरोध पर उस होस्ट से resolve करती है जिसे वह इस समय परोस रही है। ग्राहक मैप में जिस होस्ट की प्रविष्टि नहीं है, वह क्लासिक सिंगल-टेनेंट डेरिवेशन पर लौट जाता है, इसलिए ग्राहक जोड़ना पूरी तरह additive है।

export function resolveCustomer(): { authority: string; clientId: string } {
  const cfg = getConfig();
  const customer = cfg.customers?.[window.location.host];
  if (customer) return customer;
  const baseDomain = cfg.baseDomain || window.location.hostname.replace(/^consumer\./, '');
  return { authority: `https://${cfg.tenantSlug}.${baseDomain}`, clientId: cfg.clientId };
}

क्लाइंट संगठन-विशिष्ट कुछ नहीं माँगता: कोई organization पैरामीटर नहीं, कोई प्रति-ग्राहक स्कोप नहीं। संगठन का चयन पूरी तरह डोमेन पिन सर्वर-साइड करता है, और इसी से "हर ग्राहक के लिए ऐप वही कोड है" सचमुच सच होता है।

ग्राहक क्या देखता है

लॉगिन पेज हर संगठन की अपनी ब्रांडिंग टेनेंट की ब्रांडिंग पर मर्ज करके दिखाता है। Branding override देखें। हर ग्राहक के पास दूसरों को छुए बिना अपना ऐप नाम, लोगो, रंग और सपोर्ट ईमेल हो सकता है।

ग्राहक A का जो उपयोगकर्ता ग्राहक B के होस्ट पर साइन इन करने की कोशिश करता है, उसे अस्वीकार किया जाता है और ग्राहक B का डेटा नहीं दिखाया जाता। टकराव कैसे हुआ, उसके आधार पर यह दो रूपों में से एक में होता है:

• Relying party कुछ नहीं भेजती और बस पिन किए गए डोमेन पर पहुँच जाती है। पिन उपयोगकर्ता की ओर से संगठन उपलब्ध कराता है, चयन तब स्पष्ट हो जाता है, और B में सदस्यता न रखने वाले ग्राहक-A के उपयोगकर्ता को ठीक उसी बिंदु पर अस्वीकार किया जाता है जहाँ टोकन बनता।
• Relying party खुद किसी दूसरे संगठन को नाम देती है। डोमेन-पिनिंग middleware इसे किसी भी लॉगिन पेज के दिखने से पहले सीधे 400 के साथ अस्वीकार कर देता है।

ग्राहक N+1 को ऑनबोर्ड करना

जब Terraform प्रोविज़निंग कॉल चलाता है, तब एक और ग्राहक को ऑनबोर्ड करना एक फ़ाइल का संपादन है: संगठन ऐरे में एक और प्रविष्टि, उसे पिन करने वाली एक और डोमेन प्रविष्टि, एक और DNS रिकॉर्ड। एप्लिकेशन, उसके डिप्लॉयमेंट या बिल्ड में कुछ नहीं बदलता। Host-based resolver नए ग्राहक को उसी क्षण पकड़ लेता है जब उसकी कॉन्फ़िग प्रविष्टि मौजूद होती है।

रेफ़रेंस इम्प्लीमेंटेशन

एक स्थायी dev टेनेंट पूरे पैटर्न को दो असली ग्राहक डोमेन पर एंड-टू-एंड चलाकर परखता है। इसके end-to-end टेस्ट सूट सदस्य प्रोविज़न करता है, ब्रांडिंग और org_id क्लेम जाँचता है, और ऊपर के दोनों अस्वीकृति रूपों की पुष्टि करता है। यह केवल विवरण नहीं, निष्पादन-योग्य दस्तावेज़ है।

cd e2e-consumer && DOMAIN=authagonal.dev npx playwright test organizations-domains

सूट बाकी हर spec की तरह डिफ़ॉल्ट रूप से चलता है। जिस एनवायरनमेंट में रेफ़रेंस डोमेन प्रोविज़न नहीं हैं, वहाँ इसे छोड़ा जा सकता है, क्योंकि यह सूट का एकमात्र spec है जो रेपो के अपने नियंत्रण से बाहर के इंफ्रास्ट्रक्चर पर निर्भर करता है।

प्लान और सीमाएँ

Authagonal एक Free प्लान और चार सशुल्क स्तर प्रदान करता है। हर प्लान में हर प्रमाणीकरण सुविधा शामिल है। प्लान Monthly Active User (MAU) सीमा और ओवरेज मूल्य निर्धारण में भिन्न होते हैं, और Free प्लान में केवल community support है, टेनेंट support desk के बिना।

प्लान स्तर

Monthly Active Users (MAU)

Monthly Active User कोई भी अद्वितीय उपयोगकर्ता है जो किसी कैलेंडर माह (UTC) के दौरान कम से कम एक बार सफलतापूर्वक प्रमाणित होता है। SCIM के माध्यम से प्रोविज़न किए गए लेकिन लॉग इन न करने वाले उपयोगकर्ता आपके MAU कुल में नहीं गिने जाते।

ओवरेज: यदि आपका प्लान ओवरेज का समर्थन करता है (Pro और उससे ऊपर) और आपके टेनेंट के लिए ओवरेज सक्षम है (यह डिफ़ॉल्ट रूप से बंद होता है), तो MAU सीमा से अधिक उपयोगकर्ताओं को ऊपर दी गई प्लान तालिका में दिखाई गई प्रति-उपयोगकर्ता दर पर बिल किया जाता है। ओवरेज cap सीमा से ऊपर अनुमत अतिरिक्त उपयोगकर्ताओं की अधिकतम संख्या तय करता है।

प्रवर्तन: यदि आपका प्लान ओवरेज का समर्थन नहीं करता (Free, Starter) या ओवरेज सक्षम नहीं है, तो इस माह पहले ही साइन इन कर चुके उपयोगकर्ताओं की पहुँच हमेशा बनी रहती है। जब टेनेंट पहली बार अपनी सीमा पार करता है, तो 10 दिनों की grace अवधि शुरू होती है जिसके दौरान नए उपयोगकर्ता अभी भी साइन इन कर सकते हैं। उसके बाद, इस माह साइन इन न करने वाले उपयोगकर्ताओं को अगले माह तक या आपके अपग्रेड करने तक अस्वीकार कर दिया जाता है।