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, client_id और client_secret की पुष्टि, Apigee Edge के अनुमति स्टोर के हिसाब से करता है. तीसरे पक्ष के 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>

इस नीति से यह पता चलता है कि अनुरोध में पास किए गए Grant Type पैरामीटर को कहां ढूंढना है. 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.expires_in">
    3600000 <!--default value in milliseconds-->
</RefreshTokenExpiresIn>

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="VerifyOAuthAccessToken">
  <Operation>VerifyAccessToken</Operation>
</OAuthV2>

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

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

गड़बड़ी का रेफ़रंस

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

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

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

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

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

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

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

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

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

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

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

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 के बारे में जानकारी