OAuthV2 नीति

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

यह क्या है

OAuthV2, OAuth 2.0 अनुदान प्रकार कार्रवाइयां करने के लिए एक बहु-आयामी नीति है. यह मुख्य नीति है, जिसका इस्तेमाल Apigee Edge पर OAuth 2.0 एंडपॉइंट को कॉन्फ़िगर करने के लिए किया जाता है.

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

सैंपल

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

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

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

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 नीति के एलिमेंट और एट्रिब्यूट के बारे में बताया गया है.

नीचे दी गई नीति का उदाहरण, कई संभावित कॉन्फ़िगरेशन में से एक है. यह सैंपल, 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">

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

<DisplayName> एलिमेंट

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

<DisplayName>Policy Display Name</DisplayName>

<AccessToken> एलिमेंट

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

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

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

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

<AccessTokenPrefix> एलिमेंट

<AccessTokenPrefix>Bearer</AccessTokenPrefix>

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

-H "Authorization: Bearer Rft3dqrs56Blirls56a"

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

<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 ऐक्सेस टोकन को वापस पाने और रद्द करने की सुविधा चालू करना देखें.

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

<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 पर सेट किया गया था. कस्टम एट्रिब्यूट, ऐक्सेस टोकन के मेटाडेटा का हिस्सा होता है.

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

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

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

टोकन और ऑथराइज़ेशन कोड को पसंद के मुताबिक बनाना भी देखें.

<ClientId> एलिमेंट

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

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

<Code> एलिमेंट

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

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

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

<ExpiresIn> एलिमेंट

<ExpiresIn>10000</ExpiresIn> 

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

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

Apigee Edge for Public Cloud की मदद से, इकाइयों के ऐक्सेस होने के बाद, Edge नीचे दी गई इकाइयों को कम से कम 180 सेकंड तक कैश मेमोरी में रखता है.

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

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

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

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

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

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

1. message-processor.properties फ़ाइल को किसी एडिटर में खोलें. अगर फ़ाइल मौजूद नहीं है, तो इसे बनाएं:

   vi /opt/apigee/customer/application/message-processor.properties

2. प्रॉपर्टी को अपने हिसाब से सेट करें:

   conf_keymanagement_oauth_auth_code_expiry_time_in_millis=3600000

3. पक्का करें कि प्रॉपर्टी फ़ाइल का मालिकाना हक, "apigee" उपयोगकर्ता के पास हो:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. मैसेज प्रोसेसर को रीस्टार्ट करें.

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

<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>true</ExternalAuthorization>

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

<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 को जवाब में सेकंड में दिखाया जाता है.

<GenerateErrorResponse> एलिमेंट

<GenerateErrorResponse enabled='true'/>

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

<GrantType>

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

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

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

<ऑपरेशन> एलिमेंट

<Operation>GenerateAuthorizationCode</Operation>

OAuth 2.0 कार्रवाई, जो नीति लागू करती है.

<PassWord> एलिमेंट

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

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

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

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

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

<redirectUri> एलिमेंट

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

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

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

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

• (ज़रूरी है) अगर कोई कॉलबैक यूआरएल, डेवलपर ऐप्लिकेशन पर रजिस्टर किया गया है और वह अनुरोध के क्लाइंट कुंजियों से जुड़ा है और अगर अनुरोध में redirect_uri मौजूद है, तो दोनों का यूआरएल पूरी तरह से मेल खाना चाहिए. अगर वे आपस में मेल नहीं खाते, तो गड़बड़ी का मैसेज दिखता है. Edge पर डेवलपर ऐप्लिकेशन रजिस्टर करने और कॉलबैक यूआरएल की जानकारी के लिए, ऐप्लिकेशन रजिस्टर करें और एपीआई कुंजियां मैनेज करें देखें.

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

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

<RefreshToken> एलिमेंट

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

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

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

<रीफ़्रेशTokenExpiresIn> एलिमेंट

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

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

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

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

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

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

1. message-processor.properties फ़ाइल को किसी एडिटर में खोलें. अगर फ़ाइल मौजूद नहीं है, तो इसे बनाएं:

   vi /opt/apigee/customer/application/message-processor.properties

2. प्रॉपर्टी को अपने हिसाब से सेट करें:

   conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000

3. पक्का करें कि प्रॉपर्टी फ़ाइल का मालिकाना हक, "apigee" उपयोगकर्ता के पास हो:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. मैसेज प्रोसेसर को रीस्टार्ट करें.

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

<ResponseType> एलिमेंट

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

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

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

<ReuseRefreshToken> एलिमेंट

<ReuseRefreshToken>true</ReuseRefreshToken>

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

<Scope> एलिमेंट

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

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

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

<Scope>A B</Scope>

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

<State> एलिमेंट

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

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

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

<StoreToken> एलिमेंट

 <StoreToken>true</StoreToken> 

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

<supportedGrantTypes>/<GrantType> एलिमेंट

<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 पैरामीटर की वैल्यू, इस्तेमाल किए जा सकने वाले किसी एक तरह के अनुदान से मेल खाती हो.

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

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

<UserName> एलिमेंट

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

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

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

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

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

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

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

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

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

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

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

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

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

ऐक्सेस टोकन की पुष्टि करना और ऐक्सेस टोकन और ऑथराइज़ेशन कोड का अनुरोध करना भी देखें.

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

नीति के तहत, हर तरह के अनुदान के लिए, मैसेज में जगह की जानकारी या ज़रूरी जानकारी का अनुमान लगाया जाता है. ये अनुमान, 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 नीतियों के लागू होने पर अपने-आप भर जाते हैं. इसलिए, ये वैरिएबल उन दूसरी नीतियों या ऐप्लिकेशन के लिए उपलब्ध होते हैं जिन्हें एपीआई प्रॉक्सी फ़्लो में लागू किया जाता है.

पुष्टि करने के लिए AccessToken की कार्रवाई

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

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

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

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

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

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

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

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

जनरेटर कोड कार्रवाई

ये वैरिएबल तब सेट किए जाते हैं, जब generateAuthorizeCode कार्रवाई सही तरीके से पूरी हो जाती है:

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

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

BringAccessToken और RefreshAccessToken की कार्रवाइयां तय की जाती हैं

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

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

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

GenerateAccessTokenImplicitGrant

ये वैरिएबल तब सेट किए जाते हैं, जब generateAccessTokenImplicit कार्रवाई, इंप्लिसिट ग्रांट टाइप फ़्लो के लिए सही तरीके से लागू होती है.

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

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

गड़बड़ी के बारे में जानकारी

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

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

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

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

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

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

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

गड़बड़ी के जवाब का उदाहरण

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

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

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

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

ऐक्सेस टोकन को इंस्टॉल करना

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

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

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

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

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

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

आरएफ़सी का पालन न करने वाला व्यवहार

OAuthV2 नीति, टोकन रिस्पॉन्स के तौर पर दिखती है. इसमें कुछ ऐसी प्रॉपर्टी होती हैं जो आरएफ़सी का पालन नहीं करती हैं. इस टेबल में उन प्रॉपर्टी को दिखाया गया है जो OAuthV2 नीति का पालन नहीं करने वाली हैं और नीति का पालन करती हैं.

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

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

हालांकि, RFC का पालन करने वाला जवाब यह है:

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

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

• OAuth 2.0 के बारे में जानकारी