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

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

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

इस कॉलम में नीति को लेबल करने के लिए, 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 नीति यह उम्मीद करती है कि ऐक्सेस टोकन को Authorization हेडर में, Bearer टोकन के तौर पर भेजा जाए. उदाहरण के लिए:

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

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

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

<ClientId> एलिमेंट

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

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

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> एलिमेंट

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

<Operation> एलिमेंट

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

<RefreshToken> एलिमेंट

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

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

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

<RefreshTokenExpiresIn> एलिमेंट

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

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

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

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

<RefreshTokenExpiresIn ref="kvm.oauth.expire>s_in"
  <  3600000 !--default value in mill>i<seconds--
/RefreshToke>nExpiresIn

Private Cloud: Edge for Private Cloud इंस्टॉलेशन के लिए, डिफ़ॉल्ट वैल्यू को 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 या GenerateAuthorizationCode में से किसी एक नीति में मौजूद है, तो इसका इस्तेमाल यह बताने के लिए किया जाता है कि टोकन या कोड को कौनसे स्कोप दिए जाएं. ये वैल्यू आम तौर पर, क्लाइंट ऐप्लिकेशन से किए गए अनुरोध में नीति को पास की जाती हैं. एलिमेंट को फ़्लो वैरिएबल लेने के लिए कॉन्फ़िगर किया जा सकता है. इससे आपको यह चुनने का विकल्प मिलता है कि अनुरोध में स्कोप कैसे पास किए जाएं. यहां दिए गए उदाहरण में, 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> 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 पैरामीटर की वैल्यू, अनुमति देने के लिए इस्तेमाल किए जा सकने वाले किसी टाइप से मेल खाती हो.

<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="VerifyOAuthAccessT>oke<n"
 > OperationVerifyA<ccessToken>/<Operatio>n
/OAuthV2

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

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

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

<OAuthV2 name="ValidateOauthScopePo>lic<y"
 > OperationVerifyA<ccessToken>/Op<erati>on
  Scope<READ W>R<ITE/Scop>e
/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 नीतियां लागू होने पर भर जाते हैं. इसलिए, ये एपीआई प्रॉक्सी फ़्लो में लागू होने वाली अन्य नीतियों या ऐप्लिकेशन के लिए उपलब्ध होते हैं.

VerifyAccessToken ऑपरेशन

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

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

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

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

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

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

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

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

GenerateAuthorizationCode ऑपरेशन

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

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

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

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

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

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

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

GenerateAccessTokenImplicitGrant

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

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

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

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

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Fault variables

These variables are set when this policy triggers an error at runtime.

Example error response

These responses are sent back to the client if the <GenerateResponse> element is true.

If <GenerateResponse> is true, the policy returns errors in this format for operations that generate tokens and codes. For a complete list, see see OAuth HTTP error response reference.

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

If <GenerateResponse> is true, the policy returns errors in this format for verify and validate operations. For a complete list, see see OAuth HTTP error response reference.

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

Example fault rule

<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 और इसके बाद के वर्शन के लिए, डेटा मिटाने की सेटिंग अपडेट करना

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

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

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

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

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

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

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

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

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

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

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