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

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

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

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

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

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

<ClientId> एलिमेंट

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

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

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

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

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

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

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

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

<GrantType>

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

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

उदाहरण के लिए, request.queryparam.grant_type से पता चलता है कि पासवर्ड, क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए, जैसे कि ?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 से पता चलता है कि रीडायरेक्शन को क्वेरी पैरामीटर के तौर पर मौजूद होना चाहिए, जैसे कि ?redirect_uri=login.myapp.com. उदाहरण के लिए, किसी एचटीटीपी हेडर में रीडायरेक्शन का इस्तेमाल करने के लिए, इस वैल्यू को 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>

निजी क्लाउड: 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>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> एलिमेंट

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

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

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

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> एलिमेंट सही है.

अगर <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 एंडपॉइंट को समझना लेख पढ़ें.

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

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

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

हालांकि, आरएफ़सी के मुताबिक जवाब यह है:

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

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

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