OAuthV2 নীতি

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।

কী

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

নিম্নলিখিত সারণী সমস্ত নীতির মূল উপাদানগুলির জন্য সাধারণ বৈশিষ্ট্যগুলি বর্ণনা করে:

<DisplayName> উপাদান

ম্যানেজমেন্ট UI প্রক্সি এডিটরে নীতিটিকে একটি ভিন্ন, প্রাকৃতিক-ভাষা নামের সাথে লেবেল করতে name বৈশিষ্ট্য ছাড়াও ব্যবহার করুন।

<DisplayName>Policy Display Name</DisplayName>

<অ্যাক্সেস টোকেন> উপাদান

<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 কোথায় এন্ড ইউজার আইডিটি খুঁজবে। উদাহরণস্বরূপ, এটি একটি কোয়েরি প্যারামিটার হিসেবে অথবা একটি HTTP হেডারে পাঠানো যেতে পারে।

উদাহরণস্বরূপ, request.queryparam.app_enduser নির্দেশ করে যে AppEndUser-কে একটি কোয়েরি প্যারামিটার হিসেবে উপস্থিত থাকতে হবে, যেমন, ?app_enduser=ntesla@theramin.com । উদাহরণস্বরূপ, একটি HTTP হেডারে 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 মনে রাখে না যে generate access token পলিসিতে display অ্যাট্রিবিউটটি মূলত false সেট করা হয়েছিল—কাস্টম অ্যাট্রিবিউটটি কেবল অ্যাক্সেস টোকেনের মেটাডেটার একটি অংশ।

আপনি যদি কোনো অথরাইজেশন কোডে কাস্টম অ্যাট্রিবিউট যোগ করেন, তাহলেও একই আচরণ দেখতে পাবেন—যখন সেই কোড ব্যবহার করে একটি অ্যাক্সেস টোকেন তৈরি করা হবে, তখন সেই কাস্টম অ্যাট্রিবিউটগুলো অ্যাক্সেস টোকেন রেসপন্সে প্রদর্শিত হবে। আবারও বলছি, এটি হয়তো আপনার কাঙ্ক্ষিত আচরণ নয়।

এইসব ক্ষেত্রে কাস্টম অ্যাট্রিবিউট লুকানোর জন্য আপনার কাছে এই বিকল্পগুলো রয়েছে:

• রিফ্রেশ টোকেন পলিসিতে কাস্টম অ্যাট্রিবিউটগুলো স্পষ্টভাবে রিসেট করুন এবং সেগুলোর ডিসপ্লে 'ফলস' (false) সেট করুন। এক্ষেত্রে, আপনাকে GetOAuthV2Info পলিসি ব্যবহার করে মূল অ্যাক্সেস টোকেন থেকে আসল কাস্টম ভ্যালুগুলো পুনরুদ্ধার করতে হতে পারে।
• রেসপন্সে আপনি যে কাস্টম অ্যাট্রিবিউটগুলো দেখতে চান না, সেগুলো ম্যানুয়ালি এক্সট্র্যাক্ট করতে একটি পোস্টপ্রসেসিং জাভাস্ক্রিপ্ট পলিসি ব্যবহার করুন।

টোকেন এবং অনুমোদন কোড কাস্টমাইজ করাও দেখুন।

<ক্লায়েন্ট আইডি> উপাদান

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

অনেক ক্ষেত্রে, ক্লায়েন্ট অ্যাপকে অবশ্যই অথরাইজেশন সার্ভারে ক্লায়েন্ট আইডি পাঠাতে হয়। এই এলিমেন্টটি নির্দিষ্ট করে যে Apigee যেন request.formparam.client_id ফ্লো ভ্যারিয়েবলে ক্লায়েন্ট আইডিটি খোঁজে। ClientId অন্য কোনো ভ্যারিয়েবলে সেট করা সমর্থিত নয়। আরও দেখুন অ্যাক্সেস টোকেন এবং অথরাইজেশন কোডের জন্য অনুরোধ ।

<কোড> উপাদান

<Code>request.queryparam.code</Code>

অনুমোদন মঞ্জুর করার প্রক্রিয়ার সময়, ক্লায়েন্টকে অবশ্যই অনুমোদন সার্ভারে (Apigee Edge) একটি অনুমোদন কোড জমা দিতে হবে। এই উপাদানটি আপনাকে নির্দিষ্ট করতে দেয় যে Edge কোথায় অনুমোদন কোডটি খুঁজবে। উদাহরণস্বরূপ, এটি একটি কোয়েরি প্যারামিটার, HTTP হেডার, বা ফর্ম প্যারামিটার (ডিফল্ট) হিসাবে পাঠানো যেতে পারে।

request.queryparam.auth_code ভ্যারিয়েবলটি নির্দেশ করে যে অথরাইজেশন কোডটি একটি কোয়েরি প্যারামিটার হিসেবে উপস্থিত থাকা উচিত, যেমন, ?auth_code=AfGlvs9 । উদাহরণস্বরূপ, একটি HTTP হেডারে অথরাইজেশন কোডটি আবশ্যক করতে, এই মানটিকে request.header.auth_code এ সেট করুন। আরও দেখুন `অ্যাক্সেস টোকেন এবং অথরাইজেশন কোডের জন্য অনুরোধ` ।

<ExpiresIn> উপাদান

<ExpiresIn>10000</ExpiresIn>

মিলিসেকেন্ডে অ্যাক্সেস টোকেন এবং অথরাইজেশন কোডের মেয়াদ শেষ হওয়ার সময় কার্যকর করে। (রিফ্রেশ টোকেনের জন্য, <RefreshTokenExpiresIn> ব্যবহার করুন।) মেয়াদ শেষ হওয়ার সময়ের মানটি হলো সিস্টেম-জেনারেটেড একটি মান এবং <ExpiresIn> মানের যোগফল। যদি <ExpiresIn> -1 এ সেট করা হয়, তাহলে টোকেন বা কোডটির মেয়াদ সর্বোচ্চ OAuth অ্যাক্সেস টোকেনের মেয়াদ শেষ হওয়ার সময় অনুযায়ী শেষ হয়ে যায়। যদি <ExpiresIn> নির্দিষ্ট করা না থাকে, তাহলে সিস্টেম লেভেলে কনফিগার করা একটি ডিফল্ট মান প্রয়োগ করা হয়।

মেয়াদ শেষ হওয়ার সময়টি রানটাইমেও সেট করা যেতে পারে, হয় একটি হার্ড-কোডেড ডিফল্ট মান ব্যবহার করে অথবা একটি ফ্লো ভেরিয়েবল রেফারেন্স করার মাধ্যমে। উদাহরণস্বরূপ, আপনি একটি কী-ভ্যালু ম্যাপে টোকেনের মেয়াদ শেষ হওয়ার মান সংরক্ষণ করতে পারেন, সেটি পুনরুদ্ধার করে একটি ভেরিয়েবলে অ্যাসাইন করতে পারেন এবং পলিসিতে রেফারেন্স করতে পারেন। যেমন, kvm.oauth.expires_in ।

Apigee Edge for Public Cloud-এর মাধ্যমে, কোনো এনটিটি অ্যাক্সেস করার পর Edge সেটিকে ন্যূনতম ১৮০ সেকেন্ডের জন্য ক্যাশে সংরক্ষণ করে।

• OAuth অ্যাক্সেস টোকেন। এর মানে হলো, একটি বাতিল করা টোকেনও তার ক্যাশে সীমা শেষ না হওয়া পর্যন্ত সর্বোচ্চ তিন মিনিট পর্যন্ত সফল হতে পারে।
• কী ম্যানেজমেন্ট সার্ভিস (কেএমএস) সত্তাসমূহ (অ্যাপস, ডেভেলপার, এপিআই প্রোডাক্টস)।
• 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>request.queryparam.external_access_token</ExternalAccessToken>

Apigee Edge-কে বলে দেয় একটি এক্সটার্নাল অ্যাক্সেস টোকেন (যে অ্যাক্সেস টোকেন Apigee Edge দ্বারা তৈরি করা হয়নি) কোথায় খুঁজে পাওয়া যাবে।

request.queryparam.external_access_token ভ্যারিয়েবলটি নির্দেশ করে যে এক্সটার্নাল অ্যাক্সেস টোকেনটি একটি কোয়েরি প্যারামিটার হিসেবে উপস্থিত থাকা উচিত, যেমন, ?external_access_token=12345678 । উদাহরণস্বরূপ, একটি HTTP হেডারে এক্সটার্নাল অ্যাক্সেস টোকেনটি আবশ্যক করতে, এই মানটিকে request.header.external_access_token এ সেট করুন। আরও দেখুন ` তৃতীয় পক্ষের OAuth টোকেন ব্যবহার` ।

<বাহ্যিক অনুমোদন> উপাদান

<ExternalAuthorization>true</ExternalAuthorization>

যদি এই এলিমেন্টটি false হয় বা উপস্থিত না থাকে, তাহলে Edge স্বাভাবিকভাবে Apigee Edge অথরাইজেশন স্টোরের বিপরীতে client_id এবং client_secret যাচাই করে। যখন আপনি থার্ড-পার্টি OAuth টোকেন নিয়ে কাজ করতে চান, তখন এই এলিমেন্টটি ব্যবহার করুন। এই এলিমেন্টটি ব্যবহারের বিস্তারিত জানতে, “Using Third-Party OAuth Tokens ” দেখুন।

<বাহ্যিক অনুমোদন কোড> উপাদান

<ExternalAuthorizationCode>request.queryparam.external_auth_code</ExternalAuthorizationCode>

Apigee Edge-কে বলে দেয় যে একটি এক্সটার্নাল অথ কোড (যে অথ কোডটি Apigee Edge তৈরি করেনি) কোথায় খুঁজে পাওয়া যাবে।

request.queryparam.external_auth_code ভ্যারিয়েবলটি নির্দেশ করে যে এক্সটার্নাল অথ কোডটি একটি কোয়েরি প্যারামিটার হিসেবে উপস্থিত থাকা উচিত, যেমন, ?external_auth_code=12345678 । উদাহরণস্বরূপ, একটি HTTP হেডারে এক্সটার্নাল অথ কোডটি আবশ্যক করতে, এই মানটিকে 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 । উদাহরণস্বরূপ, একটি HTTP হেডারে এক্সটার্নাল রিফ্রেশ টোকেনটি আবশ্যক করতে, এই মানটিকে 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' অ্যাট্রিবিউটটি 'true' হলে পলিসিটি একটি রেসপন্স তৈরি করে এবং ফেরত পাঠায়। যদি false (ডিফল্ট) হয়, কোনো রেসপন্স পাঠানো হয় না। এর পরিবর্তে, পলিসির ফাংশনের সাথে সম্পর্কিত মান দিয়ে এক সেট ফ্লো ভেরিয়েবল পূরণ করা হয়।

অনুদানের ধরণ

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

অনুরোধে পাঠানো গ্রান্ট টাইপ প্যারামিটারটি কোথায় পাওয়া যাবে, তা পলিসিকে জানিয়ে দেয়। OAuth 2.0 স্পেসিফিকেশন অনুযায়ী, অ্যাক্সেস টোকেন এবং অথরাইজেশন কোডের অনুরোধের ক্ষেত্রে গ্রান্ট টাইপ অবশ্যই সরবরাহ করতে হবে। ভেরিয়েবলটি একটি হেডার, কোয়েরি প্যারামিটার, বা ফর্ম প্যারামিটার (ডিফল্ট) হতে পারে।

উদাহরণস্বরূপ, request.queryparam.grant_type নির্দেশ করে যে পাসওয়ার্ডটি একটি কোয়েরি প্যারামিটার হিসেবে উপস্থিত থাকা উচিত, যেমন, ?grant_type=password । উদাহরণস্বরূপ, একটি HTTP হেডারে গ্রান্ট টাইপটি বাধ্যতামূলক করতে, এই মানটি request.header.grant_type এ সেট করুন। আরও দেখুন অ্যাক্সেস টোকেন এবং অনুমোদন কোডের জন্য অনুরোধ ।

<অপারেশন> উপাদান

<Operation>GenerateAuthorizationCode</Operation>

পলিসি দ্বারা সম্পাদিত OAuth 2.0 অপারেশন।

<পাসওয়ার্ড> উপাদান

<PassWord>request.queryparam.password</PassWord>

এই এলিমেন্টটি শুধুমাত্র পাসওয়ার্ড গ্রান্ট টাইপের সাথে ব্যবহৃত হয় । পাসওয়ার্ড গ্রান্ট টাইপের ক্ষেত্রে, ব্যবহারকারীর ক্রেডেনশিয়াল (পাসওয়ার্ড এবং ইউজারনেম) অবশ্যই OAuthV2 পলিসির কাছে উপলব্ধ করতে হবে। <PassWord> এবং <UserName> এলিমেন্টগুলো এমন ভ্যারিয়েবল নির্দিষ্ট করতে ব্যবহৃত হয়, যেখানে Edge এই ভ্যালুগুলো খুঁজে পেতে পারে। যদি এই এলিমেন্টগুলো নির্দিষ্ট করা না থাকে, তাহলে পলিসিটি (ডিফল্টরূপে) username এবং password নামের ফর্ম প্যারামিটারগুলোতে ভ্যালুগুলো খুঁজে পাওয়ার আশা করে। যদি ভ্যালুগুলো খুঁজে না পাওয়া যায়, তাহলে পলিসিটি একটি এরর দেখায়। ক্রেডেনশিয়াল ধারণকারী যেকোনো ফ্লো ভ্যারিয়েবলকে রেফারেন্স করতে আপনি <PassWord> এবং <UserName> এলিমেন্টগুলো ব্যবহার করতে পারেন।

উদাহরণস্বরূপ, আপনি একটি কোয়েরি প্যারামিটার ব্যবহার করে টোকেন অনুরোধে পাসওয়ার্ডটি পাঠাতে পারেন এবং এলিমেন্টটি এইভাবে সেট করতে পারেন: <PassWord>request.queryparam.password</PassWord> . HTTP হেডারে পাসওয়ার্ডটি বাধ্যতামূলক করতে, এই মানটি request.header.password এ সেট করুন।

OAuthV2 পলিসি এই ক্রেডেনশিয়াল ভ্যালুগুলো নিয়ে আর কিছুই করে না; Edge শুধুমাত্র যাচাই করে যে সেগুলো উপস্থিত আছে কিনা। টোকেন জেনারেশন পলিসি কার্যকর হওয়ার আগে, ভ্যালু রিকোয়েস্টটি গ্রহণ করে কোনো আইডেন্টিটি প্রোভাইডারের কাছে পাঠানোর দায়িত্ব এপিআই ডেভেলপারের।

আরও দেখুন অ্যাক্সেস টোকেন এবং অনুমোদন কোডের জন্য অনুরোধ ।

<RedirectUri> উপাদান

<RedirectUri>request.queryparam.redirect_uri</RedirectUri>

অনুরোধে redirect_uri প্যারামিটারটি Edge কোথায় খুঁজবে তা নির্দিষ্ট করে।

পুনঃনির্দেশনা URI সম্পর্কে

রিডাইরেকশন ইউআরআই অথরাইজেশন কোড এবং ইমপ্লিসিট গ্রান্ট টাইপের সাথে ব্যবহৃত হয়। রিডাইরেক্ট ইউআরআই অথরাইজেশন সার্ভারকে (Edge) বলে দেয় যে, অথরাইজেশন কোড (অথ কোড গ্রান্ট টাইপের জন্য) অথবা অ্যাক্সেস টোকেন (ইমপ্লিসিট গ্রান্ট টাইপের জন্য) কোথায় পাঠাতে হবে। এই প্যারামিটারটি কখন আবশ্যক, কখন ঐচ্ছিক এবং কীভাবে ব্যবহৃত হয়, তা বোঝা জরুরি।

• (আবশ্যক) যদি অনুরোধের ক্লায়েন্ট কী-গুলির সাথে যুক্ত ডেভেলপার অ্যাপে একটি কলব্যাক ইউআরএল নিবন্ধিত থাকে এবং অনুরোধে redirect_uri উপস্থিত থাকে, তবে এই দুটিকে অবশ্যই হুবহু মিলতে হবে। যদি না মেলে, তাহলে একটি ত্রুটি দেখানো হবে। Edge-এ ডেভেলপার অ্যাপ নিবন্ধন করা এবং কলব্যাক ইউআরএল নির্দিষ্ট করার বিষয়ে তথ্যের জন্য, "অ্যাপ নিবন্ধন করুন এবং এপিআই কী পরিচালনা করুন" দেখুন।

• (ঐচ্ছিক) যদি একটি কলব্যাক ইউআরএল নিবন্ধিত থাকে এবং অনুরোধে redirect_uri অনুপস্থিত থাকে, তাহলে Edge নিবন্ধিত কলব্যাক ইউআরএল-এ রিডাইরেক্ট করে।
• (আবশ্যক) যদি কোনো কলব্যাক ইউআরএল (Callback URL) রেজিস্টার করা না থাকে, তাহলে redirect_uri ) আবশ্যক। মনে রাখবেন যে, এই ক্ষেত্রে Edge যেকোনো ইউআরএল (URL) গ্রহণ করবে। এই পরিস্থিতিটি একটি নিরাপত্তা ঝুঁকি তৈরি করতে পারে, এবং তাই এটি শুধুমাত্র বিশ্বস্ত ক্লায়েন্ট অ্যাপের সাথেই ব্যবহার করা উচিত। যদি ক্লায়েন্ট অ্যাপগুলো বিশ্বস্ত না হয়, তাহলে সর্বদা একটি কলব্যাক ইউআরএল রেজিস্টার করা আবশ্যক করাই সর্বোত্তম পন্থা।

আপনি এই প্যারামিটারটি একটি কোয়েরি প্যারামিটার হিসেবে অথবা একটি হেডারে পাঠাতে পারেন। request.queryparam.redirect_uri ভ্যারিয়েবলটি নির্দেশ করে যে `RedirectUri` একটি কোয়েরি প্যারামিটার হিসেবে উপস্থিত থাকা উচিত, যেমন, ?redirect_uri=login.myapp.com । উদাহরণস্বরূপ, একটি HTTP হেডারে `RedirectUri`-কে আবশ্যক করতে, এই মানটিকে request.header.redirect_uri তে সেট করুন। আরও দেখুন `অ্যাক্সেস টোকেন এবং অথরাইজেশন কোডের জন্য অনুরোধ` ।

<রিফ্রেশটোকেন> উপাদান

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

রিফ্রেশ টোকেন ব্যবহার করে অ্যাক্সেস টোকেনের অনুরোধ করার সময়, আপনাকে অবশ্যই অনুরোধে রিফ্রেশ টোকেনটি সরবরাহ করতে হবে। এই এলিমেন্টটি আপনাকে নির্দিষ্ট করতে দেয় যে Edge রিফ্রেশ টোকেনটি কোথায় খুঁজবে। উদাহরণস্বরূপ, এটি একটি কোয়েরি প্যারামিটার, HTTP হেডার, বা ফর্ম প্যারামিটার (ডিফল্ট) হিসাবে পাঠানো যেতে পারে।

request.queryparam.refreshtoken ভ্যারিয়েবলটি নির্দেশ করে যে রিফ্রেশ টোকেনটি একটি কোয়েরি প্যারামিটার হিসেবে উপস্থিত থাকা উচিত, যেমন, ?refresh_token=login.myapp.com । উদাহরণস্বরূপ, একটি HTTP হেডারে রিফ্রেশ টোকেনটি আবশ্যক করতে, এই মানটি request.header.refresh_token এ সেট করুন। আরও দেখুন `অ্যাক্সেস টোকেন এবং অথরাইজেশন কোডের জন্য অনুরোধ` ।

<RefreshTokenExpiresIn> উপাদান

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

রিফ্রেশ টোকেনের মেয়াদ শেষ হওয়ার সময় মিলিসেকেন্ডে কার্যকর করে। মেয়াদ শেষ হওয়ার সময়ের মানটি হলো সিস্টেম দ্বারা তৈরি একটি মান এবং <RefreshTokenExpiresIn> মানের যোগফল। যদি <RefreshTokenExpiresIn> সেট করা থাকে -1 , সর্বোচ্চ OAuth রিফ্রেশ টোকেন মেয়াদ শেষ হওয়ার তারিখ অনুযায়ী রিফ্রেশ টোকেনটির মেয়াদ শেষ হয়ে যায়। যদি <RefreshTokenExpiresIn> নির্দিষ্ট করা না থাকে, তাহলে সিস্টেমটি সিস্টেম স্তরে কনফিগার করা একটি ডিফল্ট মান প্রয়োগ করে। ডিফল্ট সিস্টেম সেটিংস সম্পর্কে আরও তথ্যের জন্য Apigee Edge Support-এর সাথে যোগাযোগ করুন।

মেয়াদ শেষ হওয়ার সময়টি রানটাইমেও সেট করা যেতে পারে, হয় একটি হার্ড-কোডেড ডিফল্ট মান ব্যবহার করে অথবা একটি ফ্লো ভেরিয়েবল রেফারেন্স করার মাধ্যমে। উদাহরণস্বরূপ, আপনি একটি কী-ভ্যালু ম্যাপে টোকেনের মেয়াদ শেষ হওয়ার মান সংরক্ষণ করতে পারেন, সেটি পুনরুদ্ধার করে একটি ভেরিয়েবলে অ্যাসাইন করতে পারেন এবং পলিসিতে রেফারেন্স করতে পারেন। যেমন, 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> উপাদান

<Scope>request.queryparam.scope</Scope>

যদি এই এলিমেন্টটি GenerateAccessToken বা GenerateAuthorizationCode পলিসিগুলোর কোনো একটিতে উপস্থিত থাকে, তবে এটি টোকেন বা কোডটি কোন স্কোপগুলোতে প্রদান করা হবে তা নির্দিষ্ট করতে ব্যবহৃত হয়। এই মানগুলো সাধারণত একটি ক্লায়েন্ট অ্যাপ থেকে করা অনুরোধের মাধ্যমে পলিসিতে পাঠানো হয়। আপনি এলিমেন্টটিকে একটি ফ্লো ভ্যারিয়েবল গ্রহণ করার জন্য কনফিগার করতে পারেন, যা আপনাকে একটি অনুরোধে স্কোপগুলো কীভাবে পাঠানো হবে তা বেছে নেওয়ার সুযোগ দেয়। নিচের উদাহরণে, request.queryparam.scope নির্দেশ করে যে স্কোপটি একটি কোয়েরি প্যারামিটার হিসেবে উপস্থিত থাকা উচিত, যেমন, ?scope=READ । উদাহরণস্বরূপ, একটি HTTP হেডারে স্কোপটি আবশ্যক করতে, এই মানটিকে request.header.scope এ সেট করুন।

যদি এই এলিমেন্টটি কোনো 'VerifyAccessToken' পলিসিতে থাকে, তাহলে এটি নির্দিষ্ট করতে ব্যবহৃত হয় যে পলিসিটি কোন কোন স্কোপ প্রয়োগ করবে। এই ধরনের পলিসিতে, ভ্যালুটি অবশ্যই একটি 'হার্ড কোডেড' স্কোপের নাম হতে হবে — আপনি ভ্যারিয়েবল ব্যবহার করতে পারবেন না। উদাহরণস্বরূপ:

<Scope>A B</Scope>

আরও দেখুন OAuth2 স্কোপ নিয়ে কাজ করা এবং অ্যাক্সেস টোকেন ও অনুমোদন কোডের জন্য অনুরোধ করা ।

<রাষ্ট্র> উপাদান

<State>request.queryparam.state</State>

যেসব ক্ষেত্রে ক্লায়েন্ট অ্যাপকে অথরাইজেশন সার্ভারে স্টেট তথ্য পাঠাতে হয়, সেখানে Edge স্টেট ভ্যালুগুলো কোথায় খুঁজবে তা নির্দিষ্ট করার জন্য এই এলিমেন্টটি ব্যবহার করা যায়। উদাহরণস্বরূপ, এটি একটি কোয়েরি প্যারামিটার হিসেবে অথবা একটি HTTP হেডারে পাঠানো যেতে পারে। স্টেট ভ্যালুটি সাধারণত CSRF অ্যাটাক প্রতিরোধের জন্য একটি নিরাপত্তা ব্যবস্থা হিসেবে ব্যবহৃত হয়।

উদাহরণস্বরূপ, request.queryparam.state নির্দেশ করে যে স্টেটটি একটি কোয়েরি প্যারামিটার হিসেবে উপস্থিত থাকা উচিত, যেমন, ?state=HjoiuKJH32 । উদাহরণস্বরূপ, একটি HTTP হেডারে স্টেটটি আবশ্যক করতে, এই মানটি request.header.state এ সেট করুন। আরও দেখুন অ্যাক্সেস টোকেন এবং অথরাইজেশন কোডের জন্য অনুরোধ করা ।

<স্টোরটোকেন> উপাদান

 <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 টোকেন এন্ডপয়েন্ট দ্বারা সমর্থিত গ্রান্ট টাইপগুলো নির্দিষ্ট করে। একটি এন্ডপয়েন্ট একাধিক গ্রান্ট টাইপ সমর্থন করতে পারে (অর্থাৎ, একটি একক এন্ডপয়েন্ট একাধিক গ্রান্ট টাইপের জন্য অ্যাক্সেস টোকেন বিতরণ করতে কনফিগার করা যেতে পারে)। এন্ডপয়েন্ট সম্পর্কে আরও জানতে, "Understanding OAuth endpoints" দেখুন। টোকেন অনুরোধে গ্রান্ট টাইপটি একটি grant_type প্যারামিটারে পাস করা হয়।

যদি কোনো সমর্থিত গ্রান্ট টাইপ নির্দিষ্ট করা না থাকে, তাহলে শুধুমাত্র authorization_code এবং implicit গ্রান্ট টাইপগুলোই অনুমোদিত। এছাড়াও <GrantType> এলিমেন্টটি দেখুন (এটি একটি উচ্চ-স্তরের এলিমেন্ট যা নির্দিষ্ট করে যে, ক্লায়েন্ট অনুরোধে পাঠানো grant_type প্যারামিটারটি Apigee Edge কোথায় খুঁজবে। Edge নিশ্চিত করবে যে grant_type প্যারামিটারের মান সমর্থিত গ্রান্ট টাইপগুলোর মধ্যে একটির সাথে মেলে)।

<টোকেন>/<টোকেন> উপাদান

ValidateToken এবং InvalidateToken অপারেশনগুলির সাথে ব্যবহৃত হয়। আরও দেখুন অ্যাক্সেস টোকেন অনুমোদন এবং বাতিল করা । <Token> এলিমেন্টটি সেই ফ্লো ভেরিয়েবলকে শনাক্ত করে যা বাতিলযোগ্য টোকেনের উৎস নির্ধারণ করে। উদাহরণস্বরূপ, যদি ডেভেলপারদের access_token নামের কোয়েরি প্যারামিটার হিসেবে অ্যাক্সেস টোকেন জমা দেওয়ার কথা থাকে, তাহলে request.queryparam.access_token ব্যবহার করুন।

<ব্যবহারকারীর নাম> উপাদান

<UserName>request.queryparam.user_name</UserName>

এই এলিমেন্টটি শুধুমাত্র পাসওয়ার্ড গ্রান্ট টাইপের সাথে ব্যবহৃত হয় । পাসওয়ার্ড গ্রান্ট টাইপের ক্ষেত্রে, ব্যবহারকারীর ক্রেডেনশিয়াল (পাসওয়ার্ড এবং ইউজারনেম) অবশ্যই OAuthV2 পলিসির কাছে উপলব্ধ করতে হবে। <PassWord> এবং <UserName> এলিমেন্টগুলো এমন ভ্যারিয়েবল নির্দিষ্ট করতে ব্যবহৃত হয়, যেখানে Edge এই ভ্যালুগুলো খুঁজে পেতে পারে। যদি এই এলিমেন্টগুলো নির্দিষ্ট করা না থাকে, তাহলে পলিসিটি (ডিফল্টরূপে) username এবং password নামের ফর্ম প্যারামিটারগুলোতে ভ্যালুগুলো খুঁজে পাওয়ার আশা করে। যদি ভ্যালুগুলো খুঁজে না পাওয়া যায়, তাহলে পলিসিটি একটি এরর দেখায়। ক্রেডেনশিয়াল ধারণকারী যেকোনো ফ্লো ভ্যারিয়েবলকে রেফারেন্স করতে আপনি <PassWord> এবং <UserName> এলিমেন্টগুলো ব্যবহার করতে পারেন।

উদাহরণস্বরূপ, আপনি কোয়েরি প্যারামিটারে ইউজারনেমটি পাস করতে পারেন এবং <UserName> এলিমেন্টটি এভাবে সেট করতে পারেন: <UserName>request.queryparam.username</UserName> . HTTP হেডারে ইউজারনেমটি আবশ্যক করতে, এই ভ্যালুটি request.header.username এ সেট করুন।

The OAuthV2 policy doesn't do anything else with these credential values; Edge is simply verifying that they are present. It is up to the API developer to retrieve the values request and send them to an identity provider before the token generation policy executes.

See also Requesting access tokens and authorization codes .

অ্যাক্সেস টোকেন যাচাই করা হচ্ছে

Once a token endpoint is set up for an API proxy, a corresponding OAuthV2 policy that specifies the VerifyAccessToken operation is attached to the Flow that exposes the protected resource.

For example, to ensure that all requests to an API are authorized, the following policy enforces access token verification:

<OAuthV2 name="VerifyOAuthAccessToken">
  <Operation>VerifyAccessToken</Operation>
</OAuthV2>

The policy is attached to the API resource to be protected. To ensure that all requests to an API are verified, attach the policy to the ProxyEndpoint request PreFlow, as follows:

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

The following optional elements can be used to override the default settings for the VerifyAccessToken operation.

<OAuthV2 name="ValidateOauthScopePolicy">
  <Operation>VerifyAccessToken</Operation>
  <Scope>READ WRITE</Scope>
</OAuthV2>

See also Verifying access tokens and Requesting access tokens and authorization codes .

Specifying request variable locations

For each grant type, the policy makes assumptions about the location or required information in request messages. These assumptions are based on the OAuth 2.0 specification. If your apps need to deviate from the OAuth 2.0 specification, then you can specify the expected locations for each parameter. For example, when handling an authorization code, you can specify the location of the authorization code, the client ID, the redirect URI, and the scope. These can be specified as HTTP headers, query parameters, or form parameters.

The example below demonstrates how you can specify the location of required authorization code parameters as HTTP headers:

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

Or, if necessary to support your client app base, you can mix and match headers and query parameters:

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

Only one location can be configured per parameter.

প্রবাহ পরিবর্তনশীল

The flow variables defined in this table are populated when the respective OAuth policies are executed, and hence are available to other policies or applications executing in the API proxy flow.

VerifyAccessToken operation

The VerifyAccessToken operation executes, a large number of flow variables are populated in the proxy's execution context. These variables give you properties related to the access token, developer app, developer, and company. You can use an AssignMessage or JavaScript policy, for example, to read any of these variables and use them as needed later in the flow. These variables can also be useful for debugging purposes.

Token-specific variables

App-specific variables

These variables are related to the Developer App that is associated with the token.

Developer-specific variables

If the app.appType is "Company", then company attributes are populated and if app.appType is "Developer", then developer attributes are populated.

Company-specific variables

If the app.appType is "Company", then company attributes are populated and if app.appType is "Developer", then developer attributes are populated.

GenerateAuthorizationCode operation

These variables are set when the GenerateAuthorizationCode operation executes successfully:

Prefix: oauthv2authcode.{policy_name}.{variable_name}

Example: oauthv2authcode.GenerateCodePolicy.code

GenerateAccessToken and RefreshAccessToken operations

These variables are set when the GenerateAccessToken and RefreshAccessToken operations execute successfully. Note that refresh token variables do not apply for the client credentials grant type flow.

Prefix: oauthv2accesstoken.{policy_name}.{variable_name}

Example: oauthv2accesstoken.GenerateTokenPolicy.access_token

GenerateAccessTokenImplicitGrant

These variables are set when the GenerateAccessTokenImplicit operation executes successfully for the implicit grant type flow.

Prefix: oauthv2accesstoken.{policy_name}.{variable_name}

Example: oauthv2accesstoken.RefreshTokenPolicy.access_token

ত্রুটির রেফারেন্স

এই বিভাগটি ফল্ট কোড এবং ত্রুটি বার্তাগুলি বর্ণনা করে যেগুলি ফেরত দেওয়া হয় এবং ত্রুটি ভেরিয়েবলগুলি যেগুলি এজ দ্বারা সেট করা হয় যখন এই নীতিটি একটি ত্রুটি ট্রিগার করে৷ এই তথ্যটি জানা গুরুত্বপূর্ণ যে আপনি ত্রুটিগুলি পরিচালনা করার জন্য ত্রুটির নিয়ম তৈরি করছেন কিনা। আরও জানতে, নীতিগত ত্রুটি এবং হ্যান্ডলিং ফল্ট সম্পর্কে আপনার যা জানা দরকার তা দেখুন৷

রানটাইম ত্রুটি

নীতি কার্যকর করার সময় এই ত্রুটিগুলি ঘটতে পারে৷

স্থাপনার ত্রুটি

আপনি যখন এই নীতি সম্বলিত একটি প্রক্সি স্থাপন করেন তখন এই ত্রুটিগুলি ঘটতে পারে৷

ফল্ট ভেরিয়েবল

যখন এই নীতি রানটাইমে একটি ত্রুটি ট্রিগার করে তখন এই ভেরিয়েবলগুলি সেট করা হয়৷

উদাহরণ ত্রুটি প্রতিক্রিয়া

<GenerateResponse> উপাদানটি সত্য হলে এই প্রতিক্রিয়াগুলি ক্লায়েন্টের কাছে ফেরত পাঠানো হয়।

যদি <GenerateResponse> সত্য হয়, নীতিটি টোকেন এবং কোড তৈরি করে এমন ক্রিয়াকলাপগুলির জন্য এই বিন্যাসে ত্রুটি প্রদান করে। একটি সম্পূর্ণ তালিকার জন্য, OAuth HTTP ত্রুটি প্রতিক্রিয়া রেফারেন্স দেখুন।

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

যদি <GenerateResponse> সত্য হয়, নীতিটি এই বিন্যাসে ত্রুটিগুলি প্রদান করে অপারেশনগুলি যাচাই ও যাচাই করার জন্য৷ একটি সম্পূর্ণ তালিকার জন্য, OAuth HTTP ত্রুটি প্রতিক্রিয়া রেফারেন্স দেখুন।

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

Policy schema

Each policy type is defined by an XML schema ( .xsd ). For reference, policy schemas are available on GitHub.

Working with the default OAuth configuration

Each organization (even a free trial org) on Apigee Edge is provisioned with an OAuth token endpoint. The endpoint is preconfigured with policies in the API proxy called oauth . You can begin using the token endpoint as soon as you create an account on Apigee Edge . For details, see Understanding OAuth endpoints .

Purging access tokens

By default, OAuth2 tokens are purged from the Apigee Edge system 3 days (259200 seconds) after both the access token and refresh token (if it exists) have expired. In some cases, you may want to change this default. For example, you may want to shorten the purge time to save disk space if a large number of tokens are being generated.

If you are on Edge for Private Cloud , you can change this default by setting organization properties as explained in this section. (The 3-day purge of expired tokens applies to Edge for Private Cloud version 4.19.01 and later. For earlier versions, the default purge interval is 180 days.)

Updating purge settings for Edge Private Cloud 4.16.01 and later versions

Note: Only tokens generated after these settings are applied are affected; the settings do not apply to tokens that were generated earlier.

Updating purge settings for Edge Private Cloud 4.15.07

Note: Only tokens generated after these settings are applied are affected; the settings do not apply to tokens that were generated earlier.

Non-RFC-compliant behavior

The OAuthV2 policy returns a token response that contains certain non- RFC-compliant properties. The following table shows the non-compliant properties returned by the OAuthV2 policy and the corresponding compliant properties.

Also, the error response for an expired refresh token when grant_type = refresh_token is:

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

However, the RFC-compliant response is:

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

সম্পর্কিত বিষয়

• Introduction to OAuth 2.0