मुख्य कंटेंट पर जाएँ
Sursa Developers

POST/oauth/token

OAuth 2.0 टोकन जारी करें

oauth_token

OAuth 2.0 का टोकन एंडपॉइंट (RFC 6749, सेक्शन 3.2)। grant_type: authorization_code एक बार इस्तेमाल होने वाले कोड को टोकन की जोड़ी से बदलता है और इसके लिए code_verifier (PKCE S256) चाहिए; refresh_token रिफ़्रेश टोकन के बदले नई जोड़ी जारी करता है और पिछले रिफ़्रेश टोकन को अमान्य करता है (रोटेशन), और अमान्य किए गए टोकन का दोबारा इस्तेमाल पूरी श्रृंखला रद्द कर देता है; client_credentials संगठन की ओर से टोकन जारी करता है, सिर्फ़ confidential ऐप के लिए, रिफ़्रेश टोकन के बिना। confidential क्लाइंट Authorization: Basic हेडर से या client_id और client_secret फ़ील्ड से ऑथेंटिकेट होता है; पब्लिक क्लाइंट सिर्फ़ client_id भेजता है। ऐक्सेस टोकन 1 घंटे के लिए मान्य होता है, रिफ़्रेश टोकन 90 दिन के लिए। रिस्पॉन्स और एरर RFC 6749, सेक्शन 5 के अनुसार होते हैं, Cache-Control: no-store के साथ। 1.62.0 में जोड़ा गया।

ऑथेंटिकेशन

क्रेडेंशियल की ज़रूरत नहीं है।

रिक्वेस्ट बॉडी

application/x-www-form-urlencoded

ऑब्जेक्ट: OAuthTokenRequest

  • grant_typestringज़रूरी

    मान्य मान: authorization_coderefresh_tokenclient_credentials

  • codestring

    ऑथराइज़ेशन कोड (authorization_code)।

  • redirect_uristring

    वही रीडायरेक्ट URI, जो ऑथराइज़ेशन रिक्वेस्ट में था (authorization_code)।

  • code_verifierstring

    मूल PKCE मान, 43 से 128 अक्षर (authorization_code)।

  • refresh_tokenstring

    रिफ़्रेश (refresh_token)।

  • scopestring

    स्पेस से अलग किए गए स्कोप, सिर्फ़ दायरा घटाने के लिए (refresh_token, client_credentials)।

  • client_idstring

    ऐप का ID, जब सीक्रेट Authorization: Basic हेडर में नहीं दिया जाता।

  • client_secretstring

    confidential ऐप का क्लाइंट सीक्रेट, जब वह Authorization: Basic हेडर में नहीं दिया जाता।

रिस्पॉन्स

200टोकन जारी किए गए।

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: OAuthTokenResponse

  • access_tokenstringज़रूरी

    Authorization: Bearer हेडर के लिए ऐक्सेस टोकन (kbat_…)।

  • token_typestringज़रूरी

    मान्य मान: Bearer

  • expires_inintegerज़रूरी

    ऐक्सेस टोकन की उम्र, सेकंड में।

  • refresh_tokenstring

    रिफ़्रेश टोकन (kbrt_…); client credentials के लिए नहीं होता।

  • scopestringज़रूरी

    टोकन के स्कोप, स्पेस से अलग।

400RFC 6749, सेक्शन 5.2 में बताए अनुसार एरर।

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: OAuthErrorResponse

401क्लाइंट के अमान्य क्रेडेंशियल (`invalid_client`)।

रिस्पॉन्स हेडर

  • RateLimit-Policy

    लागू सीमाएँ, IETF ड्राफ़्ट draft-ietf-httpapi-ratelimit-headers के फ़ॉर्मेट में: कॉमा से अलग आइटम "<name>";q=<quota>;w=<window in seconds>। key API कुंजी की रिक्वेस्ट दर है (कोटा बर्स्ट है, विंडो उसके पूरी तरह भरने का समय है; सेशन के लिए यह user है, बिना क्रेडेंशियल के ip); minute, day और month UTC में कैलेंडर मिनट, दिन और महीने के लिए संगठन के कोटा हैं।

  • RateLimit

    RateLimit-Policy की हर सीमा में से कितना बचा है: "<name>";r=<remaining>;t=<seconds until reset>।

  • X-RateLimit-Limit

    RateLimit-Policy की सबसे सख़्त एंट्री की सीमा (जिसमें सबसे कम रिक्वेस्ट बची हैं)।

  • X-RateLimit-Remaining

    सबसे सख़्त सीमा में बची रिक्वेस्ट।

  • X-RateLimit-Reset

    सबसे सख़्त सीमा के रीसेट होने तक के सेकंड।

application/json

ऑब्जेक्ट: OAuthErrorResponse

सुरक्षित रीट्राई

हर POST और PATCH के साथ Idempotency-Key हेडर भेजें (उदाहरण के लिए, UUID)। 24 घंटे के अंदर उसी कुंजी के साथ रीट्राई करने पर रिक्वेस्ट दोबारा नहीं चलती, बल्कि सेव किया गया रिस्पॉन्स लौटता है।

रेट लिमिट

रिस्पॉन्स में RateLimit और RateLimit-Policy हेडर होते हैं, और पहले वाले X-RateLimit-Limit, X-RateLimit-Remaining और X-RateLimit-Reset भी। 429 रिस्पॉन्स में Retry-After सेकंड में होता है: उतना इंतज़ार करें और रीट्राई करें।

← oauth · API रेफ़रेंस