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

शुरुआत करना

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

एक खाता बनाएँ

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

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

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

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

पोर्टल में एक नया 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, tokens.refresh_token

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

डैशबोर्ड

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

अवलोकन

डैशबोर्ड के शीर्ष पर आपको आपकी वर्तमान कुल उपयोगकर्ता संख्या के साथ एक स्वागत संदेश दिखाई देगा। उसके नीचे, एक Daily Active Users चार्ट उन अद्वितीय उपयोगकर्ताओं का 7-दिवसीय इतिहास दिखाता है जिन्होंने हर दिन प्रमाणीकरण किया, जिससे आपको एंगेजमेंट रुझानों की त्वरित जानकारी मिलती है।

DAU चार्ट और गतिविधि अवलोकन के साथ डैशबोर्ड होम स्क्रीन

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

गतिविधि मेट्रिक्स पैनल प्रमुख प्रमाणीकरण इवेंट्स को सारांशित करने वाले चार स्टेट कार्ड दिखाता है:

• Successful Logins — कुल पूर्ण किए गए प्रमाणीकरण फ़्लो
• Failed Logins — गलत क्रेडेंशियल्स, लॉक किए गए खाते, या नीति अस्वीकृतियाँ
• Active Users — चयनित अवधि में प्रमाणीकरण करने वाले अद्वितीय उपयोगकर्ता
• SCIM Operations — कनेक्टेड IdPs से उपयोगकर्ता और ग्रुप provisioning इवेंट्स

24 घंटे, 3 दिन, 7 दिन, और 30 दिन के बीच स्विच करने के लिए टाइम रेंज फ़िल्टर का उपयोग करें। सभी स्टेट कार्ड और चार्ट चयनित विंडो को दर्शाने के लिए अपडेट हो जाते हैं।

कॉन्फ़िगर करने योग्य टाइम रेंज के साथ गतिविधि मेट्रिक्स

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

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

क्लाइंट्स

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

क्लाइंट सूची

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

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

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

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

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

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

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

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

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

हर क्लाइंट के पास कई अनुभागों में व्यवस्थित कॉन्फ़िगरेशन विकल्पों का एक व्यापक सेट होता है।

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

URIs

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

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

Scopes और Grant Types

Token Lifetimes

प्रति क्लाइंट token lifetimes कॉन्फ़िगर करें

Logout URIs

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

MFA Policy

हर क्लाइंट प्रति-क्लाइंट सेटिंग के साथ टेनेंट-व्यापी MFA policy को ओवरराइड कर सकता है। MFA policy ड्रॉपडाउन तीन विकल्प प्रदान करता है:

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

Enterprise SSO

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

Domain-based SSO routing

SAML 2.0 कनेक्शन

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

जब आप कनेक्शन सहेजते हैं, तो Authagonal metadata document प्राप्त करता है और IdP का signing certificate, SSO endpoint URL, और name identifier format आयात करता है। certificate rotations को पकड़ने के लिए metadata को समय-समय पर रीफ़्रेश किया जाता है।

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

OIDC कनेक्शन

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

एक OIDC federation कनेक्शन बनाएँ

Domain Routing

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

Domain routing ईमेल डोमेन को identity providers से मैप करता है

JIT Provisioning

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

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

उपयोगकर्ता

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

खोज और Pagination

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

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

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

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

उपयोगकर्ता बनाना

एक नया लोकल उपयोगकर्ता जोड़ने के लिए Create User पर क्लिक करें। फ़ॉर्म के लिए आवश्यक है:

एक नया लोकल उपयोगकर्ता बनाएँ

पसंदीदा भाषा

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

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

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

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

प्रोफ़ाइल

ईमेल, पहला/अंतिम नाम, फ़ोन, कंपनी, external ID संपादित करें, और उपयोगकर्ता के active flag को टॉगल करें। ईमेल परिवर्तन टेनेंट भर में अद्वितीय रहने चाहिए; यदि पहले से लिया गया है तो API email_in_use लौटाता है।

भूमिकाएँ (Roles)

Roles पेज पर परिभाषित भूमिकाएँ असाइन और अनअसाइन करें। जब क्लाइंट में includeRolesInTokens सक्षम होता है तो भूमिका सदस्यता ID और access tokens में सामने आती है।

Multi-Factor Authentication

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

Custom Attributes

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

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

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

ग्रुप्स

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

ग्रुप सूची

Groups पेज आपके टेनेंट में सभी ग्रुप्स को निम्नलिखित जानकारी के साथ दिखाता है:

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

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

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

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

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

• Add members — किसी उपयोगकर्ता को ग्रुप में जोड़ने के लिए एक user ID दर्ज करें।
• Remove members — किसी सदस्य को व्यक्तिगत रूप से हटाने के लिए उसके बगल में remove बटन पर क्लिक करें।

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

Tokens में ग्रुप्स

जब किसी क्लाइंट पर includeGroupsInTokens सक्षम होता है, तो ID token में एक groups claim शामिल होता है जिसमें उपयोगकर्ता की ग्रुप सदस्यताएँ होती हैं। प्रत्येक प्रविष्टि में ग्रुप का id और name शामिल होता है:

{
  "sub": "user-123",
  "email": "[email protected]",
  "groups": [
    { "id": "grp-001", "name": "Engineering" },
    { "id": "grp-002", "name": "Beta Testers" }
  ]
}

भूमिकाएँ (Roles)

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

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

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

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

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

Inline Editing

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

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

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

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

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

किसी उपयोगकर्ता को असाइन की गई भूमिकाएँ ID token में एक roles claim के रूप में शामिल होती हैं। आपका एप्लिकेशन authorization निर्णय लेने के लिए इस claim को पढ़ सकता है:

{
  "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 सुविधाओं का वर्णन करती है, जिसमें बल्क ऑपरेशन, फ़िल्टरिंग और पासवर्ड बदलने की क्षमता शामिल है।

OAuth स्कोप

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

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

कस्टम स्कोप

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

tokens पर कस्टम claims

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

जब एक क्लाइंट स्कोप का अनुरोध करता है, तो Authagonal ग्रांट किए गए स्कोप के माध्यम से चलता है, उनकी userClaims सूचियों का union करता है, और उपयोगकर्ता के customAttributes से केवल उन्हीं keys को emit करता है। अज्ञात keys चुपचाप गिरा दी जाती हैं — एक क्लाइंट नाम का अनुमान लगाकर किसी attribute को नहीं पढ़ सकता। मानक OIDC claims (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 दें। फ़ाइल डिफ़ॉल्ट स्टाइल के बाद लोड होती है, इसलिए आपके नियमों को प्राथमिकता मिलती है।

डार्क मोड

लॉगिन ऐप लाइट, डार्क और सिस्टम थीम के साथ आता है। उपयोगकर्ता लॉगिन पेज पर एक टॉगल से चुनते हैं; यह विकल्प सेशनों के बीच बना रहता है। 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));
}

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

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

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

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

सैंडबॉक्स {slug}-sandbox.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 सत्यापन

अपने डोमेन को {slug}.authagonal.io की ओर इंगित करने वाला एक CNAME रिकॉर्ड बनाएँ। DNS रिकॉर्ड लागू हो जाने के बाद, DNS प्रसार जाँचने के लिए Verify पर क्लिक करें।

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 (पूर्णतः चालू), या failed (कॉन्फ़िगरेशन समस्या का पता चला)।

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

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

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

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

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

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

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

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

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

प्रेषक पहचान

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

Resend Custom Domain

अपने सेंडिंग डोमेन को Resend के साथ एक बार सत्यापित करें, फिर इसे इस टेनेंट के लिए From पते के रूप में उपयोग करें। DNS TXT रिकॉर्ड (SPF, DKIM) Domains पेज द्वारा प्रदान किए जाते हैं; Resend उन्हें स्वचालित रूप से मान्य करता है।

कस्टम SMTP

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

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

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

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

परीक्षण

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

ऑडिट लॉग

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

लॉग कॉलम

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

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

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

बैकअप

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

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

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

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

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

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

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

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

जब कोई उपयोगकर्ता इवेंट होता है (निर्माण या प्रमाणीकरण), तो Authagonal TCC (Try/Confirm/Cancel) पैटर्न का उपयोग करके आपके प्रोविज़निंग ऐप के कॉलबैक URL को कॉल करता है। यह तीन-चरण दृष्टिकोण कई डाउनस्ट्रीम सिस्टम में विश्वसनीय प्रोविज़निंग सुनिश्चित करता है:

वेबहुक पेलोड

प्रत्येक वेबहुक अनुरोध में निम्नलिखित फ़ील्ड के साथ एक JSON पेलोड शामिल होता है:

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

प्रोविज़निंग ऐप जोड़ने के लिए, एक नाम, एक कॉलबैक URL, और एक वैकल्पिक API key दें। API key प्रत्येक वेबहुक अनुरोध के Authorization हेडर में Bearer टोकन के रूप में भेजी जाती है, जो आपके ऐप को Authagonal से अनुरोधों को प्रमाणित करने की अनुमति देती है।

परीक्षण

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

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

प्लान सीमाएँ

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

टीम

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

एडमिन सूची

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

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

नए टीम सदस्य को आमंत्रित करने के लिए, उनका ईमेल पता, नाम, और एक अस्थायी पासवर्ड (न्यूनतम 8 वर्ण) दें। आमंत्रित उपयोगकर्ता अस्थायी पासवर्ड से साइन इन करता है और उसे पहले लॉगिन पर बदल देना चाहिए।

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

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

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

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

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

सपोर्ट

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

आपके टिकट

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

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

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

एक टिकट थ्रेड

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

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

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

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

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

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

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

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

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

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

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

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

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

Password Hashes

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

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

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

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

प्रीव्यू की समीक्षा करने के बाद Start import पर क्लिक करें। कमिट चरण क्लाइंट, स्कोप, उपयोगकर्ता, भूमिकाओं, और 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 secret को इम्पोर्ट फ़ॉर्म में पेस्ट करें — इनका उपयोग केवल इम्पोर्ट के लिए किया जाता है।

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

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 Discovery और JWKS

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

GET /.well-known/openid-configuration

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

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

टोकन हस्ताक्षरों को सत्यापित करने के लिए उपयोग किया जाने वाला JSON Web Key Set लौटाता है। प्रतिक्रिया में RSA सार्वजनिक कुंजियों के साथ एक keys array होता है, जिनमें से प्रत्येक में kty, use, kid, alg, n, और e फ़ील्ड शामिल होते हैं।

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

Authorization एंडपॉइंट

GET /connect/authorize

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

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

त्रुटि प्रतिक्रिया: error, error_description, और state query पैरामीटर के साथ 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 क्लाइंट बिना secret के पोस्ट करते हैं। body में वही पैरामीटर होते हैं जो आप सामान्यतः /connect/authorize पर भेजते हैं; request_uri स्वयं अस्वीकृत कर दिया जाता है (PAR को chain करना विनिर्देश के §2.1 द्वारा निषिद्ध है)। 201 Created लौटाता है।

प्रतिक्रिया

फ़ॉलो-अप GET /connect/authorize?client_id=…&request_uri=… पर, अन्य सभी पैरामीटर pushed payload से लिए जाते हैं और कोई भी अतिरिक्त query पैरामीटर अनदेखा कर दिया जाता है। 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 स्कोप के साथ एक वैध access token की आवश्यकता होती है।

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 के साथ token एंडपॉइंट को poll करता है।

Polling त्रुटि कोड:

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

वर्तमान उपयोगकर्ता सत्र को साइन आउट करता है, पंजीकृत BackChannelLogoutUri वाले सभी क्लाइंट के लिए back-channel logout ट्रिगर करता है, और सभी grants रद्द करता है।

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

SCIM 2.0 API संदर्भ

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

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

प्रमाणीकरण: सभी अनुरोधों के लिए एक Bearer token आवश्यक है। पोर्टल में Settings > SCIM Provisioning के अंतर्गत एक SCIM token जनरेट करें।

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

List एंडपॉइंट startIndex (1-आधारित) और count (अधिकतम 200) query पैरामीटर के माध्यम से pagination का समर्थन करते हैं, और filter पैरामीटर (उदा. userName eq "[email protected]") के माध्यम से filtering का।

Users

GET /scim/v2/Users — वैकल्पिक pagination और filtering के साथ उपयोगकर्ताओं की सूची बनाएँ।

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 — वैकल्पिक pagination और filtering के साथ सभी समूहों की सूची बनाएँ।

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

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

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

PATCH /scim/v2/Groups/{id} — समूह सदस्यों को जोड़ने या हटाने के लिए आंशिक अपडेट।

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 access token के साथ प्रमाणित होते हैं; टेनेंट को URL से नहीं, टोकन से लिया जाता है।

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

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

एक्सेस स्तर

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

अपने टेनेंट के token endpoint — https://<your-tenant>.<your-domain>/connect/token — पर क्रेडेंशियल को एक access 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 access token की आवश्यकता होती है। प्रत्येक समूह के बगल में दिया गया स्कोप उसके लिए आवश्यक न्यूनतम क्रेडेंशियल एक्सेस स्तर है। List एंडपॉइंट startIndex और count क्वेरी पैरामीटर स्वीकार करते हैं।

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

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

POST/api/v1/clients— एक क्लाइंट बनाएँ। client ID लौटाता है और, confidential क्लाइंट के लिए, एक एक-बार का secret।

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

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

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

GET/api/v1/users— उपयोगकर्ता सूचीबद्ध करें। startIndex, count, और खोज (ईमेल / नाम उपसर्ग) का समर्थन करता है।

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

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

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

POST/api/v1/users— एक ईमेल और पासवर्ड के साथ एक उपयोगकर्ता बनाएँ।

PUT/api/v1/users/{id}— एक उपयोगकर्ता अपडेट करें (प्रोफ़ाइल, ईमेल, enabled/blocked स्थिति)।

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

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

DELETE/api/v1/users/{id}/mfa— Reset a user's MFA enrollment.

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/scopes— API स्कोप सूचीबद्ध करें।

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

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

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

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

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

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

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

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

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

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

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

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

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

POST/api/v1/settings/webhook-secret/regenerate— webhook signing secret रोटेट करें।

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— प्रेषक ईमेल डोमेन सूचीबद्ध करें।

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

उदाहरण: एक उपयोगकर्ता बनाएँ

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

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

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

ये वे होस्टेड स्क्रीन हैं जो आपके अंतिम उपयोगकर्ता आपके टेनेंट के 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 पेज)।
• Session lifetime और lockout थ्रेशोल्ड (Settings → Security)।

रजिस्ट्रेशन

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

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

• registration लिंक दिखाएँ या छिपाएँ (Branding)।
• आपके टेनेंट की password policy चेकलिस्ट को संचालित करती है।
• Branding पूरी स्क्रीन को स्टाइल करती है।

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

• उपयोगकर्ता अपना ईमेल दर्ज करता है, फिर एक तटस्थ "check your email" पुष्टि देखता है।
• स्क्रीन कभी प्रकट नहीं करती कि कोई खाता मौजूद है या नहीं, जो account-enumeration जाँच को विफल करती है।
• एक "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 पूरी स्क्रीन को स्टाइल करती है।

डिवाइस authorization

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

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

• एप्लिकेशन पर device-code grant सक्षम करें (Clients → Grant types)।
• device-code lifetime सेट करें (Clients → Tokens)।

सहमति

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

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

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

कनेक्टेड ऐप्स (grants)

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

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

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

खाता

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

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

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

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

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

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

लॉगिन

POST /api/auth/login

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

अनुरोध बॉडी:

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

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

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

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

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

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

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

रजिस्ट्रेशन

POST /api/auth/register

एक नया उपयोगकर्ता खाता बनाता है। एक सत्यापन ईमेल स्वतः भेजा जाता है — उपयोगकर्ता को लॉगिन करने से पहले अपना ईमेल सत्यापित करना होगा।

अनुरोध बॉडी:

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

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

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

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

POST /api/auth/forgot-password

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

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

POST /api/auth/reset-password

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

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

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

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

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

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

TOTP सेटअप

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

POST /api/auth/mfa/totp/confirm — authenticator app से एक 6-अंकीय कोड को मान्य करके TOTP enrollment की पुष्टि करता है।

{
  "code": "123456"
}

WebAuthn सेटअप

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

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

Recovery Codes

POST /api/auth/mfa/recovery/generate — 10 एकल-उपयोग 8-वर्ण recovery codes जनरेट करता है। प्रत्येक कोड MFA को बायपास करने के लिए ठीक एक बार उपयोग किया जा सकता है।

MFA सत्यापन

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

MFA स्थिति

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

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

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

SSO Check

GET /api/auth/[email protected]

SAML प्रवाह

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

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

OIDC प्रवाह

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

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

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

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

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

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

अपने UI के origin (उदा. https://app.acme.com) को अपने OAuth क्लाइंट के Allowed CORS origins में भी जोड़ें — वही सूची जो आपने token 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';

function MyLogin() {
  async function onSubmit(email: string, password: string) {
    try {
      const res = await login({ email, password });        // POST /login (sets the session cookie)
      if (res.mfaRequired) {/* render your MFA step → mfaVerify(...) */}
      else window.location.href = res.returnUrl;            // hand off to /connect/authorize
    } catch (e) {
      if (e instanceof ApiRequestError) {/* show e.message */}
    }
  }
  return <AuthLayout>{/* your own markup + <Input/> <Button/> */}</AuthLayout>;
}

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

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

# 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.

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

Authagonal चार प्लान स्तर प्रदान करता है। सभी प्लान में सभी सुविधाएँ शामिल हैं — एकमात्र अंतर Monthly Active User (MAU) सीमा और ओवरेज मूल्य निर्धारण है।

प्लान स्तर

Monthly Active Users (MAU)

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

ओवरेज — यदि आपका प्लान ओवरेज का समर्थन करता है, तो MAU सीमा से अधिक उपयोगकर्ताओं को ऊपर दी गई प्लान तालिका में दिखाई गई प्रति-उपयोगकर्ता दर पर बिल किया जाता है। आप बिलिंग अवधि के लिए अपने अधिकतम व्यय को सीमित करने हेतु एक ओवरेज cap सेट कर सकते हैं।

प्रवर्तन — यदि आपका प्लान ओवरेज का समर्थन नहीं करता (Starter), तो MAU सीमा से अधिक उपयोगकर्ता अगली बिलिंग अवधि तक या जब तक आप ओवरेज का समर्थन करने वाले प्लान में अपग्रेड नहीं करते, लॉग इन नहीं कर सकते।