इस पेज का अनुवाद Cloud Translation API से किया गया है.

OAuthV2 नीति

आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

क्या

OAuthV2, OAuth 2.0 के ग्रांट टाइप के ऑपरेशन करने के लिए कई तरह की नीतियां उपलब्ध कराता है. यह Apigee Edge पर OAuth 2.0 एंडपॉइंट कॉन्फ़िगर करने के लिए इस्तेमाल की जाने वाली मुख्य नीति है.

ध्यान दें: OAuthV2 नीति, RFC के मुताबिक नहीं होने वाले कुछ रिस्पॉन्स एलिमेंट दिखाती है. उदाहरण के लिए, नीति एक टोकन प्रॉपर्टी "token_type":"BearerToken" दिखाती है. इसमें नीति का पालन करने वाली टोकन प्रॉपर्टी "token_type":"Bearer" होती है. नीतियों का पालन न करने वाले रिस्पॉन्स के इन एलिमेंट के बारे में ज़्यादा जानने के लिए, RFC के मुताबिक काम न करने वाले एलिमेंट देखें.

सलाह: अगर आपको Apigee Edge पर OAuth के बारे में ज़्यादा जानना है, तो OAuth का होम पेज देखें. इसमें संसाधनों, सैंपल, वीडियो वगैरह के लिंक दिए गए हैं. किसी ऐप्लिकेशन में इस नीति का इस्तेमाल कैसे किया जाता है, यह जानने के लिए GitHub पर OAuth का ऐडवांस सैंपल देखें.

नमूने

VerifyAccessToken

OAuthV2 नीति का यह कॉन्फ़िगरेशन (VerifyAccessToken ऑपरेशन के साथ) पुष्टि करता है कि Apigee Edge को सबमिट किया गया ऐक्सेस टोकन मान्य है. इस नीति के लागू होने पर, Edge अनुरोध में मान्य ऐक्सेस टोकन की जांच करता है. अगर ऐक्सेस टोकन मान्य है, तो अनुरोध को आगे बढ़ने की अनुमति दी जाती है. अगर यह अमान्य है, तो सभी प्रोसेस रुक जाती हैं और जवाब में गड़बड़ी का मैसेज दिखता है.

<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuth-v20-2">
    <DisplayName>OAuth v2.0 2</DisplayName>
    <Operation>VerifyAccessToken</Operation>
    <AccessTokenPrefix>Bearer</AccessTokenPrefix> <!-- Optional, default is Bearer -->
</OAuthV2>

ध्यान दें: सिर्फ़ OAuth 2.0 बियरर टोकन इस्तेमाल किए जा सकते हैं. मैसेज की पुष्टि करने वाले कोड (एमएसी) टोकन काम नहीं करते हैं.

उदाहरण के लिए:

$ curl -H "Authorization: Bearer ylSkZIjbdWybfsUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

डिफ़ॉल्ट रूप से, Edge, Authorization हेडर में ऐक्सेस टोकन स्वीकार करता है. इसके लिए, Bearer प्रीफ़िक्स का इस्तेमाल किया जाता है. <AccessToken> एलिमेंट का इस्तेमाल करके, इस डिफ़ॉल्ट सेटिंग को बदला जा सकता है.

GenerateAccessToken

ऐक्सेस टोकन जनरेट करना

अनुमति देने के हर तरीके के लिए ऐक्सेस टोकन का अनुरोध करने के तरीके के उदाहरण देखने के लिए, ऐक्सेस टोकन और ऑथराइज़ेशन कोड का अनुरोध करना लेख पढ़ें. इस विषय में, इन कार्रवाइयों के उदाहरण शामिल हैं:

GenerateAuthorizationCode

ऑथराइज़ेशन कोड जनरेट करना

ऑथराइज़ेशन कोड का अनुरोध करने का तरीका दिखाने वाले उदाहरणों के लिए, ऑथराइज़ेशन कोड का अनुरोध करना लेख पढ़ें.

RefreshAccessToken

ऐक्सेस टोकन रीफ़्रेश करना

रीफ़्रेश टोकन का इस्तेमाल करके ऐक्सेस टोकन का अनुरोध करने के तरीके के उदाहरण देखने के लिए, ऐक्सेस टोकन रीफ़्रेश करना लेख पढ़ें.

जवाब देने के फ़्लो का टोकन

जवाब देने के फ़्लो पर ऐक्सेस टोकन जनरेट करना

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

सबसे पहले, नीति का सैंपल देखें:

<OAuthV2 enabled="true" continueOnError="false" async="false" name="generateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <AppEndUser>Doe</AppEndUser>
    <UserName>jdoe</UserName>
    <PassWord>jdoe</PassWord>
    <GrantType>grant_type</GrantType>
    <ClientId>a_valid_client_id</ClientId>
    <SupportedGrantTypes>
        <GrantType>password</GrantType>
    </SupportedGrantTypes>
</OAuthV2>

अगर इस नीति को रिस्पॉन्स फ़्लो पर लागू किया जाता है, तो यह 401 UnAuthorized गड़बड़ी के साथ काम नहीं करेगी. भले ही, नीति में सही लॉगिन पैरामीटर दिए गए हों. इस समस्या को हल करने के लिए, आपको अनुमति का अनुरोध करने वाला हेडर सेट करना होगा.

Authorization हेडर में, Basic ऐक्सेस स्कीम होनी चाहिए. साथ ही, इसमें Base64 के कोड में बदला गया client_id:client_secret होना चाहिए.

इस हेडर को OAuthV2 नीति से ठीक पहले लागू की गई JavaScript नीति के साथ जोड़ा जा सकता है. जैसे, यहां दिखाया गया है. "local_clientid" और "local_secret" वैरिएबल पहले से सेट होने चाहिए और फ़्लो में उपलब्ध होने चाहिए:

var client_id = context.getVariable("local_clientid");
var client_secret = context.getVariable("local_secret");
context.setVariable("request.header.Authorization","Basic "+CryptoJS.enc.Base64.stringify(CryptoJS.enc.Latin1
                                      .parse(client_id + ':' + client_secret)));

"बुनियादी पुष्टि करने के क्रेडेंशियल को कोड में बदलना" भी देखें.

तत्व का रेफ़रंस

नीति के रेफ़रंस में, OAuthV2 नीति के एलिमेंट और एट्रिब्यूट के बारे में बताया गया है.

ध्यान दें: इस नीति को कॉन्फ़िगर करने का तरीका और आपको जिन एलिमेंट के बारे में बताना है वे इस बात पर निर्भर करते हैं कि आपको नीति से कौनसी कार्रवाई करानी है. उदाहरण के लिए, अगर आपको ऑथराइज़ेशन कोड ग्रांट टाइप लागू करना है, तो आपको चार अलग-अलग OAuthV2 नीतियों की ज़रूरत होगी. इनकी मदद से, ऑथराइज़ेशन कोड जनरेट किया जा सकेगा, ऐक्सेस कोड जनरेट किया जा सकेगा, ऐक्सेस कोड की पुष्टि की जा सकेगी, और रीफ़्रेश टोकन जनरेट किया जा सकेगा. इस रेफ़रंस में, उन सभी एलिमेंट की सूची दी गई है जिनका इस्तेमाल इस नीति के साथ किया जा सकता है.

अगर आपको किसी खास तरह के ग्रांट टाइप के इस्तेमाल के उदाहरणों के लिए कॉन्फ़िगरेशन देखने हैं, तो ग्रांट टाइप लागू करने की सूची के लिए OAuth का होम पेज देखें. खास तौर पर, GitHub पर OAuth का ऐडवांस सैंपल देखें. इससे आपको यह समझने में मदद मिलेगी कि इस नीति का इस्तेमाल, काम करने वाले ऐप्लिकेशन में कैसे किया जाता है.

यहां दी गई नीति का सैंपल, कई संभावित कॉन्फ़िगरेशन में से एक है. इस सैंपल में, GenerateAccessToken ऑपरेशन के लिए कॉन्फ़िगर की गई OAuthV2 नीति दिखाई गई है. इसमें ज़रूरी और वैकल्पिक एलिमेंट शामिल हैं. ज़्यादा जानकारी के लिए, इस सेक्शन में एलिमेंट के ब्यौरे देखें.

<OAuthV2 name="GenerateAccessToken">
  <!-- This policy generates an OAuth 2.0 access token using the client_credentials grant type -->
  <Operation>GenerateAccessToken</Operation>
  <!-- This is in millseconds, so expire in an hour -->
  <ExpiresIn>3600000</ExpiresIn>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.queryparam.grant_type</GrantType>
  <GenerateResponse/>
</OAuthV2>

<OAuthV2> एट्रिब्यूट

<OAuthV2 async="false" continueOnError="false" enabled="true" name="MyOAuthPolicy">

यहां दी गई टेबल में, ऐसे एट्रिब्यूट के बारे में बताया गया है जो नीति के सभी पैरंट एलिमेंट में एक जैसे होते हैं:

एट्रिब्यूट	ब्यौरा	डिफ़ॉल्ट	मौजूदगी
`name`	नीति का अंदरूनी नाम. `name` एट्रिब्यूट की वैल्यू ये काम कर सकती है: अक्षरों, संख्याओं, स्पेस, हाइफ़न, अंडरस्कोर, और फ़ुलस्टॉप को शामिल करें. यह मान नहीं हो सकता 255 वर्णों से ज़्यादा होने चाहिए. इसके अलावा, नीति को लेबल करने के लिए, `<DisplayName>` एलिमेंट का इस्तेमाल करें प्रबंधन यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर को अलग, आम भाषा में इस्तेमाल करने वाले नाम के साथ किया जा सकता है.	लागू नहीं	ज़रूरी है
`continueOnError`	किसी नीति के काम न करने पर, गड़बड़ी दिखाने के लिए `false` पर सेट करें. यह उम्मीद है व्यवहार की जानकारी देने वाला डेटा. नीति के लागू होने के बाद भी फ़्लो को एक्ज़ीक्यूट करने के लिए, इसे `true` पर सेट करें विफल होता है.	गलत	वैकल्पिक
`enabled`	नीति को लागू करने के लिए, `true` पर सेट करें. नीति को बंद करने के लिए, `false` पर सेट करें. नीति लागू किया जाता है, भले ही वह किसी फ़्लो से जुड़ा रहता हो.	सही	वैकल्पिक
`async`	यह एट्रिब्यूट अब काम नहीं करता.	गलत	बहिष्कृत

<DisplayName> एलिमेंट

इस कॉलम में नीति को लेबल करने के लिए, name एट्रिब्यूट के साथ-साथ इस्तेमाल करें मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर, जिसका नाम अलग और सामान्य भाषा में है.

<DisplayName>Policy Display Name</DisplayName>

डिफ़ॉल्ट

डिफ़ॉल्ट	लागू नहीं अगर आप इस एलिमेंट को छोड़ देते हैं, तो नीति की `name` एट्रिब्यूट की वैल्यू यह होगी इस्तेमाल किया गया.
मौजूदगी	वैकल्पिक
टाइप	स्ट्रिंग

लागू नहीं

अगर आप इस एलिमेंट को छोड़ देते हैं, तो नीति की name एट्रिब्यूट की वैल्यू यह होगी इस्तेमाल किया गया.

मौजूदगी वैकल्पिक

टाइप स्ट्रिंग

<AccessToken> एलिमेंट

<AccessToken>request.header.access_token</AccessToken>

डिफ़ॉल्ट रूप से, VerifyAccessToken को Authorization हेडर में ऐक्सेस टोकन भेजने की ज़रूरत होती है. इस एलिमेंट का इस्तेमाल करके, डिफ़ॉल्ट सेटिंग को बदला जा सकता है. उदाहरण के लिए, request.queryparam.access_token से पता चलता है कि ऐक्सेस टोकन को access_token नाम के क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए.

<AccessToken>request.header.access_token</AccessToken> के बारे में जानकारी देने वाला उदाहरण:

curl https://myorg-myenv.apigee.net/oauth2/validate -H "access_token:Rft3dqrs56Blirls56a"

<AccessToken>request.queryparam.access_token</AccessToken> के बारे में जानकारी देने वाला उदाहरण:

curl "https://myorg-myenv.apigee.net/oauth2/validate?access_token:Rft3dqrs56Blirls56a"

डिफ़ॉल्ट:	लागू नहीं
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
इन कार्रवाइयों के साथ इस्तेमाल किया जाता है:	VerifyAccessToken

<AccessTokenPrefix> एलिमेंट

<AccessTokenPrefix>Bearer</AccessTokenPrefix>

डिफ़ॉल्ट रूप से, VerifyAccessToken नीति यह उम्मीद करती है कि ऐक्सेस टोकन को Authorization हेडर में, Bearer टोकन के तौर पर भेजा जाए. उदाहरण के लिए:

-H "Authorization: Bearer Rft3dqrs56Blirls56a"

फ़िलहाल, Bearer ही ऐसा प्रीफ़िक्स है जिसका इस्तेमाल किया जा सकता है.

डिफ़ॉल्ट:	धारक
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	धारक
इन कार्रवाइयों के साथ इस्तेमाल किया जाता है:	VerifyAccessToken

<AppEndUser> एलिमेंट

<AppEndUser>request.queryparam.app_enduser</AppEndUser>

कुछ मामलों में, ऐप्लिकेशन के असली उपयोगकर्ता का आईडी, अनुमति देने वाले सर्वर को भेजना ज़रूरी होता है. इस एलिमेंट की मदद से, यह तय किया जा सकता है कि Edge को असली उपयोगकर्ता का आईडी कहां से मिलेगा. उदाहरण के लिए, इसे क्वेरी पैरामीटर या एचटीटीपी हेडर में भेजा जा सकता है.

उदाहरण के लिए, request.queryparam.app_enduser से पता चलता है कि AppEndUser को क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए. उदाहरण के लिए, ?app_enduser=ntesla@theramin.com. अगर आपको एचटीटीपी हेडर में AppEndUser की ज़रूरत है, तो इस वैल्यू को request.header.app_enduser पर सेट करें.

इस सेटिंग को चालू करने पर, ऐक्सेस टोकन में ऐप्लिकेशन के असली उपयोगकर्ता का आईडी शामिल किया जा सकता है. अगर आपको OAuth 2.0 के ऐक्सेस टोकन को वापस लेना है या उन्हें उपयोगकर्ता आईडी के हिसाब से वापस पाना है, तो यह सुविधा आपके लिए मददगार है. ज़्यादा जानकारी के लिए, असली उपयोगकर्ता के आईडी, ऐप्लिकेशन आईडी या दोनों के हिसाब से, OAuth 2.0 ऐक्सेस टोकन को वापस पाने और रद्द करने की सुविधा चालू करना लेख पढ़ें.

डिफ़ॉल्ट:	लागू नहीं
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	कोई भी फ़्लो वैरिएबल, जिसे नीति के ज़रिए रनटाइम में ऐक्सेस किया जा सकता है.
इनके साथ इस्तेमाल किया जाता है:	authorization_code इंप्लिसिट पासवर्ड client_credentials

<Attributes/Attribute>

<Attributes>
    <Attribute name="attr_name1" ref="flow.variable" display="true|false">value1</Attribute>
    <Attribute name="attr_name2" ref="flow.variable" display="true|false">value2</Attribute>
</Attributes>

इस एलिमेंट का इस्तेमाल, ऐक्सेस टोकन या अनुमति कोड में कस्टम एट्रिब्यूट जोड़ने के लिए करें. उदाहरण के लिए, आपको ऐक्सेस टोकन में यूज़र आईडी या सेशन आइडेंटिफ़ायर एम्बेड करना पड़ सकता है. इसे रनटाइम में निकाला और जांचा जा सकता है.

इस एलिमेंट की मदद से, फ़्लो वैरिएबल या लिटरल स्ट्रिंग में वैल्यू तय की जा सकती है. अगर आपने वैरिएबल और स्ट्रिंग, दोनों को तय किया है, तो फ़्लो वैरिएबल में तय की गई वैल्यू का इस्तेमाल किया जाएगा. अगर वैरिएबल को हल नहीं किया जा सकता, तो स्ट्रिंग डिफ़ॉल्ट होती है.

इस एलिमेंट को इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, टोकन और ऑथराइज़ेशन कोड को पसंद के मुताबिक बनाना लेख पढ़ें.

जवाब में कस्टम एट्रिब्यूट दिखाना या छिपाना

ध्यान रखें कि अगर आपने इस नीति के GenerateResponse एलिमेंट को true पर सेट किया है, तो रिस्पॉन्स में टोकन का पूरा JSON वर्शन दिखेगा. इसमें आपके सेट किए गए सभी कस्टम एट्रिब्यूट भी शामिल होंगे. कुछ मामलों में, आपको जवाब में अपने कुछ या सभी कस्टम एट्रिब्यूट छिपाने पड़ सकते हैं, ताकि वे क्लाइंट ऐप्लिकेशन को न दिखें.

डिफ़ॉल्ट रूप से, कस्टम एट्रिब्यूट रिस्पॉन्स में दिखते हैं. अगर आपको उन्हें छिपाना है, तो display पैरामीटर को false पर सेट करें. उदाहरण के लिए:

<Attributes>
    <Attribute name="employee_id" ref="employee.id" display="false"/>
    <Attribute name="employee_name" ref="employee.name" display="false"/>
</Attributes>

display एट्रिब्यूट की वैल्यू सेव नहीं की गई है. मान लें कि आपने कस्टम एट्रिब्यूट वाला एक ऐक्सेस टोकन जनरेट किया है. आपको जनरेट किए गए जवाब में इन एट्रिब्यूट को छिपाना है. display=false को सेट करने से यह लक्ष्य हासिल किया जा सकता है. हालांकि, अगर बाद में रीफ़्रेश टोकन का इस्तेमाल करके नया ऐक्सेस टोकन जनरेट किया जाता है, तो ऐक्सेस टोकन के ओरिजनल कस्टम एट्रिब्यूट, रीफ़्रेश टोकन के जवाब में दिखेंगे. ऐसा इसलिए होता है, क्योंकि Edge को यह याद नहीं रहता कि जनरेट ऐक्सेस टोकन की नीति में display एट्रिब्यूट को मूल रूप से false पर सेट किया गया था. कस्टम एट्रिब्यूट, ऐक्सेस टोकन के मेटाडेटा का हिस्सा होता है.

अगर ऑथराइज़ेशन कोड में कस्टम एट्रिब्यूट जोड़े जाते हैं, तो आपको यही व्यवहार दिखेगा. जब उस कोड का इस्तेमाल करके ऐक्सेस टोकन जनरेट किया जाता है, तो वे कस्टम एट्रिब्यूट, ऐक्सेस टोकन रिस्पॉन्स में दिखेंगे. हालांकि, ऐसा हो सकता है कि आपको ऐसा न करना हो.

इन मामलों में कस्टम एट्रिब्यूट छिपाने के लिए, आपके पास ये विकल्प हैं:

रीफ़्रेश टोकन की नीति में कस्टम एट्रिब्यूट को साफ़ तौर पर रीसेट करें और उनके डिसप्ले को false पर सेट करें. इस मामले में, आपको GetOAuthV2Info नीति का इस्तेमाल करके, ओरिजनल ऐक्सेस टोकन से ओरिजनल कस्टम वैल्यू वापस लानी पड़ सकती हैं.
पोस्टप्रोसेसिंग JavaScript नीति का इस्तेमाल करके, उन सभी कस्टम एट्रिब्यूट को मैन्युअल तरीके से निकालें जिन्हें आपको जवाब में नहीं दिखाना है.

टोकन और अनुमति देने के कोड को पसंद के मुताबिक बनाना भी देखें.

डिफ़ॉल्ट:	`N/A`
मौजूदगी:	वैकल्पिक
मान्य वैल्यू:	`name` -एट्रिब्यूट का नाम `ref` - एट्रिब्यूट की वैल्यू. यह फ़्लो वैरिएबल से मिल सकता है. `display` - (ज़रूरी नहीं) इससे यह तय किया जा सकता है कि जवाब में कस्टम एट्रिब्यूट दिखें या नहीं. अगर `true`, तो जवाब में कस्टम एट्रिब्यूट दिखते हैं (अगर `GenerateResponse` भी चालू है). अगर `false` है, तो जवाब में कस्टम एट्रिब्यूट शामिल नहीं किए जाते. डिफ़ॉल्ट वैल्यू `true` है. जवाब में कस्टम एट्रिब्यूट दिखाने या छिपाने के बारे में जानकारी देखें.
इनके साथ इस्तेमाल किया जाता है:	authorization_code इंप्लिसिट पासवर्ड client_credentials refresh_token इसका इस्तेमाल, GenerateAuthorizationCode ऑपरेशन के साथ भी किया जा सकता है.

<ClientId> एलिमेंट

<ClientId>request.formparam.client_id</ClientId>

कई मामलों में, क्लाइंट ऐप्लिकेशन को अनुमति देने वाले सर्वर को क्लाइंट आईडी भेजना होता है. इस एलिमेंट से पता चलता है कि Apigee को फ़्लो वैरिएबल request.formparam.client_id में क्लाइंट आईडी ढूंढना चाहिए. ClientId को किसी अन्य वैरिएबल पर सेट नहीं किया जा सकता. ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना भी देखें.

डिफ़ॉल्ट:	request.formparam.client_id (यह x-www-form-urlencoded है और इसे अनुरोध के मुख्य हिस्से में बताया गया है)
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	फ़्लो वैरिएबल: `request.formparam.client_id`
इनके साथ इस्तेमाल किया जाता है:	authorization_code पासवर्ड इंप्लिसिट client_credentials इसका इस्तेमाल, GenerateAuthorizationCode ऑपरेशन के साथ भी किया जा सकता है.

<Code> एलिमेंट

<Code>request.queryparam.code</Code>

ऑथराइज़ेशन ग्रांट टाइप फ़्लो में, क्लाइंट को ऑथराइज़ेशन सर्वर (Apigee Edge) को ऑथराइज़ेशन कोड सबमिट करना होगा. इस एलिमेंट की मदद से, यह तय किया जा सकता है कि Edge को अनुमति कोड कहां से लेना चाहिए. उदाहरण के लिए, इसे क्वेरी पैरामीटर, एचटीटीपी हेडर या फ़ॉर्म पैरामीटर (डिफ़ॉल्ट) के तौर पर भेजा जा सकता है.

वैरिएबल request.queryparam.auth_code से पता चलता है कि अनुमति देने वाला कोड, क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए. जैसे, ?auth_code=AfGlvs9. अगर आपको एचटीटीपी हेडर में अनुमति कोड की ज़रूरत है, तो इस वैल्यू को request.header.auth_code पर सेट करें. ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना भी देखें.

डिफ़ॉल्ट:	request.formparam.code (यह x-www-form-urlencoded है और इसे अनुरोध के मुख्य हिस्से में बताया गया है)
मौजूदगी:	ज़रूरी नहीं
टाइप:	स्ट्रिंग
मान्य वैल्यू:	कोई भी फ़्लो वैरिएबल, जिसे नीति के ज़रिए रनटाइम में ऐक्सेस किया जा सकता है
इनके साथ इस्तेमाल किया जाता है:	authorization_code

<ExpiresIn> एलिमेंट

<ExpiresIn>10000</ExpiresIn>

यह कुकी, ऐक्सेस टोकन और ऑथराइज़ेशन कोड के खत्म होने की समयसीमा को मिलीसेकंड में लागू करती है. (रीफ़्रेश टोकन के लिए, <RefreshTokenExpiresIn> का इस्तेमाल करें.) खत्म होने के समय की वैल्यू, सिस्टम से जनरेट होने वाली वैल्यू के साथ-साथ <ExpiresIn> वैल्यू भी होती है. अगर <ExpiresIn> को -1 पर सेट किया जाता है, तो टोकन या कोड की समयसीमा OAuth ऐक्सेस टोकन की ज़्यादा से ज़्यादा समयसीमा के हिसाब से खत्म हो जाती है. अगर <ExpiresIn> की वैल्यू नहीं दी जाती है, तो सिस्टम, सिस्टम लेवल पर कॉन्फ़िगर की गई डिफ़ॉल्ट वैल्यू लागू करता है.

एक्सपायरी का समय, रनटाइम पर भी सेट किया जा सकता है. इसके लिए, हार्ड-कोड की गई डिफ़ॉल्ट वैल्यू का इस्तेमाल करें या फ़्लो वैरिएबल को रेफ़रंस करें. उदाहरण के लिए, टोकन की समयसीमा खत्म होने की वैल्यू को की वैल्यू मैप में सेव किया जा सकता है. इसके बाद, इसे वापस पाया जा सकता है, किसी वैरिएबल को असाइन किया जा सकता है, और नीति में इसका रेफ़रंस दिया जा सकता है. उदाहरण के लिए, kvm.oauth.expires_in.

Apigee Edge for Public Cloud के साथ, Edge इन इकाइयों को कम से कम 180 सेकंड के लिए कैश मेमोरी में सेव रखता है. ऐसा तब होता है, जब इन इकाइयों को ऐक्सेस किया जाता है.

OAuth ऐक्सेस टोकन. इसका मतलब है कि रद्द किया गया टोकन, तीन मिनट तक काम कर सकता है. ऐसा तब तक होता है, जब तक उसकी कैश मेमोरी की समयसीमा खत्म नहीं हो जाती.
Key Management Service (KMS) इकाइयां (ऐप्लिकेशन, डेवलपर, एपीआई प्रॉडक्ट).
OAuth टोकन और KMS इकाइयों पर कस्टम एट्रिब्यूट.

यहां दिए गए स्टैंज़ा में, फ़्लो वैरिएबल और डिफ़ॉल्ट वैल्यू के बारे में बताया गया है. ध्यान दें कि फ़्लो वैरिएबल की वैल्यू को, तय की गई डिफ़ॉल्ट वैल्यू से ज़्यादा प्राथमिकता दी जाती है.

<ExpiresIn ref="kvm.oauth.expires_in">
    3600000 <!--default value in milliseconds-->
</ExpiresIn>

Edge में, टोकन बनाने के बाद उसकी समयसीमा को तुरंत खत्म करने का कोई तरीका नहीं है. अगर आपको किसी शर्त के आधार पर टोकन की समयसीमा खत्म करनी है, तो Apigee Community की इस पोस्ट में इसका तरीका बताया गया है.

डिफ़ॉल्ट रूप से, समयसीमा खत्म हो चुके ऐक्सेस टोकन, Apigee Edge सिस्टम से समयसीमा खत्म होने के तीन दिन बाद अपने-आप हटा दिए जाते हैं. ऐक्सेस टोकन मिटाना भी देखें

Private Cloud: Edge for Private Cloud इंस्टॉलेशन के लिए, डिफ़ॉल्ट वैल्यू को conf_keymanagement_oauth_auth_code_expiry_time_in_millis प्रॉपर्टी सेट करती है. इस प्रॉपर्टी को सेट करने के लिए:

message-processor.properties फ़ाइल को किसी एडिटर में खोलें. अगर फ़ाइल मौजूद नहीं है, तो इसे बनाएं:
```
vi /opt/apigee/customer/application/message-processor.properties
```
अपनी ज़रूरत के हिसाब से प्रॉपर्टी सेट करें:
```
conf_keymanagement_oauth_auth_code_expiry_time_in_millis=3600000
```
पक्का करें कि प्रॉपर्टी फ़ाइल का मालिकाना हक "apigee" उपयोगकर्ता के पास हो:
```
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
```
मैसेज प्रोसेसर को रीस्टार्ट करें.
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

डिफ़ॉल्ट:	अगर यह वैल्यू नहीं दी जाती है, तो सिस्टम के लेवल पर कॉन्फ़िगर की गई डिफ़ॉल्ट वैल्यू लागू होती है.
मौजूदगी:	वैकल्पिक
टाइप:	पूर्णांक
मान्य वैल्यू:	कोई भी धनात्मक पूर्णांक, जो शून्य न हो. समयसीमा को मिलीसेकंड में बताएं. इस एलिमेंट की वैल्यू मिलीसेकंड में होती है. हालांकि, टोकन की `expires_in` प्रॉपर्टी और `expires_in` फ़्लो वैरिएबल में सेट की गई वैल्यू को सेकंड में दिखाया जाता है. -1 की समयसीमा, OAuth ऐक्सेस टोकन की ज़्यादा से ज़्यादा समयसीमा के हिसाब से खत्म हो जाएगी. ध्यान दें: कोई अन्य नेगेटिव पूर्णांक या शून्य तय करने पर, डिप्लॉयमेंट से जुड़ी गड़बड़ी होती है. ऐंटीपैटर्न: OAuth टोकन के लिए लंबी समयसीमा सेट करना भी देखें.
इनके साथ इस्तेमाल किया जाता है:	authorization_code इंप्लिसिट पासवर्ड client_credentials refresh_token इसका इस्तेमाल GenerateAuthorizationCode ऑपरेशन के साथ भी किया जाता है.

ध्यान दें: ध्यान दें कि अगर ExpiresIn को -1 पर सेट किया जाता है, तो आपको जनरेट किए गए टोकन में समयसीमा खत्म होने की यह वैल्यू दिखेगी:

"expires_in" :
  "0"

<ExternalAccessToken> एलिमेंट

<ExternalAccessToken>request.queryparam.external_access_token</ExternalAccessToken>

Apigee Edge को बताता है कि बाहरी ऐक्सेस टोकन कहां मिलेगा. यह ऐसा ऐक्सेस टोकन होता है जिसे Apigee Edge ने जनरेट नहीं किया होता.

request.queryparam.external_access_token वैरिएबल से पता चलता है कि बाहरी ऐक्सेस टोकन को क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए. उदाहरण के लिए, ?external_access_token=12345678. अगर आपको एचटीटीपी हेडर में बाहरी ऐक्सेस टोकन की ज़रूरत है, तो इस वैल्यू को request.header.external_access_token पर सेट करें. तीसरे पक्ष के OAuth टोकन इस्तेमाल करना लेख भी पढ़ें.

<ExternalAuthorization> एलिमेंट

<ExternalAuthorization>true</ExternalAuthorization>

अगर यह एलिमेंट 'गलत है' पर सेट है या मौजूद नहीं है, तो Edge, Apigee Edge के अनुमति देने वाले स्टोर के हिसाब से client_id और client_secret की पुष्टि करता है. तीसरे पक्ष के OAuth टोकन के साथ काम करने के लिए, इस एलिमेंट का इस्तेमाल करें. इस एलिमेंट को इस्तेमाल करने के बारे में जानकारी पाने के लिए, तीसरे पक्ष के OAuth टोकन इस्तेमाल करना लेख पढ़ें.

डिफ़ॉल्ट:	गलत
मौजूदगी:	वैकल्पिक
टाइप:	बूलियन
मान्य वैल्यू:	सही या गलत
इनके साथ इस्तेमाल किया जाता है:	authorization_code पासवर्ड client_credentials

<ExternalAuthorizationCode> एलिमेंट

<ExternalAuthorizationCode>request.queryparam.external_auth_code</ExternalAuthorizationCode>

Apigee Edge को बताता है कि बाहरी अनुमति कोड (Apigee Edge से जनरेट नहीं किया गया अनुमति कोड) कहां मिलेगा.

वैरिएबल request.queryparam.external_auth_code से पता चलता है कि बाहरी पुष्टि करने का कोड, क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए. उदाहरण के लिए, ?external_auth_code=12345678. अगर आपको एचटीटीपी हेडर में बाहरी पुष्टि करने वाले कोड की ज़रूरत है, तो इस वैल्यू को request.header.external_auth_code पर सेट करें. तीसरे पक्ष के OAuth टोकन इस्तेमाल करना लेख भी पढ़ें.

<ExternalRefreshToken> एलिमेंट

<ExternalRefreshToken>request.queryparam.external_refresh_token</ExternalRefreshToken>

इस विकल्प से Apigee Edge को यह पता चलता है कि बाहरी रीफ़्रेश टोकन (Apigee Edge से जनरेट न किया गया रीफ़्रेश टोकन) कहां मिलेगा.

request.queryparam.external_refresh_token वैरिएबल से पता चलता है कि बाहरी रीफ़्रेश टोकन को क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए. उदाहरण के लिए, ?external_refresh_token=12345678. अगर आपको एचटीटीपी हेडर में बाहरी रीफ़्रेश टोकन की ज़रूरत है, तो इस वैल्यू को request.header.external_refresh_token पर सेट करें. तीसरे पक्ष के OAuth टोकन इस्तेमाल करना लेख भी पढ़ें.

<GenerateResponse> एलिमेंट

<GenerateResponse enabled='true'/>

true पर सेट होने पर, नीति जवाब जनरेट करती है और उसे वापस भेजती है. उदाहरण के लिए, GenerateAccessToken के लिए जवाब ऐसा हो सकता है:

{
  "issued_at" : "1467841035013",
  "scope" : "read",
  "application_name" : "e31b8d06-d538-4f6b-9fe3-8796c11dc930",
  "refresh_token_issued_at" : "1467841035013",
  "status" : "approved",
  "refresh_token_status" : "approved",
  "api_product_list" : "[Product1, nhl_product]",
  "expires_in" : "1799",
  "developer.email" : "edward@slalom.org",
  "token_type" : "BearerToken",
  "refresh_token" : "rVSmm3QaNa0xBVFbUISz1NZI15akvgLJ",
  "client_id" : "Adfsdvoc7KX5Gezz9le745UEql5dDmj",
  "access_token" : "AnoHsh2oZ6EFWF4h0KrA0gC5og3a",
  "organization_name" : "cerruti",
  "refresh_token_expires_in" : "0",
  "refresh_count" : "0"
}

अगर false, तो कोई जवाब नहीं भेजा जाता है. इसके बजाय, फ़्लो वैरिएबल के सेट में, नीति के फ़ंक्शन से जुड़ी वैल्यू भरी जाती हैं. उदाहरण के लिए, oauthv2authcode.OAuthV2-GenerateAuthorizationCode.code नाम का फ़्लो वैरिएबल, नए ऑथराइज़ेशन कोड से भर जाता है. ध्यान दें कि जवाब में expires_in की वैल्यू सेकंड में होती है.

डिफ़ॉल्ट:	गलत
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	सही या गलत
इनके साथ इस्तेमाल किया जाता है:	इंप्लिसिट पासवर्ड client_credentials refresh_token इसका इस्तेमाल GenerateAuthorizationCode ऑपरेशन के साथ भी किया जा सकता है.

<GenerateErrorResponse> एलिमेंट

<GenerateErrorResponse enabled='true'/>

true पर सेट होने पर, नीति जवाब जनरेट करती है और उसे तब दिखाती है, जब ContinueOnError एट्रिब्यूट को सही पर सेट किया गया हो. अगर false (डिफ़ॉल्ट) है, तो कोई जवाब नहीं भेजा जाता है. इसके बजाय, फ़्लो वैरिएबल के सेट में, नीति के फ़ंक्शन से जुड़ी वैल्यू अपने-आप भर जाती हैं.

डिफ़ॉल्ट:	गलत
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	सही या गलत
इनके साथ इस्तेमाल किया जाता है:	इंप्लिसिट पासवर्ड client_credentials refresh_token इसका इस्तेमाल GenerateAuthorizationCode ऑपरेशन के साथ भी किया जा सकता है.

<GrantType>

<GrantType>request.queryparam.grant_type</GrantType>

इस नीति से यह पता चलता है कि अनुरोध में पास किए गए ग्रांट टाइप पैरामीटर को कहां ढूंढना है. OAuth 2.0 स्पेसिफ़िकेशन के मुताबिक, ऐक्सेस टोकन और ऑथराइज़ेशन कोड के अनुरोधों के साथ, अनुमति के टाइप की जानकारी देना ज़रूरी है. यह वैरिएबल, हेडर, क्वेरी पैरामीटर या फ़ॉर्म पैरामीटर (डिफ़ॉल्ट) हो सकता है.

उदाहरण के लिए, request.queryparam.grant_type से पता चलता है कि Password को क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए. जैसे, ?grant_type=password. अगर आपको एचटीटीपी हेडर में ग्रांट टाइप की ज़रूरत है, तो इस वैल्यू को request.header.grant_type पर सेट करें. ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना भी देखें.

डिफ़ॉल्ट:	request.formparam.grant_type (a x-www-form-urlencoded and specified in the request body)
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	ऊपर बताया गया वैरिएबल.
इनके साथ इस्तेमाल किया जाता है:	authorization_code पासवर्ड इंप्लिसिट client_credentials refresh_token

<Operation> एलिमेंट

<Operation>GenerateAuthorizationCode</Operation>

नीति के ज़रिए OAuth 2.0 ऑपरेशन को लागू किया गया.

डिफ़ॉल्ट:	अगर `<Operation>` के बारे में जानकारी नहीं दी गई है, तो Edge, `<SupportedGrantTypes>` की सूची देखता है. सिर्फ़ उन ग्रांट टाइप पर कार्रवाइयां पूरी की जा सकेंगी. दूसरे शब्दों में, अगर आपने `<SupportedGrantTypes>` सूची में `<GrantType>` एट्रिब्यूट की वैल्यू दी है, तो `<Operation>` एट्रिब्यूट को शामिल करने की ज़रूरत नहीं है. अगर `<Operation>` या `<SupportedGrantTypes>` में से किसी को भी नहीं चुना जाता है, तो डिफ़ॉल्ट रूप से grant type, authorization_code होता है. इसका मतलब है कि authorization_code grant type के अनुरोध पूरे किए जाएंगे, लेकिन अन्य सभी अनुरोध पूरे नहीं किए जाएंगे.
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	`GenerateAccessToken` - ऐक्सेस टोकन जनरेट करता है. ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना भी देखें. `GenerateAccessTokenImplicitGrant` - यह इंप्लिसिट ग्रांट टाइप के लिए ऐक्सेस टोकन जनरेट करता है. ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना भी देखें. `GenerateAuthorizationCode` - यह अनुमति कोड जनरेट करता है. इसका इस्तेमाल, ऑथराइज़ेशन कोड ग्रांट टाइप के साथ किया जाता है. ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना भी देखें. `RefreshAccessToken` - रीफ़्रेश टोकन को नए ऐक्सेस टोकन के लिए एक्सचेंज करें. ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना भी देखें. `VerifyAccessToken` - इससे यह पुष्टि की जाती है कि अनुरोध में भेजा गया ऐक्सेस टोकन मान्य है. ऊपर VerifyAccessToken का सैंपल और "ऐक्सेस टोकन की पुष्टि करना" देखें. `InvalidateToken` - ऐक्सेस टोकन रद्द करता है. टोकन रद्द होने के बाद, क्लाइंट उस टोकन का इस्तेमाल करके सुरक्षित एपीआई को कॉल नहीं कर सकते. ऐक्सेस टोकन को मंज़ूरी देने और उन्हें रद्द करने के बारे में भी जानें. `ValidateToken` - यह पहले रद्द किए गए ऐक्सेस टोकन को फिर से चालू करता है या "स्वीकार करता है". ऐक्सेस टोकन को मंज़ूरी देने और उन्हें रद्द करने के बारे में भी जानें.

<PassWord> एलिमेंट

<PassWord>request.queryparam.password</PassWord>

इस एलिमेंट का इस्तेमाल सिर्फ़ पासवर्ड ग्रांट टाइप के साथ किया जाता है. पासवर्ड ग्रांट टाइप के साथ, उपयोगकर्ता के क्रेडेंशियल (पासवर्ड और उपयोगकर्ता नाम) को OAuthV2 नीति के लिए उपलब्ध कराया जाना चाहिए. <PassWord> और <UserName> एलिमेंट का इस्तेमाल, उन वैरिएबल को तय करने के लिए किया जाता है जिनमें Edge को ये वैल्यू मिल सकती हैं. अगर इन एलिमेंट के बारे में नहीं बताया जाता है, तो नीति के तहत डिफ़ॉल्ट रूप से, username और password नाम वाले फ़ॉर्म पैरामीटर में वैल्यू मिलनी चाहिए. अगर वैल्यू नहीं मिलती हैं, तो नीति से जुड़ी गड़बड़ी दिखती है. क्रेडेंशियल वाले किसी भी फ़्लो वैरिएबल को रेफ़रंस देने के लिए, <PassWord> और <UserName> एलिमेंट का इस्तेमाल किया जा सकता है.

उदाहरण के लिए, क्वेरी पैरामीटर का इस्तेमाल करके, टोकन के अनुरोध में पासवर्ड पास किया जा सकता है. साथ ही, इस एलिमेंट को इस तरह सेट किया जा सकता है: <PassWord>request.queryparam.password</PassWord>. एचटीटीपी हेडर में पासवर्ड की ज़रूरत होने पर, इस वैल्यू को request.header.password पर सेट करें.

OAuthV2 नीति, क्रेडेंशियल की इन वैल्यू के साथ कोई और कार्रवाई नहीं करती है. Edge सिर्फ़ यह पुष्टि करता है कि ये वैल्यू मौजूद हैं. एपीआई डेवलपर को, टोकन जनरेट करने की नीति लागू होने से पहले, वैल्यू के अनुरोध को वापस पाना होता है और उन्हें पहचान देने वाली कंपनी को भेजना होता है.

ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना भी देखें.

डिफ़ॉल्ट:	request.formparam.password (a x-www-form-urlencoded and specified in the request body)
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	रनटाइम के दौरान, नीति के लिए उपलब्ध कोई भी फ़्लो वैरिएबल.
इनके साथ इस्तेमाल किया जाता है:	पासवर्ड

<RedirectUri> एलिमेंट

<RedirectUri>request.queryparam.redirect_uri</RedirectUri>

इससे यह पता चलता है कि Edge को अनुरोध में redirect_uri पैरामीटर कहां खोजना चाहिए.

रीडायरेक्शन यूआरआई के बारे में जानकारी

रीडायरेक्ट यूआरआई का इस्तेमाल, ऑथराइज़ेशन कोड और इंप्लिसिट ग्रांट टाइप के साथ किया जाता है. रीडायरेक्ट यूआरआई, ऑथराइज़ेशन सर्वर (Edge) को बताता है कि ऑथराइज़ेशन कोड (ऑथराइज़ेशन कोड ग्रांट टाइप के लिए) या ऐक्सेस टोकन (इंप्लिसिट ग्रांट टाइप के लिए) कहां भेजना है. यह समझना ज़रूरी है कि इस पैरामीटर को कब शामिल करना ज़रूरी है, कब यह वैकल्पिक होता है, और इसका इस्तेमाल कैसे किया जाता है:

(ज़रूरी है) अगर अनुरोध के क्लाइंट कुंजियों से जुड़े डेवलपर ऐप्लिकेशन के साथ कोई कॉलबैक यूआरएल रजिस्टर किया गया है और अनुरोध में redirect_uri मौजूद है, तो दोनों पूरी तरह से मेल खाने चाहिए. अगर ये मेल नहीं खाते हैं, तो गड़बड़ी का मैसेज दिखता है. Edge पर डेवलपर ऐप्लिकेशन रजिस्टर करने और कॉलबैक यूआरएल तय करने के बारे में जानकारी पाने के लिए, ऐप्लिकेशन रजिस्टर करना और एपीआई कुंजियां मैनेज करना लेख पढ़ें.
ध्यान दें: यह पक्का करने के लिए कि Edge, "रीडायरेक्ट यूआरआई" और "कॉलबैक यूआरएल" के बीच फ़ॉरवर्ड मैच के बजाय सटीक मैच की जांच करे, अपने संगठन में यह प्रॉपर्टी सेट करें: features.isStrictOAuthUriValidation = true. डिफ़ॉल्ट रूप से, यह फ़ॉरवर्ड मैच के लिए false पर सेट होता है.
अगर आप क्लाउड ग्राहक हैं, तो प्रॉपर्टी चालू करने के लिए Apigee Edge की सहायता टीम से संपर्क करें. अगर आप Apigee Edge for Private Cloud के ग्राहक हैं, तो सिस्टम एडमिन के क्रेडेंशियल का इस्तेमाल करके, यहां दिए गए एपीआई PUT कॉल की मदद से फ़्लैग सेट करें.
```
curl -u email:password -X PUT -H "Content-type:application/xml" http://host:port/v1/o/{myorg} -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isStrictOAuthUriValidation">true</Property>
        
    </Properties>
</Organization>"
```
चेतावनी: एपीआई कॉल की मदद से संगठन की जानकारी अपडेट करते समय, पक्का करें कि आपने पेलोड में संगठन की सभी मौजूदा प्रॉपर्टी शामिल की हों. ऐसा न करने पर, संगठन की सभी मौजूदा प्रॉपर्टी को उन प्रॉपर्टी से बदल दिया जाएगा जिन्हें आपने इस कॉल के ज़रिए सेट किया है.
(ज़रूरी नहीं) अगर कोई कॉलबैक यूआरएल रजिस्टर किया गया है और अनुरोध में redirect_uri मौजूद नहीं है, तो Edge, रजिस्टर किए गए कॉलबैक यूआरएल पर रीडायरेक्ट करता है.
(ज़रूरी है) अगर कोई कॉलबैक यूआरएल रजिस्टर नहीं किया गया है, तो redirect_uri का इस्तेमाल करना ज़रूरी है. ध्यान दें कि इस मामले में, Edge किसी भी यूआरएल को स्वीकार करेगा. इस मामले में सुरक्षा से जुड़ी समस्या हो सकती है. इसलिए,इसका इस्तेमाल सिर्फ़ भरोसेमंद क्लाइंट ऐप्लिकेशन के साथ किया जाना चाहिए. अगर क्लाइंट ऐप्लिकेशन पर भरोसा नहीं किया जाता है, तो सबसे सही तरीका यह है कि हमेशा कॉलबैक यूआरएल के रजिस्ट्रेशन की ज़रूरत हो.

इस पैरामीटर को क्वेरी पैरामीटर या हेडर में भेजा जा सकता है. request.queryparam.redirect_uri वैरिएबल से पता चलता है कि RedirectUri को क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए. उदाहरण के लिए, ?redirect_uri=login.myapp.com. अगर आपको एचटीटीपी हेडर में RedirectUri की ज़रूरत है, तो इस वैल्यू को request.header.redirect_uri पर सेट करें. ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना भी देखें.

डिफ़ॉल्ट:	request.formparam.redirect_uri (यह x-www-form-urlencoded है और अनुरोध के मुख्य हिस्से में दिया गया है)
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	कोई भी फ़्लो वैरिएबल, जिसे रनटाइम के दौरान नीति में ऐक्सेस किया जा सकता है
इनके साथ इस्तेमाल किया जाता है:	authorization_code इंप्लिसिट इसका इस्तेमाल GenerateAuthorizationCode ऑपरेशन के साथ भी किया जाता है.

<RefreshToken> एलिमेंट

<RefreshToken>request.queryparam.refreshtoken</RefreshToken>

रीफ़्रेश टोकन का इस्तेमाल करके ऐक्सेस टोकन का अनुरोध करते समय, आपको अनुरोध में रीफ़्रेश टोकन देना होगा. इस एलिमेंट की मदद से, यह तय किया जा सकता है कि Edge को रीफ़्रेश टोकन कहां ढूंढना चाहिए. उदाहरण के लिए, इसे क्वेरी पैरामीटर, एचटीटीपी हेडर या फ़ॉर्म पैरामीटर (डिफ़ॉल्ट) के तौर पर भेजा जा सकता है.

request.queryparam.refreshtoken वैरिएबल से पता चलता है कि रीफ़्रेश टोकन को क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए. उदाहरण के लिए, ?refresh_token=login.myapp.com. अगर आपको एचटीटीपी हेडर में RefreshToken की ज़रूरत है, तो इस वैल्यू को request.header.refresh_token पर सेट करें. ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना भी देखें.

डिफ़ॉल्ट:	request.formparam.refresh_token (a x-www-form-urlencoded and specified in the request body)
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	कोई भी फ़्लो वैरिएबल, जिसे रनटाइम के दौरान नीति में ऐक्सेस किया जा सकता है
इनके साथ इस्तेमाल किया जाता है:	refresh_token

<RefreshTokenExpiresIn> एलिमेंट

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

यह कुकी, रीफ़्रेश टोकन की समयसीमा को मिलीसेकंड में लागू करती है. कुकी के खत्म होने के समय की वैल्यू, सिस्टम से जनरेट की गई वैल्यू और <RefreshTokenExpiresIn> वैल्यू को मिलाकर बनती है. अगर <RefreshTokenExpiresIn> को -1 पर सेट किया जाता है, तो रीफ़्रेश टोकन की समयसीमा OAuth रीफ़्रेश टोकन की ज़्यादा से ज़्यादा समयसीमा के हिसाब से खत्म हो जाती है. अगर <RefreshTokenExpiresIn> की वैल्यू नहीं दी जाती है, तो सिस्टम, सिस्टम लेवल पर कॉन्फ़िगर की गई डिफ़ॉल्ट वैल्यू लागू करता है. सिस्टम की डिफ़ॉल्ट सेटिंग के बारे में ज़्यादा जानकारी पाने के लिए, Apigee Edge की सहायता टीम से संपर्क करें.

<RefreshTokenExpiresIn ref="kvm.oauth.expires_in">
    3600000 <!--default value in milliseconds-->
</RefreshTokenExpiresIn>

Private Cloud: Edge for Private Cloud इंस्टॉलेशन के लिए, डिफ़ॉल्ट वैल्यू को conf_keymanagement_oauth_refresh_token_expiry_time_in_millis प्रॉपर्टी सेट करती है. इस प्रॉपर्टी को सेट करने के लिए:

message-processor.properties फ़ाइल को किसी एडिटर में खोलें. अगर फ़ाइल मौजूद नहीं है, तो इसे बनाएं:
```
vi /opt/apigee/customer/application/message-processor.properties
```
अपनी ज़रूरत के हिसाब से प्रॉपर्टी सेट करें:
```
conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
```
पक्का करें कि प्रॉपर्टी फ़ाइल का मालिकाना हक "apigee" उपयोगकर्ता के पास हो:
```
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
```
मैसेज प्रोसेसर को रीस्टार्ट करें.
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

डिफ़ॉल्ट:	63072000000 मि॰से॰ (दो साल) (5 अगस्त, 2024 से लागू)
मौजूदगी:	वैकल्पिक
टाइप:	पूर्णांक
मान्य वैल्यू:	कोई भी धनात्मक पूर्णांक, जो शून्य न हो. यह कुकी के खत्म होने का समय मिलीसेकंड में तय करता है. -1 की समयसीमा, OAuth रीफ़्रेश टोकन की ज़्यादा से ज़्यादा समयसीमा खत्म होने की तारीख के हिसाब से खत्म हो जाएगी. ध्यान दें: कोई अन्य नेगेटिव पूर्णांक या शून्य तय करने पर, डिप्लॉयमेंट से जुड़ी गड़बड़ी होती है. ऐंटीपैटर्न: OAuth टोकन के लिए लंबी समयसीमा सेट करना भी देखें.
इनके साथ इस्तेमाल किया जाता है:	authorization_code पासवर्ड refresh_token

<ResponseType> एलिमेंट

<ResponseType>request.queryparam.response_type</ResponseType>

इस एलिमेंट से Edge को पता चलता है कि क्लाइंट ऐप्लिकेशन किस तरह के ऐक्सेस का अनुरोध कर रहा है. इसका इस्तेमाल सिर्फ़ ऑथराइज़ेशन कोड और इंप्लिसिट ग्रांट टाइप फ़्लो के साथ किया जाता है.

डिफ़ॉल्ट रूप से, Edge, response_type क्वेरी पैरामीटर में जवाब के टाइप की वैल्यू ढूंढता है. अगर आपको इस डिफ़ॉल्ट व्यवहार को बदलना है, तो <ResponseType> एलिमेंट का इस्तेमाल करके, फ़्लो वैरिएबल को कॉन्फ़िगर करें. इसमें रिस्पॉन्स टाइप की वैल्यू शामिल होती है. उदाहरण के लिए, अगर आपने इस एलिमेंट को request.header.response_type पर सेट किया है, तो Edge अनुरोध के हेडर में पास किए जाने वाले जवाब के टाइप को खोजता है. ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना भी देखें.

डिफ़ॉल्ट:	request.formparam.response_type (a x-www-form-urlencoded and specified in the request body)
मौजूदगी:	ज़रूरी नहीं. अगर आपको डिफ़ॉल्ट सेटिंग को बदलना है, तो इस एलिमेंट का इस्तेमाल करें.
टाइप:	स्ट्रिंग
मान्य वैल्यू:	`code` (ऑथराइज़ेशन कोड ग्रांट टाइप के लिए) या `token` (इंप्लिसिट ग्रांट टाइप के लिए)
इनके साथ इस्तेमाल किया जाता है:	इंप्लिसिट इसका इस्तेमाल GenerateAuthorizationCode ऑपरेशन के साथ भी किया जाता है.

<ReuseRefreshToken> एलिमेंट

<ReuseRefreshToken>true</ReuseRefreshToken>

true पर सेट होने पर, मौजूदा रीफ़्रेश टोकन का इस्तेमाल तब तक किया जाता है, जब तक उसकी समयसीमा खत्म नहीं हो जाती. अगर false है, तो मान्य रीफ़्रेश टोकन सबमिट करने पर, Apigee Edge एक नया रीफ़्रेश टोकन जारी करता है.

डिफ़ॉल्ट:	`false`
मौजूदगी:	ज़रूरी नहीं
टाइप:	बूलियन
मान्य वैल्यू:	`true` या `false`
इस ग्रांट टाइप के साथ इस्तेमाल किया जाता है:	refresh_token

<Scope> एलिमेंट

<Scope>request.queryparam.scope</Scope>

अगर यह एलिमेंट, GenerateAccessToken या GenerateAuthorizationCode में से किसी एक नीति में मौजूद है, तो इसका इस्तेमाल यह बताने के लिए किया जाता है कि टोकन या कोड को कौनसे स्कोप दिए जाएं. ये वैल्यू आम तौर पर, क्लाइंट ऐप्लिकेशन से किए गए अनुरोध में नीति को पास की जाती हैं. एलिमेंट को फ़्लो वैरिएबल लेने के लिए कॉन्फ़िगर किया जा सकता है. इससे आपको यह चुनने का विकल्प मिलता है कि अनुरोध में स्कोप कैसे पास किए जाएं. यहां दिए गए उदाहरण में, request.queryparam.scope से पता चलता है कि स्कोप को क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए. जैसे, ?scope=READ. अगर आपको एचटीटीपी हेडर में स्कोप की ज़रूरत है, तो इस वैल्यू को request.header.scope पर सेट करें.

अगर यह एलिमेंट "VerifyAccessToken" नीति में दिखता है, तो इसका इस्तेमाल यह तय करने के लिए किया जाता है कि नीति को किन स्कोप पर लागू करना चाहिए. इस तरह की नीति में, वैल्यू को "हार्ड कोड" किया गया स्कोप का नाम होना चाहिए. इसमें वैरिएबल का इस्तेमाल नहीं किया जा सकता. उदाहरण के लिए:

<Scope>A B</Scope>

OAuth2 के स्कोप के साथ काम करना और ऐक्सेस टोकन और ऑथराइज़ेशन कोड का अनुरोध करना लेख भी पढ़ें.

डिफ़ॉल्ट:	कोई स्कोप नहीं है
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	Generate* नीतियों के साथ इस्तेमाल किया जाने वाला फ़्लो वैरिएबल. VerifyAccessToken के साथ इस्तेमाल करने पर, स्कोप के नामों (स्ट्रिंग) की स्पेस से अलग की गई सूची.
इनके साथ इस्तेमाल किया जाता है:	authorization_code इंप्लिसिट पासवर्ड client_credentials इसका इस्तेमाल GenerateAuthorizationCode और VerifyAccessToken ऑपरेशन के साथ भी किया जा सकता है.

<State> एलिमेंट

<State>request.queryparam.state</State>

ऐसे मामलों में जहां क्लाइंट ऐप्लिकेशन को राज्य की जानकारी, अनुमति देने वाले सर्वर को भेजनी होती है वहां यह एलिमेंट आपको यह तय करने की सुविधा देता है कि Edge को राज्य की वैल्यू कहां से लेनी चाहिए. उदाहरण के लिए, इसे क्वेरी पैरामीटर के तौर पर या एचटीटीपी हेडर में भेजा जा सकता है. स्टेट वैल्यू का इस्तेमाल आम तौर पर सुरक्षा से जुड़े उपाय के तौर पर किया जाता है, ताकि सीएसआरएफ़ हमलों को रोका जा सके.

उदाहरण के लिए, request.queryparam.state से पता चलता है कि राज्य को क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए. जैसे, ?state=HjoiuKJH32. अगर आपको एचटीटीपी हेडर में राज्य की जानकारी देना ज़रूरी है, तो इस वैल्यू को request.header.state पर सेट करें. यह भी देखें: ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना.

डिफ़ॉल्ट:	किसी भी राज्य की जानकारी नहीं है
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	कोई भी फ़्लो वैरिएबल, जिसे नीति के ज़रिए रनटाइम में ऐक्सेस किया जा सकता है
इनके साथ इस्तेमाल किया जाता है:	सभी इसका इस्तेमाल, GenerateAuthorizationCode ऑपरेशन के साथ भी किया जा सकता है

<StoreToken> एलिमेंट

 <StoreToken>true</StoreToken>

जब <ExternalAuthorization> एलिमेंट true हो, तब इस एलिमेंट को true पर सेट करें. <StoreToken> एलिमेंट, Apigee Edge को बाहरी ऐक्सेस टोकन सेव करने के लिए कहता है. ऐसा न करने पर, यह सेव नहीं होगा.

डिफ़ॉल्ट:	गलत
मौजूदगी:	वैकल्पिक
टाइप:	बूलियन
मान्य वैल्यू:	सही या गलत
इनके साथ इस्तेमाल किया जाता है:	authorization_code पासवर्ड client_credentials

<SupportedGrantTypes>/<GrantType> element

<SupportedGrantTypes>
    <GrantType>authorization_code</GrantType>
    <GrantType>client_credentials</GrantType>
    <GrantType>implicit</GrantType>
    <GrantType>password</GrantType>
</SupportedGrantTypes>

इससे Apigee Edge पर, OAuth टोकन एंडपॉइंट के साथ काम करने वाले अनुमति देने के टाइप के बारे में पता चलता है. एक एंडपॉइंट, कई तरह के ग्रांट टाइप के साथ काम कर सकता है. इसका मतलब है कि एक एंडपॉइंट को, कई तरह के ग्रांट टाइप के लिए ऐक्सेस टोकन डिस्ट्रिब्यूट करने के लिए कॉन्फ़िगर किया जा सकता है. एंडपॉइंट के बारे में ज़्यादा जानने के लिए, OAuth एंडपॉइंट के बारे में जानकारी लेख पढ़ें. अनुमति के टाइप को टोकन के अनुरोधों में grant_type पैरामीटर के तौर पर पास किया जाता है.

अगर अनुमति देने के लिए इस्तेमाल किए जा सकने वाले किसी भी टाइप के बारे में नहीं बताया गया है, तो सिर्फ़ authorization_code और implicit टाइप का इस्तेमाल किया जा सकता है. <GrantType> एलिमेंट भी देखें. यह एक हायर-लेवल एलिमेंट है. इसका इस्तेमाल यह तय करने के लिए किया जाता है कि Apigee Edge को grant_type पैरामीटर कहां खोजना चाहिए. यह पैरामीटर, क्लाइंट के अनुरोध में पास किया जाता है. Edge यह पक्का करेगा कि grant_type पैरामीटर की वैल्यू, अनुमति देने के लिए इस्तेमाल किए जा सकने वाले किसी टाइप से मेल खाती हो.

डिफ़ॉल्ट:	authorization _code और implicit
मौजूदगी:	ज़रूरी है
टाइप:	स्ट्रिंग
मान्य वैल्यू:	client_credentials authorization_code पासवर्ड इंप्लिसिट

<Tokens>/<Token> एलिमेंट

इस कुकी का इस्तेमाल, ValidateToken और InvalidateToken कार्रवाइयों के साथ किया जाता है. ऐक्सेस टोकन को स्वीकार और रद्द करना लेख भी पढ़ें. <Token> एलिमेंट, उस फ़्लो वैरिएबल की पहचान करता है जो रद्द किए जाने वाले टोकन के सोर्स के बारे में बताता है. अगर डेवलपर को ऐक्सेस टोकन, access_token नाम वाले क्वेरी पैरामीटर के तौर पर सबमिट करने हैं, तो request.queryparam.access_token का इस्तेमाल करें.

<UserName> एलिमेंट

<UserName>request.queryparam.user_name</UserName>

उदाहरण के लिए, क्वेरी पैरामीटर में उपयोगकर्ता नाम पास किया जा सकता है. साथ ही, <UserName> एलिमेंट को इस तरह सेट किया जा सकता है: <UserName>request.queryparam.username</UserName>.एचटीटीपी हेडर में उपयोगकर्ता नाम की ज़रूरत होने पर, इस वैल्यू को request.header.username पर सेट करें.

ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना भी देखें.

डिफ़ॉल्ट:	request.formparam.username (यह x-www-form-urlencoded है और अनुरोध के मुख्य हिस्से में दिया गया है)
मौजूदगी:	वैकल्पिक
टाइप:	स्ट्रिंग
मान्य वैल्यू:	वैरिएबल की कोई भी सेटिंग.
इनके साथ इस्तेमाल किया जाता है:	पासवर्ड

ऐक्सेस टोकन की पुष्टि करना

किसी एपीआई प्रॉक्सी के लिए टोकन एंडपॉइंट सेट अप करने के बाद, उससे मिलती-जुलती OAuthV2 नीति को उस फ़्लो से जोड़ा जाता है जो सुरक्षित संसाधन को दिखाता है. इस नीति में VerifyAccessToken ऑपरेशन के बारे में बताया जाता है.

उदाहरण के लिए, यह पक्का करने के लिए कि एपीआई के सभी अनुरोधों को अनुमति मिली हो, यहां दी गई नीति ऐक्सेस टोकन की पुष्टि करने की सुविधा लागू करती है:

<OAuthV2 name="VerifyOAuthAccessToken">
  <Operation>VerifyAccessToken</Operation>
</OAuthV2>

यह नीति, उस एपीआई संसाधन से जुड़ी होती है जिसे सुरक्षित रखना है. यह पक्का करने के लिए कि एपीआई के सभी अनुरोधों की पुष्टि हो गई है, नीति को ProxyEndpoint के अनुरोध PreFlow से अटैच करें. इसके लिए, यह तरीका अपनाएं:

<PreFlow>
  <Request>
    <Step><Name>VerifyOAuthAccessToken</Name></Step>
  </Request>
</PreFlow>

VerifyAccessToken ऑपरेशन के लिए डिफ़ॉल्ट सेटिंग को बदलने के लिए, इन वैकल्पिक एलिमेंट का इस्तेमाल किया जा सकता है.

नाम ब्यौरा

दायरा

नाम	ब्यौरा
दायरा	स्कोप की ऐसी सूची जिसमें दो स्कोप के बीच में खाली जगह का इस्तेमाल किया गया हो. अगर सूची में शामिल कम से कम एक स्कोप, ऐक्सेस टोकन में मौजूद है, तो पुष्टि हो जाएगी. उदाहरण के लिए, यहां दी गई नीति ऐक्सेस टोकन की जांच करेगी, ताकि यह पक्का किया जा सके कि इसमें सूची में शामिल कम से कम एक स्कोप मौजूद है. अगर READ या WRITE मौजूद है, तो पुष्टि हो जाएगी. <OAuthV2 name="ValidateOauthScopePolicy"> <Operation>VerifyAccessToken</Operation> <Scope>READ WRITE</Scope> </OAuthV2>
AccessToken	वह वैरिएबल जहां ऐक्सेस टोकन मौजूद होना चाहिए. उदाहरण के लिए `request.queryparam.accesstoken`. डिफ़ॉल्ट रूप से, ऐक्सेस टोकन को OAuth 2.0 स्पेसिफ़िकेशन के मुताबिक, ऐप्लिकेशन को Authorization एचटीटीपी हेडर में दिखाना होता है. इस सेटिंग का इस्तेमाल तब करें, जब ऐक्सेस टोकन को किसी गैर-स्टैंडर्ड जगह पर दिखाना हो. जैसे, क्वेरी पैरामीटर या Authorization के अलावा किसी दूसरे नाम वाला एचटीटीपी हेडर.

स्कोप की ऐसी सूची जिसमें दो स्कोप के बीच में खाली जगह का इस्तेमाल किया गया हो. अगर सूची में शामिल कम से कम एक स्कोप, ऐक्सेस टोकन में मौजूद है, तो पुष्टि हो जाएगी. उदाहरण के लिए, यहां दी गई नीति ऐक्सेस टोकन की जांच करेगी, ताकि यह पक्का किया जा सके कि इसमें सूची में शामिल कम से कम एक स्कोप मौजूद है. अगर READ या WRITE मौजूद है, तो पुष्टि हो जाएगी.

<OAuthV2 name="ValidateOauthScopePolicy">
  <Operation>VerifyAccessToken</Operation>
  <Scope>READ WRITE</Scope>
</OAuthV2>

AccessToken वह वैरिएबल जहां ऐक्सेस टोकन मौजूद होना चाहिए. उदाहरण के लिए request.queryparam.accesstoken. डिफ़ॉल्ट रूप से, ऐक्सेस टोकन को OAuth 2.0 स्पेसिफ़िकेशन के मुताबिक, ऐप्लिकेशन को Authorization एचटीटीपी हेडर में दिखाना होता है. इस सेटिंग का इस्तेमाल तब करें, जब ऐक्सेस टोकन को किसी गैर-स्टैंडर्ड जगह पर दिखाना हो. जैसे, क्वेरी पैरामीटर या Authorization के अलावा किसी दूसरे नाम वाला एचटीटीपी हेडर.

ऐक्सेस टोकन की पुष्टि करना और ऐक्सेस टोकन और अनुमति कोड का अनुरोध करना लेख भी पढ़ें.

अनुरोध वैरिएबल की जगहें तय करना

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

यहां दिए गए उदाहरण में, यह दिखाया गया है कि ज़रूरी अनुमति कोड पैरामीटर की जगह को एचटीटीपी हेडर के तौर पर कैसे तय किया जा सकता है:

  ...
  <GrantType>request.header.grant_type</GrantType>
  <Code>request.header.code</Code>
  <ClientId>request.header.client_id</ClientId>
  <RedirectUri>request.header.redirect_uri</RedirectUri>
  <Scope>request.header.scope</Scope>
  ...

इसके अलावा, अगर आपको अपने क्लाइंट ऐप्लिकेशन के आधार पर सहायता देनी है, तो हेडर और क्वेरी पैरामीटर को एक साथ इस्तेमाल किया जा सकता है:

  ...
  <GrantType>request.header.grant_type</GrantType>
  <Code>request.header.code</Code>
  <ClientId>request.queryparam.client_id</ClientId>
  <RedirectUri>request.queryparam.redirect_uri</RedirectUri>
  <Scope>request.queryparam.scope</Scope>
  ...

हर पैरामीटर के लिए, सिर्फ़ एक जगह की जानकारी कॉन्फ़िगर की जा सकती है.

फ़्लो वैरिएबल

इस टेबल में तय किए गए फ़्लो वैरिएबल, संबंधित OAuth नीतियां लागू होने पर भर जाते हैं. इसलिए, ये एपीआई प्रॉक्सी फ़्लो में लागू होने वाली अन्य नीतियों या ऐप्लिकेशन के लिए उपलब्ध होते हैं.

VerifyAccessToken ऑपरेशन

VerifyAccessToken ऑपरेशन के चालू होने पर, प्रॉक्सी के एक्ज़ीक्यूशन कॉन्टेक्स्ट में कई फ़्लो वैरिएबल भर जाते हैं. इन वैरिएबल से आपको ऐक्सेस टोकन, डेवलपर ऐप्लिकेशन, डेवलपर, और कंपनी से जुड़ी प्रॉपर्टी मिलती हैं. इनमें से किसी भी वैरिएबल को पढ़ने के लिए, AssignMessage या JavaScript नीति का इस्तेमाल किया जा सकता है. उदाहरण के लिए, बाद में फ़्लो में ज़रूरत के मुताबिक इनका इस्तेमाल किया जा सकता है. ये वैरिएबल, डीबग करने के लिए भी इस्तेमाल किए जा सकते हैं.

ध्यान दें: अगर एपीआई प्रॉडक्ट, मान्य एनवायरमेंट, प्रॉक्सी, और एपीआई संसाधनों (proxy.pathsuffix से लिए गए) के साथ कॉन्फ़िगर किए जाते हैं, तो एपीआई प्रॉडक्ट वैरिएबल अपने-आप भर जाएंगे. flow.resource.name वैरिएबल को साफ़ तौर पर सेट करने की ज़रूरत नहीं है.

अगर एपीआई प्रॉडक्ट को मान्य एनवायरमेंट और एपीआई प्रॉक्सी के साथ कॉन्फ़िगर नहीं किया गया है, तो फ़्लो में एपीआई प्रॉडक्ट वैरिएबल भरने के लिए, flow.resource.name को साफ़ तौर पर सेट करना ज़रूरी है. प्रॉडक्ट कॉन्फ़िगरेशन के बारे में ज़्यादा जानने के लिए, एपीआई पब्लिश करने के लिए Edge Management API का इस्तेमाल करना लेख पढ़ें.

टोकन के हिसाब से वैरिएबल

वैरिएबल	ब्यौरा
`organization_name`	उस संगठन का नाम जहां प्रॉक्सी लागू की जा रही है.
`developer.id`	रजिस्टर किए गए क्लाइंट ऐप्लिकेशन से जुड़े डेवलपर का आईडी.
`developer.app.name`	रजिस्टर किए गए क्लाइंट ऐप्लिकेशन से जुड़े डेवलपर का नाम.
`client_id`	रजिस्टर किए गए क्लाइंट ऐप्लिकेशन का क्लाइंट आईडी.
`grant_type`	अनुरोध से जुड़ा ग्रांट टाइप.
`token_type`	अनुरोध से जुड़ा टोकन टाइप.
`access_token`	वह ऐक्सेस टोकन जिसकी पुष्टि की जा रही है.
`accesstoken.{custom_attribute}`	ऐक्सेस टोकन में नाम वाला कस्टम एट्रिब्यूट.
`issued_at`	ऐक्सेस टोकन जारी करने की तारीख. इसे यूनिक्स epoch टाइम के हिसाब से मिलीसेकंड में दिखाया जाता है.
`expires_in`	ऐक्सेस टोकन के खत्म होने का समय. इसकी वैल्यू सेकंड में होती है. `ExpiresIn` एलिमेंट, समयसीमा खत्म होने की अवधि को मिलीसेकंड में सेट करता है. हालांकि, टोकन रिस्पॉन्स और फ़्लो वैरिएबल में, वैल्यू को सेकंड में दिखाया जाता है.
`status`	ऐक्सेस टोकन की स्थिति (जैसे, अनुमति दी गई या रद्द की गई).
`scope`	ऐक्सेस टोकन से जुड़ा स्कोप (अगर कोई है).
`apiproduct.<custom_attribute_name>`	रजिस्टर किए गए क्लाइंट ऐप्लिकेशन से जुड़े एपीआई प्रॉडक्ट का नाम वाला कस्टम एट्रिब्यूट.
`apiproduct.name`	रजिस्टर किए गए क्लाइंट ऐप्लिकेशन से जुड़े एपीआई प्रॉडक्ट का नाम.
`revoke_reason`	(सिर्फ़ Apigee hybrid के लिए) इससे पता चलता है कि ऐक्सेस टोकन क्यों रद्द किया गया है. इसकी वैल्यू `REVOKED_BY_APP`, `REVOKED_BY_ENDUSER`, `REVOKED_BY_APP_ENDUSER` या `TOKEN_REVOKED` हो सकती है.

ऐप्लिकेशन के हिसाब से वैरिएबल

ये वैरिएबल, उस डेवलपर ऐप्लिकेशन से जुड़े होते हैं जो टोकन से जुड़ा होता है.

वैरिएबल	ब्यौरा
`app.name`
`app.id`
`app.accessType`
`app.callbackUrl`
`app.status`	स्वीकार किया गया है या वापस ले लिया गया है
`app.scopes`
`app.appFamily`
`app.apiproducts`
`app.appParentStatus`
`app.appType`	उदाहरण के लिए: डेवलपर
`app.appParentId`
`app.created_by`
`app.created_at`
`app.last_modified_at`
`app.last_modified_by`
`app.{custom_attributes}`	रजिस्टर किए गए क्लाइंट ऐप्लिकेशन का नाम वाला कस्टम एट्रिब्यूट.

डेवलपर के हिसाब से वैरिएबल

अगर app.appType "Company" है, तो कंपनी के एट्रिब्यूट भर दिए जाते हैं. अगर app.appType "Developer" है, तो डेवलपर के एट्रिब्यूट भर दिए जाते हैं.

वैरिएबल	ब्यौरा
डेवलपर के हिसाब से वैरिएबल
`developer.id`
`developer.userName`
`developer.firstName`
`developer.lastName`
`developer.email`
`developer.status`	चालू या बंद
`developer.apps`
`developer.created_by`
`developer.created_at`
`developer.last_modified_at`
`developer.last_modified_by`
`developer.{custom_attributes}`	डेवलपर का नाम दिया गया कस्टम एट्रिब्यूट.

कंपनी के हिसाब से वैरिएबल

वैरिएबल	ब्यौरा
`company.id`
`company.displayName`
`company.apps`
`company.appOwnerStatus`
`company.created_by`
`company.created_at`
`company.last_modified_at`
`company.last_modified_by`
`company.{custom_attributes}`	कंपनी के लिए, नाम वाली कस्टम एट्रिब्यूट.

GenerateAuthorizationCode ऑपरेशन

GenerateAuthorizationCode ऑपरेशन के पूरा होने पर, ये वैरिएबल सेट किए जाते हैं:

प्रीफ़िक्स: oauthv2authcode.{policy_name}.{variable_name}

उदाहरण: oauthv2authcode.GenerateCodePolicy.code

वैरिएबल	ब्यौरा
`code`	नीति लागू होने पर जनरेट किया गया अनुमति कोड.
`redirect_uri`	रजिस्टर किए गए क्लाइंट ऐप्लिकेशन से जुड़ा रीडायरेक्ट यूआरआई.
`scope`	क्लाइंट के अनुरोध में पास किया गया, OAuth का वैकल्पिक स्कोप.
`client_id`	क्लाइंट के अनुरोध में पास किया गया क्लाइंट आईडी.

GenerateAccessToken और RefreshAccessToken कार्रवाइयां

ये वैरिएबल तब सेट किए जाते हैं, जब GenerateAccessToken और RefreshAccessToken ऑपरेशन पूरे हो जाते हैं. ध्यान दें कि रीफ़्रेश टोकन वैरिएबल, क्लाइंट क्रेडेंशियल ग्रांट टाइप के फ़्लो पर लागू नहीं होते.

प्रीफ़िक्स: oauthv2accesstoken.{policy_name}.{variable_name}

उदाहरण: oauthv2accesstoken.GenerateTokenPolicy.access_token

वैरिएबल का नाम	ब्यौरा
`access_token`	जनरेट किया गया ऐक्सेस टोकन.
`client_id`	इस टोकन से जुड़े डेवलपर ऐप्लिकेशन का क्लाइंट आईडी.
`expires_in`	टोकन की समयसीमा खत्म होने की वैल्यू. ज़्यादा जानकारी के लिए, <ExpiresIn> एलिमेंट देखें. ध्यान दें कि जवाब में, expires_in को सेकंड में दिखाया जाता है.
`scope`	टोकन के लिए कॉन्फ़िगर किए गए उपलब्ध स्कोप की सूची. OAuth2 स्कोप के साथ काम करना लेख पढ़ें.
`status`	`approved` या `revoked`.
`token_type`	`BearerToken` पर सेट हो.

`developer.email`	रजिस्टर किए गए उस डेवलपर का ईमेल पता जिसके पास टोकन से जुड़ा डेवलपर ऐप्लिकेशन है.
`organization_name`	वह संगठन जहां प्रॉक्सी लागू होती है.
`api_product_list`	टोकन से जुड़े डेवलपर ऐप्लिकेशन से जुड़े प्रॉडक्ट की सूची.

`refresh_count`
`refresh_token`	जनरेट किया गया रीफ़्रेश टोकन. ध्यान दें कि क्लाइंट क्रेडेंशियल ग्रांट टाइप के लिए, रीफ़्रेश टोकन जनरेट नहीं किए जाते.
`refresh_token_expires_in`	रीफ़्रेश टोकन का लाइफ़टाइम (सेकंड में).
`refresh_token_issued_at`	यह समय की वैल्यू, 32-बिट के टाइमस्टैंप की मात्रा का स्ट्रिंग फ़ॉर्मैट है. उदाहरण के लिए, 'Wed, 21 Aug 2013 19:16:47 UTC' टाइमस्टैंप की वैल्यू 1377112607413 है.
`refresh_token_status`	`approved` या `revoked`.

GenerateAccessTokenImplicitGrant

ये वैरिएबल तब सेट होते हैं, जब इंप्लिसिट ग्रांट टाइप फ़्लो के लिए GenerateAccessTokenImplicit ऑपरेशन पूरा हो जाता है.

प्रीफ़िक्स: oauthv2accesstoken.{policy_name}.{variable_name}

उदाहरण: oauthv2accesstoken.RefreshTokenPolicy.access_token

वैरिएबल	ब्यौरा
`oauthv2accesstoken.access_token`	नीति लागू होने पर जनरेट किया गया ऐक्सेस टोकन.
`oauthv2accesstoken.{policy_name}.expires_in`	टोकन के खत्म होने का समय (सेकंड में). ज़्यादा जानकारी के लिए, <ExpiresIn> एलिमेंट देखें.

गड़बड़ी की जानकारी

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

रनटाइम से जुड़ी गड़बड़ियां

नीति लागू होने पर ये गड़बड़ियां हो सकती हैं.

सलाह: गड़बड़ी के कोड की जांच करने और समस्याओं का तेज़ी से पता लगाने के लिए, एपीआई मॉनिटरिंग का इस्तेमाल करें. उदाहरण के लिए, नीति के उल्लंघन से जुड़ी गड़बड़ी का कोड भेजने की सूचना सेट अप करना देखें. गड़बड़ी के कोड का रेफ़रंस देखें. इसमें, उन सभी गड़बड़ी के कोड की पूरी सूची दी गई है जिन्हें एपीआई मॉनिटरिंग की मदद से मैनेज किया जा सकता है.

गड़बड़ी का कोड	एचटीटीपी कोड स्थिति	वजह	ऑपरेशन की वजह से थ्रो किया गया
`steps.oauth.v2.access_token_expired`	401	ऐक्सेस टोकन की समयसीमा खत्म हो गई है.	VerifyAccessToken InvalidateToken
`steps.oauth.v2.access_token_not_approved`	401	ऐक्सेस टोकन रद्द कर दिया गया.	VerifyAccessToken
`steps.oauth.v2.apiresource_doesnot_exist`	401	अनुरोध किया गया संसाधन, ऐक्सेस टोकन से जुड़े किसी भी एपीआई प्रॉडक्ट में मौजूद नहीं है.	VerifyAccessToken
`steps.oauth.v2.FailedToResolveAccessToken`	500	नीति को `<AccessToken>` एलिमेंट में बताए गए वैरिएबल में ऐक्सेस टोकन मिलना चाहिए था, लेकिन वैरिएबल को हल नहीं किया जा सका.	GenerateAccessToken
`steps.oauth.v2.FailedToResolveAuthorizationCode`	500	नीति को `<Code>` एलिमेंट में बताए गए वैरिएबल में अनुमति कोड मिलना चाहिए था, लेकिन वैरिएबल को हल नहीं किया जा सका.	GenerateAuthorizationCode
`steps.oauth.v2.FailedToResolveClientId`	500	नीति को `<ClientId>` एलिमेंट में बताए गए वैरिएबल में क्लाइंट आईडी मिलना चाहिए था, लेकिन वैरिएबल को हल नहीं किया जा सका.	GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken
`steps.oauth.v2.FailedToResolveRefreshToken`	500	नीति को `<RefreshToken>` एलिमेंट में बताए गए वैरिएबल में रीफ़्रेश टोकन मिलना चाहिए था, लेकिन वैरिएबल को हल नहीं किया जा सका.	RefreshAccessToken
`steps.oauth.v2.FailedToResolveToken`	500	नीति को `<Tokens>` एलिमेंट में बताए गए वेरिएबल में टोकन मिलना चाहिए था, लेकिन वेरिएबल को हल नहीं किया जा सका.	ValidateToken InvalidateToken
`steps.oauth.v2.InsufficientScope`	403	अनुरोध में दिए गए ऐक्सेस टोकन का स्कोप, ऐक्सेस टोकन की पुष्टि करने के लिए बनी नीति में बताए गए स्कोप से मेल नहीं खाता. स्कोप के बारे में जानने के लिए, OAuth2 स्कोप के साथ काम करना लेख पढ़ें.	VerifyAccessToken
`steps.oauth.v2.invalid_access_token`	401	क्लाइंट से भेजा गया ऐक्सेस टोकन अमान्य है.	VerifyAccessToken
`steps.oauth.v2.invalid_client`	401	गड़बड़ी का यह नाम तब दिखता है, जब नीति की `<GenerateResponse>` प्रॉपर्टी को सही पर सेट किया गया हो और अनुरोध में भेजा गया क्लाइंट आईडी अमान्य हो. पक्का करें कि आपने अपनी प्रॉक्सी से जुड़े डेवलपर ऐप्लिकेशन के लिए, सही क्लाइंट पासकोड और गुप्त वैल्यू का इस्तेमाल किया हो. आम तौर पर, इन वैल्यू को Base64 से कोड में बदले गए, बुनियादी पुष्टि वाले हेडर के तौर पर भेजा जाता है. ध्यान दें: हमारा सुझाव है कि आप गड़बड़ी के मौजूदा नियम की शर्तों को बदलें, ताकि `invalid_client` और `InvalidClientIdentifier`, दोनों नामों को पकड़ा जा सके. ज़्यादा जानकारी और उदाहरण के लिए, 16.09.21 के रिलीज़ नोट देखें.	GenerateAccessToken RefreshAccessToken
`steps.oauth.v2.InvalidRequest`	400	गड़बड़ी के इस नाम का इस्तेमाल कई तरह की गड़बड़ियों के लिए किया जाता है. आम तौर पर, अनुरोध में मौजूद पैरामीटर के अमान्य या मौजूद न होने पर यह गड़बड़ी दिखती है. अगर `<GenerateResponse>` को `false` पर सेट किया गया है, तो गड़बड़ी के नाम और वजह जैसी जानकारी पाने के लिए, गड़बड़ी के वैरिएबल (नीचे बताया गया है) का इस्तेमाल करें.	GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken
`steps.oauth.v2.InvalidAccessToken`	401	अनुमति वाले हेडर में "Bearer" शब्द मौजूद नहीं है, जो ज़रूरी है. उदाहरण के लिए: `Authorization: Bearer your_access_token`	VerifyAccessToken
`steps.oauth.v2.InvalidAPICallAsNoApiProductMatchFound`	401	एपीआई प्रॉक्सी, ऐक्सेस टोकन से जुड़े प्रॉडक्ट में नहीं है. सलाह: पक्का करें कि ऐक्सेस टोकन से जुड़ा प्रॉडक्ट सही तरीके से कॉन्फ़िगर किया गया हो. उदाहरण के लिए, अगर आपने संसाधन पाथ में वाइल्डकार्ड का इस्तेमाल किया है, तो पक्का करें कि वाइल्डकार्ड का इस्तेमाल सही तरीके से किया जा रहा हो. ज़्यादा जानकारी के लिए, एपीआई प्रॉडक्ट बनाना देखें. इस गड़बड़ी की वजहों के बारे में ज़्यादा जानने के लिए, Apigee कम्यूनिटी की यह पोस्ट भी देखें.	VerifyAccessToken
`steps.oauth.v2.InvalidClientIdentifier`	500	गड़बड़ी का यह नाम तब दिखता है, जब नीति की `<GenerateResponse>` प्रॉपर्टी को गलत है पर सेट किया गया हो और अनुरोध में भेजा गया क्लाइंट आईडी अमान्य हो. पक्का करें कि आपने अपनी प्रॉक्सी से जुड़े डेवलपर ऐप्लिकेशन के लिए, सही क्लाइंट पासकोड और गुप्त वैल्यू का इस्तेमाल किया हो. आम तौर पर, इन वैल्यू को Base64 के ज़रिए कोड में बदले गए, ध्यान दें: इस स्थिति में, इस गड़बड़ी को पहले `invalid_client` कहा जाता था. हमारा सुझाव है कि आप गड़बड़ी के मौजूदा नियम की शर्तों को बदलें, ताकि `invalid_client` और `InvalidClientIdentifier`, दोनों नामों को पकड़ा जा सके. ज़्यादा जानकारी और उदाहरण के लिए, 16.09.21 के रिलीज़ नोट देखें.	GenerateAccessToken RefreshAccessToken
`steps.oauth.v2.InvalidParameter`	500	नीति में ऐक्सेस टोकन या ऑथराइज़ेशन कोड में से किसी एक के बारे में बताया जाना चाहिए, दोनों के बारे में नहीं.	GenerateAuthorizationCode GenerateAccessTokenImplicitGrant
`steps.oauth.v2.InvalidTokenType`	500	`<Tokens>/<Token>` एलिमेंट के लिए, आपको टोकन का टाइप बताना होगा. उदाहरण के लिए, `refreshtoken`. अगर क्लाइंट गलत टाइप पास करता है, तो यह गड़बड़ी दिखती है.	ValidateToken InvalidateToken
`steps.oauth.v2.MissingParameter`	500	रिस्पॉन्स टाइप `token` है, लेकिन अनुदान का कोई टाइप नहीं बताया गया है.	GenerateAuthorizationCode GenerateAccessTokenImplicitGrant
`steps.oauth.v2.UnSupportedGrantType`	500	क्लाइंट ने अनुदान का ऐसा टाइप बताया है जो नीति के मुताबिक काम नहीं करता. यह टाइप, <SupportedGrantTypes> एलिमेंट में मौजूद नहीं है. ध्यान दें: फ़िलहाल, एक गड़बड़ी है, जिसमें गैर-काम करने वाले अनुदान टाइप की गड़बड़ियां ठीक से नहीं दिखती हैं. अगर ग़ैर-काम करने वाले अनुदान टाइप की गड़बड़ी होती है, तो प्रोक्सी, उम्मीद के मुताबिक गड़बड़ी के फ़्लो में नहीं जाती.	GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken

डिप्लॉयमेंट से जुड़ी गड़बड़ियां

इस नीति वाली किसी प्रॉक्सी को डिप्लॉय करने पर, ये गड़बड़ियां हो सकती हैं.

गड़बड़ी का नाम	वजह
`InvalidValueForExpiresIn`	`<ExpiresIn>` एलिमेंट के लिए, पॉज़िटिव पूर्णांक और `-1` मान्य वैल्यू हैं.
`InvalidValueForRefreshTokenExpiresIn`	`<RefreshTokenExpiresIn>` एलिमेंट के लिए, पॉज़िटिव इंटिजर और `-1` मान्य वैल्यू हैं.
`InvalidGrantType`	`<SupportedGrantTypes>` एलिमेंट में, अनुदान का अमान्य टाइप दिया गया है. मान्य टाइप की सूची के लिए, नीति का रेफ़रंस देखें.
`ExpiresInNotApplicableForOperation`	पक्का करें कि <Operations> एलिमेंट में बताए गए ऑपरेशन, समयसीमा खत्म होने की सुविधा के साथ काम करते हों. उदाहरण के लिए, VerifyToken ऑपरेशन में ऐसा नहीं होता.
`RefreshTokenExpiresInNotApplicableForOperation`	पक्का करें कि <Operations> एलिमेंट में बताए गए ऑपरेशन, रीफ़्रेश करने के लिए ज़रूरी हों और टोकन की समयसीमा खत्म होने पर, टोकन को रिन्यू किया जा सके. उदाहरण के लिए, VerifyToken ऑपरेशन में ऐसा नहीं होता.
`GrantTypesNotApplicableForOperation`	पक्का करें कि <SupportedGrantTypes> में बताए गए अनुदान टाइप, बताए गए ऑपरेशन के लिए काम करते हों.
`OperationRequired`	आपको इस नीति में, `<Operation>` एलिमेंट का इस्तेमाल करके कोई कार्रवाई तय करनी होगी. ध्यान दें: अगर `<Operation>` एलिमेंट मौजूद नहीं है, तो यूज़र इंटरफ़ेस (यूआई) में स्कीमा की पुष्टि करने से जुड़ी गड़बड़ी का मैसेज दिखता है.
`InvalidOperation`	आपको इस नीति में, `<Operation>` एलिमेंट का इस्तेमाल करके कोई मान्य कार्रवाई बतानी होगी. ध्यान दें: अगर `<Operation>` एलिमेंट अमान्य है, तो यूज़र इंटरफ़ेस (यूआई) में स्कीमा की पुष्टि करने से जुड़ी गड़बड़ी का मैसेज दिखता है.
`TokenValueRequired`	आपको `<Tokens>` एलिमेंट में टोकन `<Token>` की वैल्यू बतानी होगी.

गड़बड़ी के वैरिएबल

ये वैरिएबल तब सेट होते हैं, जब रनटाइम के दौरान यह नीति किसी गड़बड़ी को ट्रिगर करती है.

ध्यान दें: गड़बड़ी के नियम की शर्तें बनाने के लिए, इन वैरिएबल का इस्तेमाल किया जा सकता है. अगर <GenerateResponse> को false पर सेट किया गया है, तो गड़बड़ी होने पर ये वैरिएबल अपने-आप पॉप्युलेट हो जाते हैं. अगर <GenerateResponse> true है, तो गड़बड़ी होने पर नीति, क्लाइंट को तुरंत जवाब देती है. साथ ही, गड़बड़ी का फ़्लो स्किप कर दिया जाता है और इन वैरिएबल को पॉप्युलेट नहीं किया जाता. ज़्यादा जानकारी के लिए, नीति से जुड़ी गड़बड़ियों के बारे में आपको क्या जानना चाहिए लेख पढ़ें.

वैरिएबल	कहां	उदाहरण
`fault.name="fault_name"`	`fault_name`, गड़बड़ी का नाम है, जैसा कि ऊपर दी गई रनटाइम गड़बड़ियां टेबल में बताया गया है. गड़बड़ी का नाम, गड़बड़ी के कोड का आखिरी हिस्सा होता है.	`fault.name = "InvalidRequest"`
`oauthV2.policy_name.failed`	`policy_name`, उस नीति का नाम है जिसकी वजह से गड़बड़ी हुई. यह नाम उपयोगकर्ता ने तय किया है.	`oauthV2.GenerateAccesstoken.failed = true`
`oauthV2.policy_name.fault.name`	`policy_name`, उस नीति का नाम है जिसकी वजह से गड़बड़ी हुई. यह नाम उपयोगकर्ता ने तय किया है.	`oauthV2.GenerateAccesstoken.fault.name = InvalidRequest` ध्यान दें: VerifyAccessToken ऑपरेशन के लिए, गड़बड़ी के नाम में यह सफ़िक्स शामिल होता है: `keymanagement.service` उदाहरण के लिए: `keymanagement.service.invalid_access_token`
`oauthV2.policy_name.fault.cause`	`policy_name`, उस नीति का नाम है जिसकी वजह से गड़बड़ी हुई. यह नाम उपयोगकर्ता ने तय किया है.	`oauthV2.GenerateAccesstoken.cause = Required param : grant_type`

गड़बड़ी के रिस्पॉन्स का उदाहरण

अगर <GenerateResponse> एलिमेंट true है, तो ये रिस्पॉन्स क्लाइंट को भेजे जाते हैं.

ध्यान दें: गड़बड़ी को मैनेज करने के लिए, सबसे सही तरीका यह है कि गड़बड़ी के जवाब के errorcode हिस्से को ट्रैप किया जाए. faultstring में मौजूद टेक्स्ट पर भरोसा न करें, क्योंकि इसमें बदलाव हो सकता है.

अगर <GenerateResponse> सही है, तो नीति, टोकन और कोड जनरेट करने वाले ऑपरेशन के लिए, इस फ़ॉर्मैट में गड़बड़ियां दिखाती है. पूरी सूची के लिए, OAuth एचटीटीपी गड़बड़ी के रिस्पॉन्स का रेफ़रंस देखें.

{"ErrorCode" : "invalid_client", "Error" :"ClientId is Invalid"}

अगर <GenerateResponse> सही है, तो नीति पुष्टि करने और पुष्टि की पुष्टि करने के लिए, इस फ़ॉर्मैट में गड़बड़ियां दिखाती है. पूरी सूची के लिए, OAuth एचटीटीपी गड़बड़ी के रिस्पॉन्स का रेफ़रंस देखें.

{  
   {  
      "fault":{  
         "faultstring":"Invalid Access Token",
         "detail":{  
            "errorcode":"keymanagement.service.invalid_access_token"
         }
      }
   }

गड़बड़ी के नियम का उदाहरण

<FaultRule name=OAuthV2 Faults">
    <Step>
        <Name>AM-InvalidClientResponse</Name>
        <Condition>(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")</Condition>
    </Step>
    <Step>
        <Name>AM-InvalidTokenResponse</Name>
        <Condition>(fault.name = "invalid_access_token")</Condition>
    </Step>
    <Condition>(oauthV2.failed = true) </Condition>
</FaultRule>

नीति स्कीमा

नीति के हर टाइप को एक्सएमएल स्कीमा (.xsd) के ज़रिए तय किया जाता है. रेफ़रंस के लिए, नीति के स्कीमा GitHub पर उपलब्ध हैं.

OAuth के डिफ़ॉल्ट कॉन्फ़िगरेशन का इस्तेमाल करना

Apigee Edge पर मौजूद हर संगठन (मुफ़्त में आज़माने वाले संगठन के लिए भी) को OAuth टोकन एंडपॉइंट उपलब्ध कराया जाता है. एंडपॉइंट को एपीआई प्रॉक्सी में नीतियों के साथ पहले से कॉन्फ़िगर किया जाता है. इस एपीआई प्रॉक्सी को oauth कहा जाता है. Apigee Edge पर खाता बनाने के तुरंत बाद, टोकन एंडपॉइंट का इस्तेमाल शुरू किया जा सकता है. ज़्यादा जानकारी के लिए, OAuth एंडपॉइंट के बारे में जानकारी लेख पढ़ें.

ऐक्सेस टोकन मिटाना

डिफ़ॉल्ट रूप से, ऐक्सेस टोकन और रीफ़्रेश टोकन (अगर मौजूद है) दोनों की समयसीमा खत्म होने के तीन दिन (2,59,200 सेकंड) बाद, OAuth2 टोकन को Apigee Edge सिस्टम से हटा दिया जाता है. कुछ मामलों में, आपको यह डिफ़ॉल्ट सेटिंग बदलनी पड़ सकती है. उदाहरण के लिए, अगर बड़ी संख्या में टोकन जनरेट किए जा रहे हैं, तो डिस्क स्पेस बचाने के लिए, मिटाने का समय कम किया जा सकता है.

अगर Edge for Private Cloud का इस्तेमाल किया जा रहा है, तो इस सेक्शन में बताए गए तरीके से संगठन की प्रॉपर्टी सेट करके, इस डिफ़ॉल्ट वैल्यू को बदला जा सकता है. (समयसीमा खत्म हो चुके टोकन को तीन दिनों में हटाने की सुविधा, Edge for Private Cloud के 4.19.01 और इसके बाद के वर्शन पर लागू होती है. पहले के वर्शन के लिए, डेटा मिटाने का डिफ़ॉल्ट इंटरवल 180 दिन है.)

Edge Private Cloud 4.16.01 और इसके बाद के वर्शन के लिए, डेटा मिटाने की सेटिंग अपडेट करना

ध्यान दें: इन सेटिंग का असर सिर्फ़ उन टोकन पर पड़ता है जो इन सेटिंग को लागू करने के बाद जनरेट किए गए हैं. ये सेटिंग, पहले जनरेट किए गए टोकन पर लागू नहीं होती हैं.

प्राइवेट क्लाउड:

इस फ़ाइल में बदलाव करने के लिए, इसे खोलें:
```
/opt/apigee/customer/application/message-processor.properties
```
टोकन की समयसीमा खत्म होने के बाद, उसे मिटाने से पहले इंतज़ार करने के लिए सेकंड की संख्या सेट करने के लिए, यह प्रॉपर्टी जोड़ें:
```
conf_keymanagement_oauth.access.token.purge.after.seconds=<number of seconds>
```
मैसेज प्रोसेस करने वाले सिस्टम को रीस्टार्ट करें. उदाहरण के लिए:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

अगर ऐक्सेस टोकन की समयसीमा कभी खत्म नहीं होती है, तो इसे कभी नहीं हटाया जाएगा. OAuthV2 नीति में, <ExpiresIn> और <RefreshTokenExpiresIn> एट्रिब्यूट का इस्तेमाल करके, टोकन की समयसीमा खत्म होने की तारीख सेट की जा सकती है.

Edge Private Cloud 4.15.07 के लिए, डेटा मिटाने की सेटिंग अपडेट की जा रही हैं

प्राइवेट क्लाउड:

OAuthV2 नीति में, <ExpiresIn> और <RefreshTokenExpiresIn> एट्रिब्यूट के लिए पॉज़िटिव वैल्यू सेट करें. वैल्यू मिलीसेकंड में होती हैं. उदाहरण के लिए:
```
<ExpiresIn>1000</ExpiresIn>
<RefreshTokenExpiresIn>10000</RefreshTokenExpiresIn>
```
प्रॉक्सी को फिर से डिप्लॉय करें.

अपने संगठन के लिए, टोकन पर्ज करने की प्रॉपर्टी अपडेट करने के लिए, इस एपीआई का इस्तेमाल करें:

POST https://<host-name>/v1/organizations/<org-name>

पेलोड:

<Organization name="AutomationOrganization">
 <Description>Desc</Description>
 <Properties>
     <Property name="keymanagement.oauth20.access.token.purge">true</Property>
     <Property name="keymanagement.oauth20.access.token.purge.after.seconds">120</Property>
 </Properties>
</Organization>

मैसेज प्रोसेस करने वाले सिस्टम को रीस्टार्ट करें. उदाहरण के लिए:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
यह एपीआई, AutomationOrganization नाम के संगठन के लिए, टोकन पर्ज प्रॉपर्टी को सही पर सेट करता है. इस मामले में, टोकन और रीफ़्रेश टोकन, दोनों के खत्म होने के 120 सेकंड बाद, ऐक्सेस टोकन को डेटाबेस से हटा दिया जाएगा.

<ExpiresIn> एलिमेंट भी देखें.

RFC के मुताबिक काम न करना

OAuthV2 नीति, टोकन रिस्पॉन्स दिखाती है. इसमें कुछ ऐसी प्रॉपर्टी होती हैं जो RFC के मुताबिक नहीं होतीं. नीचे दी गई टेबल में, OAuthV2 नीति के ज़रिए दिखाई गई ऐसी प्रॉपर्टी के बारे में बताया गया है जो नीति का पालन नहीं करती हैं. साथ ही, नीति का पालन करने वाली प्रॉपर्टी के बारे में भी बताया गया है.

NOTE: अगर आपको इन एलिमेंट को नीति के मुताबिक बनाना है, तो कोई नीति बनाएं. जैसे, JavaScript या AssignMessage नीति. इससे नीति के आउटपुट को नीति के मुताबिक फ़ॉर्मैट में बदला जा सकता है. उदाहरण के लिए, गड़बड़ी: प्रॉक्सी को कॉल करते समय ऐक्सेस नहीं किया जा सका में बताया गया समाधान देखें. इसके अलावा, GitHub पर दिया गया OAuth2 का सैंपल समाधान भी देखें.

OAuthV2 ये वैल्यू दिखाता है:	RFC के मुताबिक प्रॉपर्टी यह है:
`"token_type":"BearerToken"`	`"token_type":"Bearer"`
`"expires_in":"3600"`	`"expires_in":3600` (ज़रूरी शर्तों को पूरा करने वाली वैल्यू एक संख्या है, स्ट्रिंग नहीं.)

इसके अलावा, grant_type = refresh_token के लिए, समयसीमा खत्म हो चुके रीफ़्रेश टोकन के लिए गड़बड़ी का जवाब यह है:

{"ErrorCode" : "InvalidRequest", "Error" :"Refresh Token expired"}

हालांकि, RFC के मुताबिक जवाब यह है:

{"error" : "invalid_grant", "error_description" :"refresh token expired"}

मिलते-जुलते विषय

OAuth 2.0 के बारे में शुरुआती जानकारी

OAuthV2 नीति

क्या

नमूने

VerifyAccessToken

VerifyAccessToken

GenerateAccessToken

ऐक्सेस टोकन जनरेट करना

GenerateAuthorizationCode

ऑथराइज़ेशन कोड जनरेट करना

RefreshAccessToken

ऐक्सेस टोकन रीफ़्रेश करना

जवाब देने के फ़्लो का टोकन

जवाब देने के फ़्लो पर ऐक्सेस टोकन जनरेट करना

तत्व का रेफ़रंस

<OAuthV2> एट्रिब्यूट

&lt;DisplayName&gt; एलिमेंट

<AccessToken> एलिमेंट

<AccessTokenPrefix> एलिमेंट

<AppEndUser> एलिमेंट

<Attributes/Attribute>

जवाब में कस्टम एट्रिब्यूट दिखाना या छिपाना

<ClientId> एलिमेंट

<Code> एलिमेंट

<ExpiresIn> एलिमेंट

<ExternalAccessToken> एलिमेंट

<ExternalAuthorization> एलिमेंट

<ExternalAuthorizationCode> एलिमेंट

<ExternalRefreshToken> एलिमेंट

<GenerateResponse> एलिमेंट

<GenerateErrorResponse> एलिमेंट

<GrantType>

<Operation> एलिमेंट

<PassWord> एलिमेंट

<RedirectUri> एलिमेंट

रीडायरेक्शन यूआरआई के बारे में जानकारी

<RefreshToken> एलिमेंट

<RefreshTokenExpiresIn> एलिमेंट

<ResponseType> एलिमेंट

<ReuseRefreshToken> एलिमेंट

<Scope> एलिमेंट

<State> एलिमेंट

<StoreToken> एलिमेंट

<SupportedGrantTypes>/<GrantType> element

<Tokens>/<Token> एलिमेंट

<UserName> एलिमेंट

ऐक्सेस टोकन की पुष्टि करना

अनुरोध वैरिएबल की जगहें तय करना

फ़्लो वैरिएबल

VerifyAccessToken ऑपरेशन

GenerateAuthorizationCode ऑपरेशन

GenerateAccessToken और RefreshAccessToken कार्रवाइयां

GenerateAccessTokenImplicitGrant

गड़बड़ी की जानकारी

रनटाइम से जुड़ी गड़बड़ियां

डिप्लॉयमेंट से जुड़ी गड़बड़ियां

गड़बड़ी के वैरिएबल

गड़बड़ी के रिस्पॉन्स का उदाहरण

गड़बड़ी के नियम का उदाहरण

नीति स्कीमा

OAuth के डिफ़ॉल्ट कॉन्फ़िगरेशन का इस्तेमाल करना

ऐक्सेस टोकन मिटाना

Edge Private Cloud 4.16.01 और इसके बाद के वर्शन के लिए, डेटा मिटाने की सेटिंग अपडेट करना

Edge Private Cloud 4.15.07 के लिए, डेटा मिटाने की सेटिंग अपडेट की जा रही हैं

RFC के मुताबिक काम न करना

मिलते-जुलते विषय

<DisplayName> एलिमेंट