तीसरे पक्ष के OAuth टोकन का इस्तेमाल करना

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

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

आम तौर पर, Apigee Edge, OAuth टोकन जनरेट और सेव करेगा. साथ ही, उसे कॉल करने वाले ऐप्लिकेशन में वापस भेज देगा. इसके बाद, कॉल करने के लिए इस्तेमाल होने वाला ऐप्लिकेशन, सेवा का अनुरोध करने पर उस टोकन को वापस Apigee Edge को दिखाता है. साथ ही, OAuthV2 नीति की मदद से, कार्रवाई = VerificationAccessToken के साथ Apigee Edge से इस बात की पुष्टि होती है कि टोकन मान्य है या नहीं. इस विषय में बताया गया है कि किसी अन्य जगह जनरेट किए गए OAuth टोकन को सेव करने के लिए, Apigee Edge को कैसे कॉन्फ़िगर किया जा सकता है. इसमें, टोकन की पुष्टि करने वाले हिस्से को वैसे ही सेव रखा जाता है जैसा EDGE से जनरेट किया गया हो.

उदाहरण

अगर आपको काम का कोई ऐसा उदाहरण देखना है जिसमें इस विषय में बताई गई तकनीक को दिखाया गया हो, तो Apigee सौंपे गए टोकन मैनेजमेंट का सैंपल देखें.

यह क्या है?

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

कुछ बैकग्राउंड

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

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

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

दूसरी ओर, यहां बताया गया तरीका अपनाकर, टोकन सेव करने के लिए Edge को कॉन्फ़िगर किया जा सकता है. इससे, टोकन की access_token की वैल्यू कोई बाहरी सेवा जनरेट होगी. अन्य सभी मेटाडेटा एक जैसे हो सकते हैं. उदाहरण के लिए, मान लें कि आपके पास Apigee Edge से बाहर का एक सिस्टम है, जो "TOKEN-<16 रैंडम नंबर>" फ़ॉर्म का टोकन जनरेट करता है. इस स्थिति में, Apigee Edge में सेव किया गया पूरा टोकन मेटाडेटा यह हो सकता है:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "TOKEN-1092837373654221",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

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

चलिए, क्लाइंट के क्रेडेंशियल की पुष्टि करने के बारे में बात करते हैं

टोकन जनरेट करने के लिए एक ज़रूरी शर्त यह है कि अनुरोध करने वाले क्लाइंट की पुष्टि की जाए. डिफ़ॉल्ट रूप से, Apigee Edge में, OAuthV2/GenerateAccessToken नीति, क्लाइंट के क्रेडेंशियल की साफ़ तौर पर पुष्टि करती है. आम तौर पर, OAuthV2 टोकन के अनुरोध के मामले में, client_id और client_secret को ऑथराइज़ेशन हेडर में पास किया जाता है, जिन्हें एचटीटीपी बेसिक ऑथराइज़ेशन (कोलन-concatenet और फिर base64-एन्कोडिंग) के ज़रिए कोड में बदला जाता है. Apigee Edge में, OAuthV2/GenerateAccessToken नीति, उस हेडर को डिकोड करती है और client_id को देखती है. साथ ही, यह पुष्टि करती है कि पास किया गया client_secret उस client_id के लिए मान्य है. यह तब काम करता है, जब क्रेडेंशियल Apigee Edge के साथ काम करते हैं - दूसरे शब्दों में, Apigee Edge में एक डेवलपर ऐप्लिकेशन सेव किया गया है, जिसमें एक क्रेडेंशियल शामिल है. इस क्रेडेंशियल में, दिए गए client_id और client_secret को शामिल किया गया है.

अगर Apigee Edge से क्लाइंट क्रेडेंशियल की पुष्टि नहीं की जानी है, तो आपको अपना एपीआई प्रॉक्सी डिज़ाइन करना होगा. इसके बाद ही, वह टोकन जनरेट करेगा. इससे, क्लाइंट की पुष्टि अन्य तरीकों से साफ़ तौर पर की जा सकेगी. अक्सर ऐसा सेवा कॉलआउट की नीति के ज़रिए होता है, जो आपके नेटवर्क में रिमोट एंडपॉइंट से कनेक्ट होती है.

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

अगर आपको Apigee Edge में OAuthV2/generateAccessToken नीति की मदद से, Edge स्टोर के क्लाइंट क्रेडेंशियल की पुष्टि करनी है, तो नीति के कॉन्फ़िगरेशन में <ExternalAuthorization> एलिमेंट को false पर सेट करें या इसे पूरी तरह से हटा दें. अगर आपको क्लाइंट के क्रेडेंशियल की साफ़ तौर पर पुष्टि करने के लिए, किसी बाहरी अनुमति सेवा का इस्तेमाल करना है, तो <ExternalAuthorization> को true पर सेट करें.

Apigee Edge, हो सकता है कि क्लाइंट के क्रेडेंशियल की पुष्टि न कर पाए, लेकिन इसके बाद भी Client_id को Apigee Edge से जाना और मैनेज करना ज़रूरी है. Apigee Edge में मौजूद हर access_token, क्लाइंट ऐप्लिकेशन से जुड़ा होना चाहिए. भले ही, उसे Apigee Edge से जनरेट किया गया हो या किसी बाहरी सिस्टम से जनरेट किया गया हो. इसके बाद, वह क्लाइंट ऐप्लिकेशन से जुड़ा होना चाहिए. इस क्लाइंट ऐप्लिकेशन के बारे में client_id से पता चलता है. इसलिए, किसी ऐसे मामले में भी जहां Apigee Edge में, OAuthV2/generateAccessToken नीति इस बात की पुष्टि नहीं करेगी कि client_id और client_secret मैच होते हैं, तो नीति इस बात की पुष्टि करेगी कि client_id मान्य है, मौजूद है, और उसे वापस नहीं लिया गया है. इसलिए, सेटअप करने से पहले ज़रूरी चरण के तौर पर, आपको Edge एडमिन एपीआई के ज़रिए client_id को इंपोर्ट करना पड़ सकता है.

Apigee पर तीसरे पक्ष के OAuth के लिए नीति फ़्लो

Apigee Edge में तीसरे पक्ष के OAuth सिस्टम के टोकन का इस्तेमाल करने के लिए, ऐक्सेस टोकन जनरेट करने का फ़्लो, इनमें से किसी एक पैटर्न के हिसाब से होना चाहिए.

क्लाइंट के क्रेडेंशियल की बाहरी पुष्टि

1. ServiceCallout का इस्तेमाल करके, इनबाउंड क्लाइंट के क्रेडेंशियल की पुष्टि करें और बाहरी टोकन पाएं.
2. रिस्पॉन्स से बाहर से जनरेट किए गए टोकन को एक्सट्रैक्ट करने के लिए, ExtractVariables या JavaScript चरण.
3. AssignMessage का इस्तेमाल करके, oauth_external_authorization_status नाम के खास वैरिएबल को सेट करें. वैल्यू सही होनी चाहिए, ताकि यह पता चल सके कि क्लाइंट क्रेडेंशियल मान्य हैं.
4. OAuthV2/GenerateAccessToken, <ExternalAuthorization> एलिमेंट को true पर सेट किया गया है. साथ ही, <ExternalAccessToken>, <ExternalRefreshToken> या <ExternalAuthorizationCode> में से कम से कम एक एलिमेंट को शामिल किया गया है.

क्लाइंट के क्रेडेंशियल की अंदरूनी तौर पर पुष्टि

• किसी बाहरी टोकन को पाने के लिए, ServiceCallout का इस्तेमाल करें.
• रिस्पॉन्स से बाहर से जनरेट किए गए टोकन को एक्सट्रैक्ट करने के लिए, ExtractVariables या JavaScript चरण.
• OAuthV2/GenerateAccessToken, <ExternalAuthorization> एलिमेंट को false पर सेट किया गया है. साथ ही, <ExternalAccessToken>, <ExternalRefreshToken> या <ExternalAuthorizationCode> में से कम से कम एक एलिमेंट को शामिल किया गया है.

फ़्लो और नीति कॉन्फ़िगरेशन के बारे में जानकारी

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

• सेवा कॉलआउट के बाद, एपीआई प्रॉक्सी को मान्य होने की स्थिति जानने के लिए, रिस्पॉन्स को पार्स करना होगा. साथ ही, बाहर से जनरेट किया गया access_token और रीफ़्रेश_token को भी पार्स करना होगा.

• OAuthV2/GenerateAccessToken नीति में, <StoreToken> एलिमेंट को true पर सेट करें. साथ ही, <ExternalAuthorization> एलिमेंट को ज़रूरत के मुताबिक true या false पर सेट करें.

  जब OAuthV2/GenerateAccessToken नीति लागू होती है, तो यह वैरिएबल oauth_external_authorization_status को पढ़ता है. अगर वैरिएबल सेट किया गया है और वैल्यू सही है, तो Apigee Edge क्लाइंट के क्रेडेंशियल की पुष्टि करने की कोशिश नहीं करता है. अगर वैरिएबल सेट नहीं है या वैल्यू सही नहीं है, तो Apigee Edge क्लाइंट के क्रेडेंशियल की पुष्टि करने की कोशिश करेगा.

• OAuthV2 नीति के ऐसे तीन एलिमेंट हैं जो आपको इंपोर्ट करने के लिए, बाहरी डेटा तय करने की सुविधा देते हैं: <ExternalAccessToken>, <ExternalRefreshToken>, और <ExternalAuthorizationCode>. इनमें से हर एलिमेंट, एक फ़्लो वैरिएबल को स्वीकार करता है. Edge नीति उस वैरिएबल को पढ़कर सुनाएगी, ताकि वह बाहरी तौर पर जनरेट किया गया ऐक्सेस टोकन, रीफ़्रेश टोकन या ऑथराइज़ेशन कोड खोज सके. यह आपकी ज़िम्मेदारी है कि आप नीतियों और तर्क को लागू करें, ताकि बाहरी टोकन या कोड को सही वैरिएबल में रखा जा सके.

  उदाहरण के लिए, OAuthV2 नीति में नीचे दिए गए कॉन्फ़िगरेशन से, Edge को पता चलता है कि external_token नाम के कॉन्टेक्स्ट वैरिएबल में टोकन खोजना है.

  <ExternalAccessToken>external_token</ExternalAccessToken>
  

  आपके पास एक पिछला चरण भी होना चाहिए, जो उस वैरिएबल को सेट करता हो.

• oauth_external_authorization_status वैरिएबल को सेट करने के लिए, इस वैरिएबल को सेट करने की एक आम तकनीक यह है:

  <AssignMessage name="AssignMessage-SetVariable">
      <DisplayName>Assign Message - Set Variable</DisplayName>
      <AssignVariable>
          <Name>oauth_external_authorization_status</Name>
          <Value>true</Value>
      </AssignVariable>
      <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
  </AssignMessage>
  

  याद रखें कि यह नीति, कार्रवाई = generateAccessToken वाली OAuthV2 नीति से पहले लागू होनी चाहिए.

OAuthV2 नीति का उदाहरण

यहां दी गई OAuthV2 नीति, Apigee Edge का ऐक्सेस टोकन जनरेट करती है. हालांकि, यह बताता है कि Edge को फ़्लो वैरिएबल external_access_token में टोकन वैल्यू मिलती है.

<OAuthV2 name="OAuth-v20-Store-External-Token">
    <ExternalAccessToken>external_access_token</ExternalAccessToken>
    <ExternalAuthorization>true</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <GenerateResponse enabled="true">
        <Format>FORM_PARAM</Format>
    </GenerateResponse>
    <ReuseRefreshToken>false</ReuseRefreshToken>
    <StoreToken>true</StoreToken>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <ExpiresIn ref='flow.variable'>2400000</ExpiresIn>
</OAuthV2>

खास तौर पर, इस पैटर्न को किसी तीसरे पक्ष की OAuth2 की अनुमति देने वाली सेवा के साथ लागू किया जा सकता है.