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

यहां Apigee Edge से जुड़े दस्तावेज़ देखे जा रहे हैं.
Apigee X से जुड़े दस्तावेज़ पर जाएं. info

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

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

उदाहरण

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

यह क्या है?

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

कुछ ज़रूरी जानकारी

आम तौर पर, Apigee Edge, अक्षरों और अंकों की रैंडम स्ट्रिंग जनरेट करके टोकन बनाता है. Apigee Edge, उस टोकन से जुड़ा अन्य डेटा भी सेव करता है. जैसे, टोकन जारी होने का समय, इसकी समयसीमा खत्म होने की तारीख, एपीआई प्रॉडक्ट की वह सूची जिसके लिए टोकन मान्य है, और स्कोप. यह सारी जानकारी, Operation = 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 के साथ अनुरोध कर सकता है. वहीं, Edge, Operation = VerifyAccessToken के साथ OAuthV2 नीति के ज़रिए, टोकन को देखेगा, सारी जानकारी वापस पाएगा, और उस जानकारी का इस्तेमाल करके यह तय करेगा कि अनुरोध की गई एपीआई प्रॉक्सी के लिए टोकन मान्य है या नहीं. इसे टोकन की पुष्टि कहा जाता है. ऊपर दी गई सारी जानकारी, टोकन में शामिल होती है. 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"
}

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

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

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

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

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

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

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

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

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

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

1. ServiceCallout 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> में से कम से कम एक का इस्तेमाल करें.

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

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

• ServiceCallout के बाद, एपीआई प्रॉक्सी को जवाब पार्स करना होगा, ताकि वैधता की स्थिति के साथ-साथ, बाहरी तौर पर जनरेट किया गया access_token और शायद refresh_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 नीति के साथ AssignVariable एलिमेंट का इस्तेमाल करना है. जैसे:

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

  ध्यान रखें कि यह नीति, Operation = 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 ऑथराइज़ेशन सेवा के साथ लागू किया जा सकता है.