আপনার পছন্দের ভাষায় কন্টেন্ট অনুবাদ করতে Google তার AI প্রযুক্তি ব্যবহার করে। AI-এর মাধ্যমে করা অনুবাদে ভুল থাকতে পারে।

OAuthV2 নীতি

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য

কী

OAuthV2 হল OAuth 2.0 গ্র্যান্টের ধরন সংক্রান্ত অপারেশন পারফর্ম করার জন্য একটি বহু-মুখী নীতি। Apigee Edge-এ OAuth 2.0 এন্ডপয়েন্ট কনফিগার করার জন্য এটি হল প্রাথমিক নীতি।

মনে রাখবেন: OAuthV2 নীতি নির্দিষ্ট কিছু নন-RFC-কম্প্লায়েন্ট উত্তর এলিমেন্ট রিটার্ন করে। যেমন, নীতিটি একটি টোকেন প্রপার্টি, "token_type":"BearerToken", রিটার্ন করে, যেখানে সম্মতিসূচক টোকেন প্রপার্টি হল "token_type":"Bearer"। এইসব নন-কমপ্লায়েন্ট উত্তর এলিমেন্টের বিবরণ পেতে, RFC-কমপ্লায়েন্ট নয় এমন আচরণ দেখুন।

পরামর্শ: আপনি যদি Apigee Edge-এ OAuth সম্পর্কে আরও জানতে চান, তাহলে OAuth হোম পেজ দেখুন। এটি রিসোর্স, স্যাম্পেল, ভিডিও ও আরও অনেক কিছুর লিঙ্ক প্রদান করে। কোনও কার্যকরী অ্যাপ্লিকেশনে এই নীতি কীভাবে ব্যবহার করা হয় তা ভালোভাবে বুঝতে GitHub-এ উন্নত OAuth স্যাম্পেল দেখুন।

নমুনা

VerifyAccessToken

এই OAuthV2 নীতি কনফিগারেশন (VerifyAccessToken অপারেশন সহ) যাচাই করে যে Apigee Edge-এ জমা দেওয়া অ্যাক্সেস টোকেনটি সঠিক। এই নীতি অপারেশন ট্রিগার করা হলে, Edge অনুরোধে একটি বৈধ অ্যাক্সেস টোকেন খোঁজে। অ্যাক্সেস টোকেন সঠিক হলে, অনুরোধটি প্রসেস করার অনুমতি দেওয়া হয়। এটি ভুল হলে, সমস্ত প্রসেসিং বন্ধ হয়ে যায় এবং উত্তরে একটি সমস্যা দেখানো হয়।

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

মনে রাখবেন: শুধুমাত্র OAuth 2.0 বিয়ারার টোকেন কাজ করে। মেসেজ অথেন্টিকেশন কোড (MAC) টোকেন কাজ করে না।

যেমন:

$ curl -H "Authorization: Bearer ylSkZIjbdWybfsUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

ডিফল্ট হিসেবে, Edge Bearer প্রিফিক্স সহ Authorization হেডারে অ্যাক্সেস টোকেন গ্রহণ করে। আপনি <AccessToken> এলিমেন্ট ব্যবহার করে এই ডিফল্ট পরিবর্তন করতে পারবেন।

GenerateAccessToken

অ্যাক্সেস টোকেন তৈরি করা

কাজ করে এমন প্রতিটি গ্র্যান্টের ধরনের জন্য কীভাবে অ্যাক্সেস টোকেন অনুরোধ করতে হয় তা দেখানো উদাহরণের জন্য, অ্যাক্সেস টোকেন ও অনুমোদন কোড অনুরোধ করা দেখুন। এইসব অপারেশনের উদাহরণ টপিকে অন্তর্ভুক্ত করা হয়েছে:

GenerateAuthorizationCode

অনুমোদন কোড জেনারেট করা

অনুমোদন কোডের অনুরোধ কীভাবে করতে হয় তার উদাহরণ দেখতে, অনুমোদন কোডের অনুরোধ করা দেখুন।

RefreshAccessToken

অ্যাক্সেস টোকেন রিফ্রেশ করা

রিফ্রেশ টোকেন ব্যবহার করে কীভাবে অ্যাক্সেস টোকেনের অনুরোধ করতে হয় তার উদাহরণ দেখতে, অ্যাক্সেস টোকেন রিফ্রেশ করা দেখুন।

উত্তর ফ্লো টোকেন

রেসপন্স ফ্লোতে অ্যাক্সেস টোকেন তৈরি করা

কখনও কখনও, আপনাকে রেসপন্স ফ্লোতে অ্যাক্সেস টোকেন তৈরি করতে হতে পারে। যেমন, আপনি ব্যাকএন্ড পরিষেবায় করা কিছু কাস্টম যাচাইকরণের উত্তরে এটি করতে পারেন। এই উদাহরণে, ব্যবহারের ক্ষেত্রে অ্যাক্সেস টোকেন ও রিফ্রেশ টোকেন, দুটিই প্রয়োজন। এর ফলে ইমপ্লিসিট গ্র্যান্ট টাইপ বাতিল হয়ে যায়। এই ক্ষেত্রে, টোকেন তৈরি করার জন্য আমরা পাসওয়ার্ড গ্র্যান্টের ধরন ব্যবহার করব। আপনি দেখতে পাবেন যে, এটি কাজ করানোর কৌশল হল JavaScript নীতি সহ একটি অনুমোদনের অনুরোধ হেডার পাস করা।

প্রথমে, নমুনা নীতিটি দেখে নেওয়া যাক:

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

আপনি যদি এই নীতিটি রেসপন্স ফ্লোতে রাখেন, তাহলে এটি 401 অননুমোদিত সমস্যা সহ ব্যর্থ হবে এমনকি নীতিতে সঠিক লগ-ইন প্যারামিটার নির্দিষ্ট করা থাকলেও। এই সমস্যার সমাধান করতে, আপনাকে একটি অনুমোদন সংক্রান্ত অনুরোধ হেডার সেট করতে হবে।

Authorization হেডারটিতে Base64-এনকোড করা client_id:client_secret সহ একটি প্রাথমিক অ্যাক্সেস স্কিম থাকতে হবে।

আপনি OAuthV2 নীতির ঠিক আগে JavaScript নীতি যোগ করে এই হেডার যোগ করতে পারেন, যেমন এখানে দেখানো হয়েছে। "local_clientid" এবং "local_secret" ভেরিয়েবল আগে থেকেই সেট করা থাকতে হবে এবং ফ্লোতে উপলভ্য থাকতে হবে:

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 নীতির এলিমেন্ট ও অ্যাট্রিবিউট বর্ণনা করা আছে।

মনে রাখবেন: আপনি যেভাবে এই নীতি কনফিগার করেন এবং আপনাকে যেসব এলিমেন্ট নির্দিষ্ট করতে হবে, তা নির্ভর করে আপনি কোন অপারেশন এই নীতির মাধ্যমে পারফর্ম করতে চান তার উপর। যেমন, আপনি যদি অনুমোদন কোড গ্রান্টের ধরন প্রয়োগ করেন, তাহলে আপনাকে অনুমোদন কোড জেনারেশন, অ্যাক্সেস কোড জেনারেশন, অ্যাক্সেস কোড যাচাইকরণ ও রিফ্রেশ টোকেন জেনারেশন পারফর্ম করার জন্য চারটি আলাদা OAuthV2 নীতি প্রয়োজন হবে। এই নীতিতে ব্যবহার করা যেতে পারে এমন সব এলিমেন্টের তালিকা এই রেফারেন্সে দেওয়া আছে।

আপনি যদি নির্দিষ্ট গ্র্যান্টের ধরন সংক্রান্ত ব্যবহারের উদাহরণ দেখতে চান, তাহলে গ্র্যান্টের ধরন প্রয়োগের তালিকার জন্য OAuth হোম পেজ দেখুন। বিশেষ করে, কোনও কার্যকর অ্যাপ্লিকেশনে কীভাবে এই নীতি ব্যবহার করা হয় তার একটি ভাল ডেমোনস্ট্রেশনের জন্য GitHub-এ উন্নত OAuth নমুনা দেখুন।

নিচে দেখানো নমুনা নীতিটি সম্ভাব্য অনেক কনফিগারেশনের মধ্যে একটি। এই নমুনাতে 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">

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

বৈশিষ্ট্য	বর্ণনা	ডিফল্ট	উপস্থিতি
`name`	নীতির অভ্যন্তরীণ নাম। `name` বৈশিষ্ট্যের মানটিতে অক্ষর, সংখ্যা, স্পেস, হাইফেন, আন্ডারস্কোর এবং পিরিয়ড থাকতে পারে। এই মান 255 অক্ষরের বেশি হতে পারে না। ঐচ্ছিকভাবে, ম্যানেজমেন্ট UI প্রক্সি এডিটরে নীতিটিকে একটি ভিন্ন, প্রাকৃতিক-ভাষা নামের সাথে লেবেল করতে `<DisplayName>` উপাদানটি ব্যবহার করুন।	N/A	প্রয়োজন
`continueOnError`	একটি নীতি ব্যর্থ হলে একটি ত্রুটি ফেরত দিতে `false` সেট করুন৷ এটি বেশিরভাগ নীতির জন্য প্রত্যাশিত আচরণ। একটি নীতি ব্যর্থ হওয়ার পরেও ফ্লো এক্সিকিউশন চালিয়ে যেতে `true` সেট করুন৷	মিথ্যা	ঐচ্ছিক
`enabled`	নীতি প্রয়োগ করতে `true` সেট করুন৷ নীতি বন্ধ করতে `false` সেট করুন। নীতিটি প্রবাহের সাথে সংযুক্ত থাকলেও তা কার্যকর করা হবে না।	সত্য	ঐচ্ছিক
`async`	এই বৈশিষ্ট্যটি অবমূল্যায়ন করা হয়েছে৷	মিথ্যা	অবচয়

<DisplayName> উপাদান

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

<DisplayName>Policy Display Name</DisplayName>

ডিফল্ট

ডিফল্ট	N/A আপনি এই উপাদানটি বাদ দিলে, নীতির `name` বৈশিষ্ট্যের মান ব্যবহার করা হবে।
উপস্থিতি	ঐচ্ছিক
টাইপ	স্ট্রিং

N/A

আপনি এই উপাদানটি বাদ দিলে, নীতির name বৈশিষ্ট্যের মান ব্যবহার করা হবে।

উপস্থিতি ঐচ্ছিক

টাইপ স্ট্রিং

<AccessToken> এলিমেন্ট

<AccessToken>request.header.access_token</AccessToken>

সাধারণত, VerifyAccessToken-এর প্রত্যাশা হল অ্যাক্সেস টোকেনটি Authorization হেডারে পাঠানো হবে। এই এলিমেন্ট ব্যবহার করে আপনি সেই ডিফল্ট পরিবর্তন করতে পারবেন। যেমন, request.queryparam.access_token থেকে বোঝা যায় যে অ্যাক্সেস টোকেনটি access_token নামের কোয়েরি প্যারামিটার হিসেবে উপস্থিত থাকতে হবে।

<AccessToken>request.header.access_token</AccessToken> নির্দিষ্ট করা হয়েছে এমন উদাহরণ:

curl https://myorg-myenv.apigee.net/oauth2/validate -H "access_token:Rft3dqrs56Blirls56a"

<AccessToken>request.queryparam.access_token</AccessToken> নির্দিষ্ট করা আছে এমন উদাহরণ:

curl "https://myorg-myenv.apigee.net/oauth2/validate?access_token:Rft3dqrs56Blirls56a"

ডিফল্ট:	প্রযোজ্য নয়
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
অপারেশনের সাথে ব্যবহার করা হয়:	VerifyAccessToken

<AccessTokenPrefix> এলিমেন্ট

<AccessTokenPrefix>Bearer</AccessTokenPrefix>

সাধারণত, VerifyAccessToken-এর প্রত্যাশা হল যে অ্যাক্সেস টোকেনটি একটি Authorization header-এ Bearer টোকেন হিসেবে পাঠানো হবে। যেমন:

-H "Authorization: Bearer Rft3dqrs56Blirls56a"

বর্তমানে, শুধু Bearer প্রিফিক্স কাজ করে।

ডিফল্ট:	বেয়ারার
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	বেয়ারার
অপারেশনের সাথে ব্যবহার করা হয়:	VerifyAccessToken

<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 অ্যাক্সেস টোকেন রিট্রিভ করা ও প্রত্যাহার করা চালু করুন দেখুন।

ডিফল্ট:	প্রযোজ্য নয়
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	রানটাইমে নীতির অ্যাক্সেসযোগ্য যেকোনও ফ্লো ভেরিয়েবল।
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	authorization_code অন্তর্নিহিত পাসওয়ার্ড client_credentials

<Attributes/Attribute>

<Attributes>
    <Attribute name="attr_name1" ref="flow.variable" display="true|false">value1</Attribute>
    <Attribute name="attr_name2" ref="flow.variable" display="true|false">value2</Attribute>
</Attributes>

অ্যাক্সেস টোকেন বা অথরাইজেশন কোডে কাস্টম অ্যাট্রিবিউট যোগ করতে এই এলিমেন্ট ব্যবহার করুন। যেমন, আপনি হয়ত অ্যাক্সেস টোকেনে ব্যবহারকারীর আইডি বা সেশন শনাক্তকারী এম্বেড করতে চান যা রানটাইমে এক্সট্র্যাক্ট ও চেক করা যেতে পারে।

এই এলিমেন্ট আপনাকে ফ্লো ভেরিয়েবলে বা লিটেরাল স্ট্রিং থেকে একটি ভ্যালু নির্দিষ্ট করতে দেয়। আপনি ভেরিয়েবল ও স্ট্রিং, দু'টিই উল্লেখ করলে, ফ্লো ভেরিয়েবলে উল্লেখ করা ভ্যালু ব্যবহার করা হয়। যদি ভেরিয়েবল সমাধান করা না যায়, তাহলে স্ট্রিংটি ডিফল্ট হিসেবে থাকবে।

এই এলিমেন্ট ব্যবহার করা সম্পর্কে আরও জানতে, টোকেন কাস্টমাইজ করা এবং অনুমোদন কোড দেখুন।

উত্তরে কাস্টম অ্যাট্রিবিউট দেখানো বা লুকানো

মনে রাখবেন, আপনি যদি এই নীতির GenerateResponse এলিমেন্টকে true হিসেবে সেট করেন, তাহলে টোকেনের সম্পূর্ণ JSON উপস্থাপনা রেসপন্সে ফেরত দেওয়া হবে, এর মধ্যে আপনার সেট করা যেকোনও কাস্টম অ্যাট্রিবিউট অন্তর্ভুক্ত থাকবে। কিছু ক্ষেত্রে, আপনি হয়ত উত্তরের মধ্যে কিছু বা সব কাস্টম অ্যাট্রিবিউট লুকাতে চাইবেন যাতে সেগুলি ক্লায়েন্ট অ্যাপে দেখা না যায়।

সাধারণত, কাস্টম অ্যাট্রিবিউট উত্তর হিসেবে দেখানো হয়। আপনি সেগুলি লুকাতে চাইলে, display প্যারামিটারকে false হিসেবে সেট করতে পারেন। যেমন:

<Attributes>
    <Attribute name="employee_id" ref="employee.id" display="false"/>
    <Attribute name="employee_name" ref="employee.name" display="false"/>
</Attributes>

display অ্যাট্রিবিউটের ভ্যালু সেভ করা হয়নি। ধরা যাক, আপনি কাস্টম অ্যাট্রিবিউট সহ একটি অ্যাক্সেস টোকেন জেনারেট করেছেন যা আপনি জেনারেট করা উত্তরে লুকিয়ে রাখতে চান। display=false সেট করলে সেই লক্ষ্য পূরণ হয়। তবে, রিফ্রেশ টোকেন ব্যবহার করে পরে কোনও নতুন অ্যাক্সেস টোকেন তৈরি করা হলে, অ্যাক্সেস টোকেনের আসল কাস্টম অ্যাট্রিবিউট রিফ্রেশ টোকেনের উত্তরে দেখা যাবে। এর কারণ হল, Edge মনে রাখে না যে জেনারেট অ্যাক্সেস টোকেন নীতিতে display অ্যাট্রিবিউটটি মূলত false হিসেবে সেট করা হয়েছিল--কাস্টম অ্যাট্রিবিউটটি অ্যাক্সেস টোকেনের মেটাডেটার অংশ।

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

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

রিফ্রেশ টোকেন নীতিতে কাস্টম অ্যাট্রিবিউট স্পষ্টভাবে রিসেট করুন এবং সেগুলির ডিসপ্লে false হিসেবে সেট করুন। এই ক্ষেত্রে, GetOAuthV2Info নীতি ব্যবহার করে আপনাকে আসল অ্যাক্সেস টোকেন থেকে আসল কাস্টম ভ্যালু রিট্রিভ করতে হতে পারে।
উত্তরে দেখতে চান না এমন কাস্টম অ্যাট্রিবিউট ম্যানুয়ালি এক্সট্র্যাক্ট করতে পোস্টপ্রসেসিং জাভাস্ক্রিপ্ট নীতি ব্যবহার করুন।

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

ডিফল্ট:	`N/A`
উপস্থিতি:	ঐচ্ছিক
সঠিক মান:	`name` -অ্যাট্রিবিউটের নাম `ref` - অ্যাট্রিবিউটের ভ্যালু। ফ্লো ভেরিয়েবল থেকে আসতে পারে। `display` - (ঐচ্ছিক) কাস্টম অ্যাট্রিবিউট উত্তরে দেখানো হবে কিনা তা নির্দিষ্ট করতে দেয়। `true` হলে, উত্তরে কাস্টম অ্যাট্রিবিউট দেখা যাবে (`GenerateResponse` চালু করা থাকলে)। `false` হলে, কাস্টম অ্যাট্রিবিউট উত্তরে অন্তর্ভুক্ত করা হয় না। ডিফল্ট ভ্যালু হল `true`। উত্তরে কাস্টম অ্যাট্রিবিউট দেখানো বা লুকানোদেখুন।
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	authorization_code অন্তর্নিহিত পাসওয়ার্ড client_credentials refresh_token GenerateAuthorizationCode অপারেশনের সাথেও ব্যবহার করা যেতে পারে।

<ClientId> এলিমেন্ট

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

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

ডিফল্ট:	request.formparam.client_id (a x-www-form-urlencoded and specified in the request body)
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	ফ্লো ভেরিয়েবল: `request.formparam.client_id`
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	authorization_code পাসওয়ার্ড অন্তর্নিহিত client_credentials GenerateAuthorizationCode অপারেশনের সাথেও ব্যবহার করা যেতে পারে।

<Code> এলিমেন্ট

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

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

ভেরিয়েবল, request.queryparam.auth_code থেকে বোঝা যায় যে অনুমোদন কোডটি কোয়েরি প্যারামিটার হিসেবে থাকতে হবে, যেমন, ?auth_code=AfGlvs9। HTTP হেডারে অনুমোদন কোড প্রয়োজন হলে, যেমন, এই ভ্যালু request.header.auth_code হিসেবে সেট করুন। এছাড়াও, দেখুন অ্যাক্সেস টোকেন ও অনুমোদন কোডের অনুরোধ করা।

ডিফল্ট:	request.formparam.code (a x-www-form-urlencoded and specified in the request body)
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	রানটাইমে নীতির অ্যাক্সেস থাকা যেকোনও ফ্লো ভেরিয়েবল
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	authorization_code

<ExpiresIn> এলিমেন্ট

<ExpiresIn>10000</ExpiresIn>

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

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

পাবলিক ক্লাউডের জন্য Apigee Edge-এর মাধ্যমে, Edge, এন্টিটি অ্যাক্সেস করার পরে কমপক্ষে ১৮০ সেকেন্ডের জন্য নিম্নলিখিত এন্টিটিগুলিকে ক্যাশেতে রাখে।

OAuth অ্যাক্সেস টোকেন। এর অর্থ হল, বাতিল করা টোকেন এখনও সর্বাধিক তিন মিনিট কাজ করতে পারে, যতক্ষণ না এর ক্যাশে সীমা শেষ হয়ে যায়।
কী ম্যানেজমেন্ট সার্ভিস (KMS) এন্টিটি (অ্যাপ, ডেভেলপার, API প্রোডাক্ট)।
OAuth টোকেন ও KMS এন্টিটিতে কাস্টম অ্যাট্রিবিউট।

নিম্নলিখিত স্তবকে একটি ফ্লো ভেরিয়েবল এবং একটি ডিফল্ট ভ্যালুও নির্দিষ্ট করা হয়েছে। মনে রাখবেন, নির্দিষ্ট ডিফল্ট ভ্যালুর চেয়ে ফ্লো ভেরিয়েবল ভ্যালুকে বেশি প্রাধান্য দেওয়া হয়।

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

Edge-এ টোকেন তৈরি হওয়ার পরে সেটি জোর করে এক্সপায়ার করার কোনও সুবিধা নেই। আপনাকে যদি টোকেনের মেয়াদ শেষ করতে বাধ্য করতে হয় (যেমন, কোনও শর্তের উপর ভিত্তি করে), তাহলে একটি সম্ভাব্য সমাধান হল এই Apigee কমিউনিটি পোস্টে বর্ণিত।

সাধারণত, মেয়াদ শেষ হয়ে যাওয়া অ্যাক্সেস টোকেন, মেয়াদ শেষ হওয়ার ৩ দিন পরে Apigee Edge সিস্টেম থেকে অটোমেটিক মুছে দেওয়া হয়। এছাড়াও, অ্যাক্সেস টোকেন সরিয়ে দেওয়া দেখুন

প্রাইভেট ক্লাউড: প্রাইভেট ক্লাউডের জন্য Edge ইনস্টলেশনের ক্ষেত্রে, ডিফল্ট মান conf_keymanagement_oauth_auth_code_expiry_time_in_millis প্রপার্টির মাধ্যমে সেট করা হয়। এই প্রপার্টি সেট করতে:

এডিটরে message-processor.properties ফাইল খুলুন। ফাইলটি না থাকলে, এটি তৈরি করুন:
```
vi /opt/apigee/customer/application/message-processor.properties
```
ইচ্ছা অনুযায়ী প্রপার্টি সেট করুন:
```
conf_keymanagement_oauth_auth_code_expiry_time_in_millis=3600000
```
প্রপার্টি ফাইলের মালিক "apigee" ব্যবহারকারী কিনা তা নিশ্চিত করুন:
```
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
```
মেসেজ প্রসেসর রিস্টার্ট করুন।
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

ডিফল্ট:	উল্লেখ করা না থাকলে, সিস্টেম লেভেলে কনফিগার করা একটি ডিফল্ট ভ্যালু সিস্টেম প্রয়োগ করে।
উপস্থিতি:	ঐচ্ছিক
টাইপ:	পূর্ণসংখ্যা
সঠিক মান:	যেকোনও পজিটিভ, অশূন্য পূর্ণসংখ্যা। মিলিসেকেন্ডে মেয়াদ শেষ হওয়ার সময় উল্লেখ করুন। যদিও এই এলিমেন্টের ভ্যালু মিলি সেকেন্ডে থাকে, তবে টোকেনের `expires_in` প্রপার্টি ও `expires_in` ফ্লো ভেরিয়েবলে সেট করা ভ্যালু সেকেন্ডে প্রকাশ করা হয়। -1-এর মেয়াদ OAuth অ্যাক্সেস টোকেনের সর্বাধিক মেয়াদ শেষ হওয়ার ভিত্তিতে শেষ হয়ে যাবে। মনে রাখবেন: অন্য কোনও নেগেটিভ পূর্ণসংখ্যা বা শূন্য উল্লেখ করলে ডেপ্লয়মেন্ট সংক্রান্ত সমস্যা হয়। এছাড়াও, অ্যান্টিপ্যাটার্ন: OAuth টোকেনের জন্য দীর্ঘ মেয়াদ শেষ হওয়ার সময় সেট করা দেখুন।
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	authorization_code অন্তর্নিহিত পাসওয়ার্ড client_credentials refresh_token এছাড়াও, GenerateAuthorizationCode অপারেশনের সাথে ব্যবহার করা হয়।

মনে রাখবেন: মনে রাখবেন, ExpiresIn -1 হিসেবে সেট করা থাকলে, আপনি জেনারেট করা টোকেনে নিম্নলিখিত মেয়াদ শেষ হওয়ার ভ্যালু দেখতে পাবেন:

"expires_in" :
  "0"

<ExternalAccessToken> এলিমেন্ট

<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> এলিমেন্ট

<ExternalAuthorization>true</ExternalAuthorization>

এই এলিমেন্টটি মিথ্যা হলে বা না থাকলে, Edge, Apigee Edge যাচাইকরণ স্টোরের বিরুদ্ধে client_id এবং client_secret সাধারণভাবে যাচাই করে। আপনি থার্ড-পার্টি OAuth টোকেন নিয়ে কাজ করতে চাইলে এই এলিমেন্ট ব্যবহার করুন। এই এলিমেন্ট ব্যবহার করার ব্যাপারে আরও জানতে, থার্ড-পার্টি OAuth টোকেন ব্যবহার করা দেখুন।

ডিফল্ট:	মিথ্যা
উপস্থিতি:	ঐচ্ছিক
টাইপ:	বুলিয়ান
সঠিক মান:	ঠিক বা ভুল
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	authorization_code পাসওয়ার্ড client_credentials

<ExternalAuthorizationCode> এলিমেন্ট

<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-এর মেয়াদ সেকেন্ডে দেখানো হয়।

ডিফল্ট:	মিথ্যা
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	ঠিক বা ভুল
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	অন্তর্নিহিত পাসওয়ার্ড client_credentials refresh_token এছাড়াও, GenerateAuthorizationCode অপারেশনের সাথে ব্যবহার করা যেতে পারে।

<GenerateErrorResponse> এলিমেন্ট

<GenerateErrorResponse enabled='true'/>

true হিসেবে সেট করা থাকলে, ContinueOnError অ্যাট্রিবিউট true হিসেবে সেট করা থাকলে, নীতিটি একটি উত্তর তৈরি করে ফেরত দেয়। false (ডিফল্ট) হলে, কোনও উত্তর পাঠানো হয় না। পরিবর্তে, ফ্লো ভেরিয়েবলের একটি সেট, নীতির ফাংশন সম্পর্কিত মান দিয়ে পূরণ করা হয়।

ডিফল্ট:	মিথ্যা
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	ঠিক বা ভুল
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	অন্তর্নিহিত পাসওয়ার্ড client_credentials refresh_token এছাড়াও, GenerateAuthorizationCode অপারেশনের সাথে ব্যবহার করা যেতে পারে।

<GrantType>

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

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

যেমন, request.queryparam.grant_type থেকে বোঝা যায় যে পাসওয়ার্ড কোয়েরি প্যারামিটার হিসেবে থাকতে হবে, যেমন, ?grant_type=password। HTTP হেডারে গ্র্যান্টের ধরন প্রয়োজন হলে, যেমন, এই ভ্যালু request.header.grant_type হিসেবে সেট করুন। এছাড়াও, অ্যাক্সেস টোকেন ও অনুমোদন কোডের জন্য অনুরোধ করা দেখুন।

ডিফল্ট:	request.formparam.grant_type (a x-www-form-urlencoded and specified in the request body)
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	উপরে ব্যাখ্যা করা হয়েছে এমন একটি ভেরিয়েবল।
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	authorization_code পাসওয়ার্ড অন্তর্নিহিত client_credentials refresh_token

<Operation> এলিমেন্ট

<Operation>GenerateAuthorizationCode</Operation>

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

ডিফল্ট:	`<Operation>` নির্দিষ্ট করা না থাকলে, Edge `<SupportedGrantTypes>`-এর তালিকা দেখে। শুধুমাত্র সেইসব গ্র্যান্টের ক্ষেত্রেই অপারেশন সফল হবে। অন্যভাবে বলতে গেলে, আপনি `<SupportedGrantTypes>` তালিকায় কোনও `<GrantType>` উল্লেখ করলে, `<Operation>` বাদ দিতে পারেন। যদি `<Operation>` বা `<SupportedGrantTypes>` কোনওটিই নির্দিষ্ট করা না থাকে, তাহলে ডিফল্ট গ্র্যান্টের ধরন হল authorization_code. অর্থাৎ, authorization_code grant type অনুরোধ সফল হবে, কিন্তু অন্য সব অনুরোধ ব্যর্থ হবে।
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	`GenerateAccessToken` - অ্যাক্সেস টোকেন তৈরি করে। এছাড়াও, অ্যাক্সেস টোকেন ও অনুমোদন কোড সংক্রান্ত অনুরোধ দেখুন। `GenerateAccessTokenImplicitGrant` - ইমপ্লিসিট গ্রান্ট টাইপের জন্য অ্যাক্সেস টোকেন তৈরি করে। এছাড়াও, অ্যাক্সেস টোকেন ও অনুমোদন কোড সংক্রান্ত অনুরোধ দেখুন। `GenerateAuthorizationCode` - একটি অথরাইজেশন কোড তৈরি করে। অনুমোদন কোড গ্রান্টের ধরনের সাথে ব্যবহার করা হয়। এছাড়াও, অ্যাক্সেস টোকেন ও অনুমোদন কোড সংক্রান্ত অনুরোধ দেখুন। `RefreshAccessToken` - নতুন অ্যাক্সেস টোকেনের জন্য রিফ্রেশ টোকেন এক্সচেঞ্জ করুন। এছাড়াও, টোকেন ও অনুমোদন কোড অ্যাক্সেস করার অনুরোধ করা দেখুন। `VerifyAccessToken` - অনুরোধে পাঠানো অ্যাক্সেস টোকেনটি বৈধ কিনা তা যাচাই করে। উপরের VerifyAccessToken স্যাম্পেল এবং "অ্যাক্সেস টোকেন যাচাই করা হচ্ছে" দেখুন। `InvalidateToken` - অ্যাক্সেস টোকেন প্রত্যাহার করে নেয়। টোকেন প্রত্যাহার করার পরে, ক্লায়েন্ট সুরক্ষিত API কল করার জন্য সেই টোকেন ব্যবহার করতে পারবে না। এছাড়াও, অ্যাক্সেস টোকেন অনুমোদন ও প্রত্যাহার করা দেখুন। `ValidateToken` - আগে প্রত্যাহার করা অ্যাক্সেস টোকেনকে পুনরায় চালু বা "অনুমোদন" করে। এছাড়াও, অ্যাক্সেস টোকেন অনুমোদন ও প্রত্যাহার করা দেখুন।

<PassWord> এলিমেন্ট

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

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

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

OAuthV2 নীতি এইসব ক্রেডেনশিয়াল ভ্যালু নিয়ে আর কিছু করে না; Edge শুধু যাচাই করে দেখে যে সেগুলি আছে কিনা। টোকেন জেনারেশন নীতি কার্যকর করার আগে, API ডেভেলপারকে অনুরোধ করা ভ্যালুগুলি পুনরুদ্ধার করতে হবে এবং সেগুলি কোনও পরিচয় প্রদানকারীর কাছে পাঠাতে হবে।

এছাড়াও, অ্যাক্সেস টোকেন ও অনুমোদন কোডের অনুরোধ করা দেখুন।

ডিফল্ট:	request.formparam.password (a x-www-form-urlencoded and specified in the request body)
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	রানটাইমে নীতির জন্য উপলভ্য যেকোনও ফ্লো ভেরিয়েবল।
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	পাসওয়ার্ড

<RedirectUri> এলিমেন্ট

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

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

রিডাইরেকশন URI সম্পর্কে

রিডাইরেকশন URI, অনুমোদনের কোড ও ইমপ্লিসিট গ্রান্টের ধরনের সাথে ব্যবহার করা হয়। রিডাইরেক্ট URI অনুমোদন সার্ভারকে (Edge) বলে দেয় যে অনুমোদন কোড (অথ কোড গ্রান্টের ধরন) বা অ্যাক্সেস টোকেন (ইমপ্লিসিট গ্রান্টের ধরন) কোথায় পাঠাতে হবে। এই প্যারামিটার কখন প্রয়োজন, কখন ঐচ্ছিক এবং কীভাবে এটি ব্যবহার করা হয় তা বোঝা গুরুত্বপূর্ণ:

(প্রয়োজনীয়) অনুরোধের ক্লায়েন্ট কী-এর সাথে যুক্ত ডেভেলপারের অ্যাপে কোনও কলব্যাক URL রেজিস্টার করা থাকলে এবং অনুরোধে redirect_uri থাকলে, দু'টিকেই হুবহু মিলতে হবে। সেগুলি না মিললে, একটি সমস্যা দেখানো হয়। Edge-এ ডেভেলপার অ্যাপ রেজিস্টার করা এবং কলব্যাক URL নির্দিষ্ট করা সম্পর্কিত তথ্যের জন্য, অ্যাপ রেজিস্টার করা এবং API কী ম্যানেজ করা দেখুন।
মনে রাখবেন: Edge যাতে "Callback URL" এবং "redirect_uri"-এর মধ্যে সম্পূর্ণ মিল চেক করে (আংশিক মিল নয়) তা নিশ্চিত করতে, আপনার সংস্থায় নিম্নলিখিত প্রপার্টি সেট করুন: features.isStrictOAuthUriValidation = true. ডিফল্ট হল false (ফরোয়ার্ড ম্যাচ)।
আপনি ক্লাউড গ্রাহক হলে, প্রপার্টি চালু করতে Apigee Edge সহায়তা টিমের সাথে যোগাযোগ করুন । আপনি যদি Private Cloud-এর জন্য Apigee Edge গ্রাহক হন, তাহলে সিস্টেম অ্যাডমিনিস্ট্রেটরের ক্রেডেনশিয়াল সহ নিচের API PUT কল ব্যবহার করে ফ্ল্যাগ সেট করুন।
```
curl -u email:password -X PUT -H "Content-type:application/xml" http://host:port/v1/o/{myorg} -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isStrictOAuthUriValidation">true</Property>
        
    </Properties>
</Organization>"
```
সতর্কতা: API কলের মাধ্যমে আপনি কোনও সংস্থা আপডেট করলে, পে-লোডে আগে থেকে থাকা সংস্থার সমস্ত প্রপার্টি অন্তর্ভুক্ত করতে ভুলবেন না। আপনি তা না করলে, এই কলের মাধ্যমে আপনার সেট করা প্রপার্টি দিয়েই আগে থেকে থাকা সবকটি সংস্থার প্রপার্টি ওভাররাইট করা হবে।
(ঐচ্ছিক) কোনও কলব্যাক URL রেজিস্টার করা থাকলে এবং অনুরোধে redirect_uri না থাকলে Edge রেজিস্টার করা কলব্যাক URL-এ রিডাইরেক্ট করে।
(প্রয়োজনীয়) কলব্যাক URL রেজিস্টার করা না থাকলে, redirect_uri প্রয়োজন। মনে রাখবেন, এই ক্ষেত্রে Edge যেকোনও URL গ্রহণ করবে। এই ক্ষেত্রে নিরাপত্তা সংক্রান্ত সমস্যা হতে পারে, তাই শুধুমাত্র বিশ্বস্ত ক্লায়েন্ট অ্যাপের সাথেই এটি ব্যবহার করা উচিত। ক্লায়েন্ট অ্যাপ বিশ্বস্ত না হলে, পেশাদার পদ্ধতি হল সবসময় কলব্যাক URL-এর রেজিস্ট্রেশন প্রয়োজন।

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

ডিফল্ট:	request.formparam.redirect_uri (a x-www-form-urlencoded and specified in the request body)
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	রানটাইমে নীতিতে অ্যাক্সেস করা যায় এমন যেকোনও ফ্লো ভেরিয়েবল
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	authorization_code অন্তর্নিহিত এছাড়াও, GenerateAuthorizationCode অপারেশনের সাথে ব্যবহার করা হয়।

<RefreshToken> এলিমেন্ট

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

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

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

ডিফল্ট:	request.formparam.refresh_token (a x-www-form-urlencoded and specified in the request body)
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	রানটাইমে নীতিতে অ্যাক্সেস করা যায় এমন যেকোনও ফ্লো ভেরিয়েবল
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	refresh_token

<RefreshTokenExpiresIn> এলিমেন্ট

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

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

নিম্নলিখিত স্তবকে একটি ফ্লো ভেরিয়েবল এবং একটি ডিফল্ট ভ্যালুও নির্দিষ্ট করা হয়েছে। মনে রাখবেন, ফ্লো ভেরিয়েবলের মান নির্দিষ্ট ডিফল্ট মানের চেয়ে বেশি গুরুত্বপূর্ণ।

<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 প্রপার্টির মাধ্যমে সেট করা হয়। এই প্রপার্টি সেট করতে:

এডিটরে message-processor.properties ফাইল খুলুন। ফাইলটি না থাকলে, এটি তৈরি করুন:
```
vi /opt/apigee/customer/application/message-processor.properties
```
ইচ্ছা অনুযায়ী প্রপার্টি সেট করুন:
```
conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
```
প্রপার্টি ফাইলের মালিক "apigee" ব্যবহারকারী কিনা তা নিশ্চিত করুন:
```
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
```
মেসেজ প্রসেসর রিস্টার্ট করুন।
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

ডিফল্ট:	63072000000 ms (২ বছর) (৫ আগস্ট, ২০২৪ থেকে কার্যকর)
উপস্থিতি:	ঐচ্ছিক
টাইপ:	পূর্ণসংখ্যা
সঠিক মান:	যেকোনও পজিটিভ, অশূন্য পূর্ণসংখ্যা। মিলিসেকেন্ডে মেয়াদ শেষ হওয়ার সময় নির্দিষ্ট করে। -1-এর মেয়াদ OAuth রিফ্রেশ টোকেনের সর্বাধিক মেয়াদ শেষ হওয়ার ভিত্তিতে শেষ হয়ে যাবে। মনে রাখবেন: অন্য কোনও নেগেটিভ পূর্ণসংখ্যা বা শূন্য উল্লেখ করলে ডেপ্লয়মেন্ট সংক্রান্ত সমস্যা হয়। এছাড়াও, অ্যান্টিপ্যাটার্ন: OAuth টোকেনের জন্য দীর্ঘ মেয়াদ শেষ হওয়ার সময় সেট করা দেখুন।
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	authorization_code পাসওয়ার্ড refresh_token

<ResponseType> এলিমেন্ট

<ResponseType>request.queryparam.response_type</ResponseType>

এই এলিমেন্ট Edge-কে জানায় যে ক্লায়েন্ট অ্যাপ কোন ধরনের গ্র্যান্টের অনুরোধ করছে। এটি শুধুমাত্র অনুমোদন কোড এবং ইমপ্লিসিট গ্রান্ট টাইপ ফ্লোর সাথে ব্যবহার করা হয়।

ডিফল্ট হিসেবে, Edge response_type কোয়েরি প্যারামিটারে রেসপন্স টাইপ ভ্যালু খোঁজে। আপনি যদি এই ডিফল্ট আচরণ ওভাররাইড করতে চান, তাহলে প্রতিক্রিয়া ধরনের মান সহ একটি ফ্লো ভেরিয়েবল কনফিগার করতে <ResponseType> এলিমেন্ট ব্যবহার করুন। যেমন, আপনি এই এলিমেন্টকে request.header.response_type হিসেবে সেট করলে, Edge অনুরোধ হেডারে পাস করা উত্তরের ধরন খোঁজে। এছাড়াও, অ্যাক্সেস টোকেন ও অনুমোদন কোডের জন্য অনুরোধ করা দেখুন।

ডিফল্ট:	request.formparam.response_type (a x-www-form-urlencoded and specified in the request body)
উপস্থিতি:	ঐচ্ছিক। ডিফল্ট আচরণ ওভাররাইড করতে চাইলে এই এলিমেন্ট ব্যবহার করুন।
টাইপ:	স্ট্রিং
সঠিক মান:	`code` (অনুমোদন কোড গ্রান্টের ধরনের জন্য) অথবা `token` (ইমপ্লিসিট গ্রান্টের ধরনের জন্য)
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	অন্তর্নিহিত এছাড়াও, GenerateAuthorizationCode অপারেশনের সাথে ব্যবহার করা হয়।

<ReuseRefreshToken> এলিমেন্ট

<ReuseRefreshToken>true</ReuseRefreshToken>

true হিসেবে সেট করা থাকলে, মেয়াদ শেষ না হওয়া পর্যন্ত আগে থেকে থাকা রিফ্রেশ টোকেন আবার ব্যবহার করা হয়। যদি false, তাহলে একটি সঠিক রিফ্রেশ টোকেন উপস্থাপন করা হলে, Apigee Edge একটি নতুন রিফ্রেশ টোকেন ইস্যু করে।

ডিফল্ট:	`false`
উপস্থিতি:	ঐচ্ছিক
টাইপ:	বুলিয়ান
সঠিক মান:	`true` বা `false`
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	refresh_token

<Scope> এলিমেন্ট

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

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

এই এলিমেন্টটি "VerifyAccessToken" নীতিতে থাকলে, কোন কোন স্কোপে নীতি প্রয়োগ করা উচিত তা নির্দিষ্ট করতে এটি ব্যবহার করা হয়। এই ধরনের নীতিতে, ভ্যালু অবশ্যই "হার্ড কোডেড" স্কোপ নাম হতে হবে -- আপনি ভেরিয়েবল ব্যবহার করতে পারবেন না। যেমন:

<Scope>A B</Scope>

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

ডিফল্ট:	কোনও স্কোপ নেই
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	Generate* নীতির সাথে ব্যবহার করা হলে, ফ্লো ভেরিয়েবল। VerifyAccessToken-এর সাথে ব্যবহার করা হলে, স্কোপের নামের স্পেস-সেপারেটেড তালিকা (স্ট্রিং)।
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	authorization_code অন্তর্নিহিত পাসওয়ার্ড client_credentials এছাড়াও, GenerateAuthorizationCode এবং VerifyAccessToken অপারেশনের সাথে ব্যবহার করা যেতে পারে।

<State> এলিমেন্ট

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

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

যেমন, request.queryparam.state থেকে বোঝা যায় যে কোয়েরি প্যারামিটার হিসেবে স্ট্যাটাস উপস্থিত থাকতে হবে, যেমন, ?state=HjoiuKJH32। HTTP হেডারে স্টেট প্রয়োজন হলে, এই ভ্যালু request.header.state হিসেবে সেট করুন। এছাড়াও, অ্যাক্সেস টোকেন ও অনুমোদন কোডের অনুরোধ করা দেখুন।

ডিফল্ট:	কোনও রাজ্য নেই
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	রানটাইমে নীতির অ্যাক্সেস থাকা যেকোনও ফ্লো ভেরিয়েবল
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	সব GenerateAuthorizationCode অপারেশনের সাথেও ব্যবহার করা যেতে পারে

<StoreToken> এলিমেন্ট

 <StoreToken>true</StoreToken>

<ExternalAuthorization> এলিমেন্ট true হলে এই এলিমেন্টকে true হিসেবে সেট করুন। <StoreToken> এলিমেন্ট Apigee Edge-কে এক্সটার্নাল অ্যাক্সেস টোকেন স্টোর করতে বলে। অন্যথায়, এটি সেভ করা হবে না।

ডিফল্ট:	মিথ্যা
উপস্থিতি:	ঐচ্ছিক
টাইপ:	বুলিয়ান
সঠিক মান:	ঠিক বা ভুল
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	authorization_code পাসওয়ার্ড client_credentials

<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 প্যারামিটারের ভ্যালু কাজ করে এমন গ্র্যান্টের ধরনের সাথে মিলছে)।

ডিফল্ট:	অনুমোদন _কোড ও ইমপ্লিসিট
উপস্থিতি:	প্রয়োজনীয়
টাইপ:	স্ট্রিং
সঠিক মান:	client_credentials authorization_code পাসওয়ার্ড অন্তর্নিহিত

<Tokens>/<Token> এলিমেন্ট

ValidateToken ও InvalidateToken অপারেশনের সাথে ব্যবহার করা হয়। এছাড়াও, অ্যাক্সেস টোকেন অনুমোদন করা ও প্রত্যাহার করা দেখুন। <Token> এলিমেন্ট সেই ফ্লো ভেরিয়েবলকে শনাক্ত করে যা বাতিল করা টোকেনের সোর্সকে সংজ্ঞায়িত করে। ডেভেলপারদের যদি অ্যাক্সেস টোকেন জমা দিতে হয়, তাহলে access_token নামের কোয়েরি প্যারামিটার ব্যবহার করুন, যেমন, request.queryparam.access_token ব্যবহার করুন।

<UserName> এলিমেন্ট

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

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

এছাড়াও, অ্যাক্সেস টোকেন ও অনুমোদন কোডের অনুরোধ করা দেখুন।

ডিফল্ট:	request.formparam.username (a x-www-form-urlencoded and specified in the request body)
উপস্থিতি:	ঐচ্ছিক
টাইপ:	স্ট্রিং
সঠিক মান:	যেকোনও ভেরিয়েবল সেটিং।
গ্র্যান্টের ধরনের সাথে ব্যবহার করা হয়:	পাসওয়ার্ড

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

API প্রক্সির জন্য টোকেন এন্ডপয়েন্ট সেট-আপ করা হয়ে গেলে, একটি সংশ্লিষ্ট OAuthV2 নীতি যা VerifyAccessToken অপারেশন নির্দিষ্ট করে, সেটি সেই ফ্লোর সাথে অ্যাটাচ করা হয় যা সুরক্ষিত রিসোর্স এক্সপোজ করে।

যেমন, কোনও API-তে পাঠানো সব অনুরোধ যাতে অনুমোদিত হয় তা নিশ্চিত করতে, নিম্নলিখিত নীতি অ্যাক্সেস টোকেন যাচাইকরণ প্রয়োগ করে:

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

সুরক্ষিত করতে হবে এমন API রিসোর্সের সাথে নীতিটি অ্যাটাচ করা হয়। API-তে করা সব অনুরোধ যাচাই করা হয়েছে কিনা তা নিশ্চিত করতে, ProxyEndpoint অনুরোধের PreFlow-তে নিম্নলিখিতভাবে নীতি অ্যাটাচ করুন:

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

VerifyAccessToken অপারেশনের জন্য ডিফল্ট সেটিংস ওভাররাইড করতে নিম্নলিখিত ঐচ্ছিক এলিমেন্ট ব্যবহার করা যেতে পারে।

নাম বিবরণ

সুযোগ

নাম	বিবরণ
সুযোগ	স্পেস দিয়ে আলাদা করা স্কোপের তালিকা। অ্যাক্সেস টোকেনে তালিকাভুক্ত স্কোপের মধ্যে অন্তত একটি স্কোপ থাকলে যাচাইকরণ সফল হবে। যেমন, নিম্নলিখিত নীতি অ্যাক্সেস টোকেন চেক করে দেখবে যে এতে তালিকাভুক্ত স্কোপের মধ্যে অন্তত একটি আছে কিনা। যদি পড়ুন বা লিখুন থাকে, তাহলে যাচাইকরণ সফল হবে। <OAuthV2 name="ValidateOauthScopePolicy"> <Operation>VerifyAccessToken</Operation> <Scope>READ WRITE</Scope> </OAuthV2>
AccessToken	যে ভেরিয়েবলে অ্যাক্সেস টোকেন থাকার কথা। যেমন `request.queryparam.accesstoken`. সাধারণত, OAuth 2.0 স্পেসিফিকেশন অনুযায়ী, অ্যাপটি অনুমোদনের HTTP হেডারে অ্যাক্সেস টোকেন দেখাবে বলে আশা করা হয়। অ্যাক্সেস টোকেন যদি কোনও নন-স্ট্যান্ডার্ড লোকেশনে, যেমন কোয়েরি প্যারামিটার বা Authorization ছাড়া অন্য কোনও নামের HTTP হেডারে থাকার কথা থাকে, তাহলে এই সেটিং ব্যবহার করুন।

স্পেস দিয়ে আলাদা করা স্কোপের তালিকা। অ্যাক্সেস টোকেনে তালিকাভুক্ত স্কোপের মধ্যে অন্তত একটি স্কোপ থাকলে যাচাইকরণ সফল হবে। যেমন, নিম্নলিখিত নীতি অ্যাক্সেস টোকেন চেক করে দেখবে যে এতে তালিকাভুক্ত স্কোপের মধ্যে অন্তত একটি আছে কিনা। যদি পড়ুন বা লিখুন থাকে, তাহলে যাচাইকরণ সফল হবে।

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

AccessToken যে ভেরিয়েবলে অ্যাক্সেস টোকেন থাকার কথা। যেমন request.queryparam.accesstoken. সাধারণত, OAuth 2.0 স্পেসিফিকেশন অনুযায়ী, অ্যাপটি অনুমোদনের HTTP হেডারে অ্যাক্সেস টোকেন দেখাবে বলে আশা করা হয়। অ্যাক্সেস টোকেন যদি কোনও নন-স্ট্যান্ডার্ড লোকেশনে, যেমন কোয়েরি প্যারামিটার বা Authorization ছাড়া অন্য কোনও নামের HTTP হেডারে থাকার কথা থাকে, তাহলে এই সেটিং ব্যবহার করুন।

এছাড়াও, অ্যাক্সেস টোকেন যাচাই করাএবং অ্যাক্সেস টোকেন ও অনুমোদন কোডের জন্য অনুরোধ করা দেখুন।

অনুরোধ ভেরিয়েবলের লোকেশন নির্দিষ্ট করা

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

নিচের উদাহরণে দেখানো হয়েছে যে কীভাবে প্রয়োজনীয় অনুমোদন কোড প্যারামিটারের লোকেশন HTTP হেডার হিসেবে নির্দিষ্ট করতে হয়:

  ...
  <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 নীতিগুলি এক্সিকিউট করা হলে পপুলেট করা হয় এবং তাই API প্রক্সি ফ্লোতে এক্সিকিউট করা অন্যান্য নীতি বা অ্যাপ্লিকেশনগুলির জন্য উপলভ্য।

VerifyAccessToken অপারেশন

VerifyAccessToken অপারেশন এক্সিকিউট হয়, প্রক্সির এক্সিকিউশন কনটেক্সটে প্রচুর ফ্লো ভেরিয়েবল পপুলেট করা হয়। এইসব ভেরিয়েবল আপনাকে অ্যাক্সেস টোকেন, ডেভেলপার অ্যাপ, ডেভেলপার ও কোম্পানি সম্পর্কিত প্রপার্টি দেয়। আপনি AssignMessage বা JavaScript নীতি ব্যবহার করতে পারেন, যেমন, এর মধ্যে যেকোনও একটি ভেরিয়েবল পড়তে এবং পরে ফ্লোতে প্রয়োজন মতো ব্যবহার করতে। এইসব ভেরিয়েবল ডিবাগিংয়ের উদ্দেশ্যেও কাজে লাগতে পারে।

মনে রাখবেন: API প্রোডাক্ট যদি বৈধ এনভায়রনমেন্ট, প্রক্সি ও API রিসোর্স (proxy.pathsuffix থেকে প্রাপ্ত) দিয়ে কনফিগার করা থাকে, তাহলে API প্রোডাক্ট ভেরিয়েবল অটোমেটিক পূরণ হয়ে যাবে। flow.resource.name ভেরিয়েবল স্পষ্টভাবে সেট করার প্রয়োজন নেই।

যেখানে API প্রোডাক্ট বৈধ এনভায়রনমেন্ট ও API প্রক্সি দিয়ে কনফিগার করা হয় না, সেখানে ফ্লোতে API প্রোডাক্ট ভেরিয়েবল পপুলেট করার জন্য flow.resource.name অবশ্যই স্পষ্টভাবে সেট করতে হবে। প্রোডাক্ট কনফিগারেশন সম্পর্কে আরও জানতে, API প্রকাশ করার জন্য Edge ম্যানেজমেন্ট API ব্যবহার করা দেখুন।

টোকেন-নির্দিষ্ট ভেরিয়েবল

ভেরিয়েবল	বিবরণ
`organization_name`	যে সংস্থার হয়ে প্রক্সি এক্সিকিউট করা হচ্ছে তার নাম।
`developer.id`	রেজিস্টার করা ক্লায়েন্ট অ্যাপের সাথে যুক্ত ডেভেলপারের আইডি।
`developer.app.name`	রেজিস্টার করা ক্লায়েন্ট অ্যাপের সাথে যুক্ত ডেভেলপার।
`client_id`	রেজিস্টার করা ক্লায়েন্ট অ্যাপের ক্লায়েন্ট আইডি।
`grant_type`	অনুরোধের সাথে যুক্ত গ্রান্টের ধরন।
`token_type`	অনুরোধের সাথে যুক্ত টোকেনের ধরন।
`access_token`	যাচাই করা হচ্ছে এমন অ্যাক্সেস টোকেন।
`accesstoken.{custom_attribute}`	অ্যাক্সেস টোকেনে নাম সহ কাস্টম অ্যাট্রিবিউট।
`issued_at`	অ্যাক্সেস টোকেন ইস্যু করার তারিখটি Unix epoch টাইমে মিলিসেকেন্ডে প্রকাশ করা হয়।
`expires_in`	অ্যাক্সেস টোকেনের মেয়াদ শেষ হওয়ার সময়। এটি সেকেন্ডে প্রকাশ করা হয়। যদিও `ExpiresIn` এলিমেন্ট মিলি সেকেন্ডে মেয়াদ শেষ হওয়ার সময় সেট করে, টোকেন রেসপন্স ও ফ্লো ভেরিয়েবলে, ভ্যালু সেকেন্ডে প্রকাশ করা হয়।
`status`	অ্যাক্সেস টোকেনের স্ট্যাটাস (যেমন, অনুমোদিত বা প্রত্যাহার করা হয়েছে)।
`scope`	অ্যাক্সেস টোকেনের সাথে যুক্ত স্কোপ (যদি থাকে)।
`apiproduct.<custom_attribute_name>`	রেজিস্টার করা ক্লায়েন্ট অ্যাপের সাথে যুক্ত API প্রোডাক্টের নামযুক্ত কাস্টম অ্যাট্রিবিউট।
`apiproduct.name`	রেজিস্টার করা ক্লায়েন্ট অ্যাপের সাথে যুক্ত API প্রোডাক্টের নাম।
`revoke_reason`	(শুধুমাত্র Apigee hybrid) অ্যাক্সেস টোকেন কেন প্রত্যাহার করা হয়েছে তা নির্দেশ করে। ভ্যালু `REVOKED_BY_APP`, `REVOKED_BY_ENDUSER`, `REVOKED_BY_APP_ENDUSER`, বা `TOKEN_REVOKED` হতে পারে।

অ্যাপ-নির্দিষ্ট ভেরিয়েবল

এইসব ভেরিয়েবল টোকেনের সাথে যুক্ত ডেভেলপার অ্যাপের সাথে সম্পর্কিত।

ভেরিয়েবল	বিবরণ
`app.name`
`app.id`
`app.accessType`
`app.callbackUrl`
`app.status`	অনুমোদিত বা প্রত্যাহার করা হয়েছে
`app.scopes`
`app.appFamily`
`app.apiproducts`
`app.appParentStatus`
`app.appType`	যেমন: ডেভেলপার
`app.appParentId`
`app.created_by`
`app.created_at`
`app.last_modified_at`
`app.last_modified_by`
`app.{custom_attributes}`	নিবন্ধিত ক্লায়েন্ট অ্যাপের নামযুক্ত কাস্টম অ্যাট্রিবিউট।

ডেভেলপার-নির্দিষ্ট ভেরিয়েবল

যদি app.appType "Company" হয়, তাহলে কোম্পানির অ্যাট্রিবিউট অটো-ফিল করা হয় এবং যদি app.appType "Developer" হয়, তাহলে ডেভেলপার অ্যাট্রিবিউট অটো-ফিল করা হয়।

ভেরিয়েবল	বিবরণ
ডেভেলপার-নির্দিষ্ট ভেরিয়েবল
`developer.id`
`developer.userName`
`developer.firstName`
`developer.lastName`
`developer.email`
`developer.status`	অ্যাক্টিভ বা ইনঅ্যাক্টিভ
`developer.apps`
`developer.created_by`
`developer.created_at`
`developer.last_modified_at`
`developer.last_modified_by`
`developer.{custom_attributes}`	ডেভেলপারের নামযুক্ত কাস্টম অ্যাট্রিবিউট।

কোম্পানি-নির্দিষ্ট ভেরিয়েবল

ভেরিয়েবল	বিবরণ
`company.id`
`company.displayName`
`company.apps`
`company.appOwnerStatus`
`company.created_by`
`company.created_at`
`company.last_modified_at`
`company.last_modified_by`
`company.{custom_attributes}`	কোম্পানির কোনও নামযুক্ত কাস্টম অ্যাট্রিবিউট।

GenerateAuthorizationCode অপারেশন

GenerateAuthorizationCode অপারেশন সফলভাবে এক্সিকিউট হলে এইসব ভেরিয়েবল সেট করা হয়: সফলভাবে এক্সিকিউট হলে এইসব ভেরিয়েবল সেট করা হয়:

প্রিফিক্স: oauthv2authcode.{policy_name}.{variable_name}

উদাহরণ: oauthv2authcode.GenerateCodePolicy.code

ভেরিয়েবেল	বিবরণ
`code`	নীতি কার্যকর করার সময় জেনারেট হওয়া অনুমোদন কোড।
`redirect_uri`	রেজিস্টার করা ক্লায়েন্ট অ্যাপের সাথে যুক্ত রিডাইরেক্ট URI.
`scope`	ক্লায়েন্টের অনুরোধে পাস করা ঐচ্ছিক OAuth স্কোপ।
`client_id`	ক্লায়েন্ট অনুরোধে পাস করা ক্লায়েন্ট আইডি।

GenerateAccessToken এবং RefreshAccessToken অপারেশন

GenerateAccessToken এবং RefreshAccessToken অপারেশন সফলভাবে এক্সিকিউট হলে এইসব ভেরিয়েবল সেট করা হয় । মনে রাখবেন, রিফ্রেশ টোকেন ভেরিয়েবল ক্লায়েন্ট ক্রেডেনশিয়াল গ্রান্ট ফ্লোয়ের ক্ষেত্রে প্রযোজ্য হয় না।

প্রিফিক্স: oauthv2accesstoken.{policy_name}.{variable_name}

উদাহরণ: oauthv2accesstoken.GenerateTokenPolicy.access_token

ভেরিয়েবেলের নাম	বিবরণ
`access_token`	জেনারেট করা অ্যাক্সেস টোকেন।
`client_id`	এই টোকেনের সাথে যুক্ত ডেভেলপার অ্যাপের ক্লায়েন্ট আইডি।
`expires_in`	টোকেনের মেয়াদ শেষ হওয়ার ভ্যালু। বিবরণের জন্য <ExpiresIn> এলিমেন্ট দেখুন। মনে রাখবেন, উত্তরে expires_in-এর মেয়াদ সেকেন্ডে দেখানো হয়।
`scope`	টোকেনের জন্য কনফিগার করা উপলভ্য স্কোপের তালিকা। OAuth2 স্কোপের সাথে কাজ করা দেখুন।
`status`	`approved` অথবা `revoked`।
`token_type`	`BearerToken`-এ সেট করা আছে।

`developer.email`	টোকেনের সাথে যুক্ত ডেভেলপার অ্যাপের মালিক রেজিস্টার করা ডেভেলপারের ইমেল আইডি।
`organization_name`	যেখানে প্রক্সি এক্সিকিউট করে সেই সংস্থা।
`api_product_list`	টোকেনের সংশ্লিষ্ট ডেভেলপার অ্যাপের সাথে যুক্ত প্রোডাক্টের তালিকা।

`refresh_count`
`refresh_token`	জেনারেট করা রিফ্রেশ টোকেন। মনে রাখবেন যে ক্লায়েন্ট ক্রেডেনশিয়াল গ্রান্ট টাইপের জন্য রিফ্রেশ টোকেন তৈরি করা হয় না।
`refresh_token_expires_in`	রিফ্রেশ টোকেনের মেয়াদ, সেকেন্ডে।
`refresh_token_issued_at`	এই সময়ের ভ্যালু হল সংশ্লিষ্ট ৩২-বিট টাইমস্ট্যাম্প পরিমাণের স্ট্রিং উপস্থাপনা। যেমন, 'Wed, 21 Aug 2013 19:16:47 UTC' টাইমস্ট্যাম্প ভ্যালু 1377112607413-এর সাথে সম্পর্কিত।
`refresh_token_status`	`approved` অথবা `revoked`।

GenerateAccessTokenImplicitGrant

ইমপ্লিসিট গ্র্যান্ট টাইপ ফ্লোয়ের জন্য GenerateAccessTokenImplicit অপারেশন সফলভাবে এক্সিকিউট হলে এইসব ভেরিয়েবল সেট করা হয়।

প্রিফিক্স: oauthv2accesstoken.{policy_name}.{variable_name}

উদাহরণ: oauthv2accesstoken.RefreshTokenPolicy.access_token

ভেরিয়েবেল	বিবরণ
`oauthv2accesstoken.access_token`	নীতি কার্যকর করার সময় জেনারেট হওয়া অ্যাক্সেস টোকেন।
`oauthv2accesstoken.{policy_name}.expires_in`	টোকেনের মেয়াদ শেষ হওয়ার ভ্যালু, সেকেন্ডে। বিবরণের জন্য <ExpiresIn> এলিমেন্ট দেখুন।

সমস্যার রেফারেন্স

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

রানটাইম সমস্যা

নীতি এক্সিকিউট করার সময় এই সমস্যা হতে পারে।

সমস্যার কোড	HTTP স্ট্যাটাস	কারণ	অপারেশন থেকে পাওয়া
`steps.oauth.v2.access_token_expired`	401	অ্যাক্সেস টোকেনের মেয়াদ শেষ হয়ে গেছে।	VerifyAccessToken InvalidateToken
`steps.oauth.v2.access_token_not_approved`	401	অ্যাক্সেস টোকেন প্রত্যাহার করা হয়েছে।	VerifyAccessToken
`steps.oauth.v2.apiresource_doesnot_exist`	401	অ্যাক্সেস টোকেনের সাথে যুক্ত কোনও API প্রোডাক্টে অনুরোধ করা রিসোর্সটি নেই।	VerifyAccessToken
`steps.oauth.v2.FailedToResolveAccessToken`	500	নীতিটি `<AccessToken>` এলিমেন্টে নির্দিষ্ট করা ভেরিয়েবলে অ্যাক্সেস টোকেন খুঁজে পাবে বলে আশা করা হয়েছিল, কিন্তু ভেরিয়েবলটি সমাধান করা যায়নি।	GenerateAccessToken
`steps.oauth.v2.FailedToResolveAuthorizationCode`	500	নীতিটি `<Code>` এলিমেন্টে নির্দিষ্ট করা একটি ভেরিয়েবলে একটি অনুমোদন কোড খুঁজে পাওয়ার কথা, কিন্তু ভেরিয়েবলটি সমাধান করা যায়নি।	GenerateAuthorizationCode
`steps.oauth.v2.FailedToResolveClientId`	500	নীতিটি `<ClientId>` এলিমেন্টে নির্দিষ্ট করা ভেরিয়েবলে ক্লায়েন্ট আইডি খুঁজে পাওয়ার কথা, কিন্তু ভেরিয়েবলটি সমাধান করা যায়নি।	GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken
`steps.oauth.v2.FailedToResolveRefreshToken`	500	নীতিটি `<RefreshToken>` এলিমেন্টে নির্দিষ্ট করা ভেরিয়েবলে একটি রিফ্রেশ টোকেন খুঁজে পাওয়ার কথা, কিন্তু ভেরিয়েবলটি সমাধান করা যায়নি।	RefreshAccessToken
`steps.oauth.v2.FailedToResolveToken`	500	নীতিটি `<Tokens>` এলিমেন্টে নির্দিষ্ট করা ভেরিয়েবলে একটি টোকেন খুঁজে পাবে বলে আশা করা হয়েছিল, কিন্তু ভেরিয়েবলটি সমাধান করা যায়নি।	ValidateToken InvalidateToken
`steps.oauth.v2.InsufficientScope`	403	অনুরোধে দেখানো অ্যাক্সেস টোকেনের সুযোগ, যাচাই করা অ্যাক্সেস টোকেন নীতিতে নির্দিষ্ট করা সুযোগের সাথে মেলে না। স্কোপ সম্পর্কে জানতে, OAuth2 স্কোপের সাথে কাজ করা দেখুন।	VerifyAccessToken
`steps.oauth.v2.invalid_access_token`	401	ক্লায়েন্টের পাঠানো অ্যাক্সেস টোকেনটি সঠিক নয়।	VerifyAccessToken
`steps.oauth.v2.invalid_client`	401	নীতির `<GenerateResponse>` প্রপার্টি true হিসেবে সেট করা থাকলে এবং অনুরোধে পাঠানো ক্লায়েন্ট আইডি ভুল হলে এই সমস্যার নাম রিটার্ন করা হয়। আপনার প্রক্সির সাথে যুক্ত ডেভেলপার অ্যাপের জন্য আপনি সঠিক ক্লায়েন্ট কী ও সিক্রেট ভ্যালু ব্যবহার করছেন কিনা তা নিশ্চিত করুন। সাধারণত, এই মানগুলি Base64 এনকোড করা Basic Authorization হেডার হিসেবে পাঠানো হয়। মনে রাখবেন: `invalid_client` ও `InvalidClientIdentifier` নাম, দুটিই যাতে ধরা পড়ে, তার জন্য আগে থেকে থাকা ফল্ট রুল কন্ডিশন পরিবর্তন করার সাজেশন দেওয়া হয়। আরও তথ্য ও উদাহরণের জন্য ১৬.০৯.২১ রিলিজ নোট দেখুন।	GenerateAccessToken RefreshAccessToken
`steps.oauth.v2.InvalidRequest`	400	এই সমস্যার নাম একাধিক ভিন্ন ধরনের সমস্যার জন্য ব্যবহার করা হয়, সাধারণত অনুরোধে পাঠানো প্যারামিটার অনুপস্থিত বা ভুল হলে এই সমস্যা হয়। `<GenerateResponse>`-এর মান `false` হলে, নিচে বর্ণিত ফল্ট ভেরিয়েবল ব্যবহার করে ফল্ট নেম ও কারণের মতো সমস্যার বিবরণ পান।	GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken
`steps.oauth.v2.InvalidAccessToken`	401	অনুমোদনকারী হেডারে "Bearer" শব্দটি নেই, যা প্রয়োজন। যেমন: `Authorization: Bearer your_access_token`	VerifyAccessToken
`steps.oauth.v2.InvalidAPICallAsNoApiProductMatchFound`	401	অ্যাক্সেস টোকেনের সাথে যুক্ত প্রোডাক্টে API প্রক্সি নেই। পরামর্শ: অ্যাক্সেস টোকেনের সাথে যুক্ত প্রোডাক্ট সঠিকভাবে কনফিগার করা হয়েছে কিনা তা নিশ্চিত করুন। যেমন, রিসোর্স পাথে ওয়াইল্ডকার্ড ব্যবহার করলে, ওয়াইল্ডকার্ড সঠিকভাবে ব্যবহার করা হচ্ছে কিনা তা নিশ্চিত করুন। আরও বিবরণের জন্য API প্রোডাক্ট তৈরি করুন দেখুন। এই সমস্যার কারণ সম্পর্কে আরও নির্দেশিকা পেতে, এই Apigee কমিউনিটি পোস্ট দেখুন।	VerifyAccessToken
`steps.oauth.v2.InvalidClientIdentifier`	500	নীতির `<GenerateResponse>` প্রপার্টি false হিসেবে সেট করা থাকলে এবং অনুরোধে পাঠানো ক্লায়েন্ট আইডি সঠিক না হলে এই সমস্যার নাম রিটার্ন করা হয়। আপনার প্রক্সির সাথে যুক্ত ডেভেলপার অ্যাপের জন্য সঠিক ক্লায়েন্ট কী ও সিক্রেট ভ্যালু ব্যবহার করছেন কিনা তা নিশ্চিত করতে চেক করুন। সাধারণত, এই মানগুলি Base64 এনকোড করা প্রাথমিক অনুমোদন হেডার হিসেবে পাঠানো হয়। মনে রাখবেন: এই পরিস্থিতিতে, এই সমস্যাকে `invalid_client` বলা হত। `invalid_client` এবং `InvalidClientIdentifier`, দুটি নামই যাতে ধরা পড়ে, তার জন্য আগে থেকে থাকা ফল্ট রুল কন্ডিশন পরিবর্তন করার সাজেশন দেওয়া হয়। আরও তথ্য ও উদাহরণের জন্য ১৬.০৯.২১ রিলিজ নোট দেখুন।	GenerateAccessToken RefreshAccessToken
`steps.oauth.v2.InvalidParameter`	500	নীতিতে অবশ্যই অ্যাক্সেস টোকেন বা অনুমোদন কোড উল্লেখ করতে হবে, তবে দুটিই উল্লেখ করা যাবে না।	GenerateAuthorizationCode GenerateAccessTokenImplicitGrant
`steps.oauth.v2.InvalidTokenType`	500	`<Tokens>/<Token>` এলিমেন্টে আপনাকে টোকেনের ধরন (যেমন, `refreshtoken`) নির্দিষ্ট করতে হবে। ক্লায়েন্ট ভুল ধরন পাস করলে, এই সমস্যাটি দেখানো হয়।	ValidateToken InvalidateToken
`steps.oauth.v2.MissingParameter`	500	উত্তর দেওয়ার ধরন হল `token`, কিন্তু কোনও গ্র্যান্টের ধরন নির্দিষ্ট করা নেই।	GenerateAuthorizationCode GenerateAccessTokenImplicitGrant
`steps.oauth.v2.UnSupportedGrantType`	500	ক্লায়েন্ট এমন গ্র্যান্টের ধরন নির্দিষ্ট করেছে যা নীতিতে কাজ করে না (এটি <SupportedGrantTypes> এলিমেন্টে তালিকাভুক্ত নেই)। মনে রাখবেন: বর্তমানে একটি সমস্যা রয়েছে যেখানে অসমর্থিত গ্র্যান্টের ধরন সংক্রান্ত সমস্যা সঠিকভাবে দেখানো হচ্ছে না। অননুমোদিত গ্র্যান্টের ধরন সংক্রান্ত সমস্যা হলে, প্রক্সি প্রত্যাশিতভাবে সমস্যার ফ্লোতে প্রবেশ করে না।	GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken

ডিপ্লয়মেন্ট সংক্রান্ত সমস্যা

এই নীতি থাকা কোনও প্রক্সি আপনি প্রয়োগ করলে, এই সমস্যা হতে পারে।

সমস্যার নাম	কারণ
`InvalidValueForExpiresIn`	`<ExpiresIn>` এলিমেন্টের জন্য, সঠিক মান হল পজিটিভ পূর্ণসংখ্যা এবং `-1`।
`InvalidValueForRefreshTokenExpiresIn`	`<RefreshTokenExpiresIn>` এলিমেন্টের জন্য, সঠিক মান হল পজিটিভ পূর্ণসংখ্যা এবং `-1`।
`InvalidGrantType`	`<SupportedGrantTypes>` এলিমেন্টে ভুল গ্র্যান্টের ধরন উল্লেখ করা হয়েছে। বৈধ ধরনের তালিকার জন্য নীতি রেফারেন্স দেখুন।
`ExpiresInNotApplicableForOperation`	<Operations> এলিমেন্টে নির্দিষ্ট করা অপারেশনগুলি যেন মেয়াদ শেষ হয়ে যাওয়া সংক্রান্ত সুবিধা দেয়, তা নিশ্চিত করুন। যেমন, VerifyToken অপারেশনটি তা করে না।
`RefreshTokenExpiresInNotApplicableForOperation`	<Operations> এলিমেন্টে উল্লেখ করা অপারেশনগুলি রিফ্রেশ টোকেনের মেয়াদ শেষ হওয়া সম্পর্কিত কাজ করতে পারে কিনা তা নিশ্চিত করুন। যেমন, VerifyToken অপারেশনটি তা করে না।
`GrantTypesNotApplicableForOperation`	<SupportedGrantTypes>-এ উল্লেখ করা গ্র্যান্টের ধরন নির্দিষ্ট অপারেশনের জন্য কাজ করে কিনা তা ভালোভাবে দেখে নিন।
`OperationRequired`	আপনাকে অবশ্যই `<Operation>` এলিমেন্ট ব্যবহার করে এই নীতিতে একটি অপারেশন নির্দিষ্ট করতে হবে। মনে রাখবেন: `<Operation>` এলিমেন্ট না থাকলে, UI স্কিমা যাচাইকরণ সংক্রান্ত সমস্যা দেখাবে।
`InvalidOperation`	আপনাকে অবশ্যই এই নীতিতে `<Operation>` এলিমেন্ট ব্যবহার করে একটি সঠিক অপারেশন নির্দিষ্ট করতে হবে। মনে রাখবেন: `<Operation>` এলিমেন্টটি ভুল হলে, UI স্কিমা যাচাইকরণ সংক্রান্ত সমস্যা দেখায়।
`TokenValueRequired`	আপনাকে অবশ্যই `<Tokens>` এলিমেন্টে `<Token>` টোকেন ভ্যালু উল্লেখ করতে হবে।

ফল্ট ভেরিয়েবল

এই নীতি রানটাইমে কোনও সমস্যা ট্রিগার করলে, এইসব ভেরিয়েবল সেট করা হয়।

মনে রাখবেন: ফল্ট রুলের কন্ডিশন তৈরি করতে আপনি এইসব ভেরিয়েবল ব্যবহার করতে পারবেন। <GenerateResponse>-এর মান false হলে সমস্যা হলে এইসব ভেরিয়েবল অটো-ফিল হয়ে যায়। <GenerateResponse> is true হলে, কোনও সমস্যা হলে নীতিটি ক্লায়েন্টকে অবিলম্বে একটি উত্তর পাঠায় -- সমস্যার ফ্লো এড়িয়ে যাওয়া হয় এবং এই ভেরিয়েবলগুলি পপুলেট করা হয় না। আরও তথ্যের জন্য, নীতি সংক্রান্ত সমস্যার ব্যাপারে আপনার কী জানা প্রয়োজন দেখুন।

ভেরিয়েবল	কোথায়	উদাহরণ
`fault.name="fault_name"`	`fault_name` হল সমস্যার নাম, যা উপরে দেওয়া রানটাইম সংক্রান্ত সমস্যা সারণীতে তালিকাভুক্ত করা আছে। ফল্ট কোডের শেষ অংশটি হল ফল্টের নাম।	`fault.name = "InvalidRequest"`
`oauthV2.policy_name.failed`	`policy_name` হল সেই নীতির ব্যবহারকারী-নির্দিষ্ট নাম যার কারণে সমস্যা হয়েছে।	`oauthV2.GenerateAccesstoken.failed = true`
`oauthV2.policy_name.fault.name`	`policy_name` হল সেই নীতির ব্যবহারকারী-নির্দিষ্ট নাম যার কারণে সমস্যা হয়েছে।	`oauthV2.GenerateAccesstoken.fault.name = InvalidRequest` মনে রাখবেন: VerifyAccessToken অপারেশনের জন্য, ফল্টের নামের মধ্যে এই প্রত্যয়টি অন্তর্ভুক্ত থাকে: `keymanagement.service` যেমন: `keymanagement.service.invalid_access_token`
`oauthV2.policy_name.fault.cause`	`policy_name` হল সেই নীতির ব্যবহারকারী-নির্দিষ্ট নাম যার কারণে সমস্যা হয়েছে।	`oauthV2.GenerateAccesstoken.cause = Required param : grant_type`

সমস্যার উত্তরের উদাহরণ

<GenerateResponse> এলিমেন্ট true হলে, এই উত্তরগুলি ক্লায়েন্টকে ফেরত পাঠানো হয়।

মনে রাখবেন: সমস্যার সমাধান করার জন্য, পেশাদার পদ্ধতি হল সমস্যার উত্তরের errorcode অংশটি ট্র্যাক করা। faultstring-এ দেওয়া টেক্সটের উপর নির্ভর করবেন না, কারণ এটি পরিবর্তন হতে পারে।

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

নীতি স্কিমা

প্রতিটি নীতির ধরন XML স্কিমা (.xsd) দ্বারা সংজ্ঞায়িত করা হয়। রেফারেন্সের জন্য, নীতি স্কিমা GitHub-এ উপলভ্য।

ডিফল্ট OAuth কনফিগারেশনের সাথে কাজ করা

Apigee Edge-এ প্রতিটি সংস্থার (এমনকি ফ্রি ট্রায়াল সংস্থারও) জন্য OAuth টোকেন এন্ডপয়েন্ট প্রদান করা হয়। oauth নামের API প্রক্সিতে এন্ডপয়েন্ট আগে থেকেই কনফিগার করা থাকে। Apigee Edge-এ অ্যাকাউন্ট তৈরি করার সাথে সাথেই আপনি টোকেন এন্ডপয়েন্ট ব্যবহার করা শুরু করতে পারবেন। আরও বিবরণের জন্য, OAuth এন্ডপয়েন্ট বোঝা দেখুন।

অ্যাক্সেস টোকেন মুছে দেওয়া

অ্যাক্সেস টোকেন ও রিফ্রেশ টোকেন (যদি থাকে) দু'টির মেয়াদ শেষ হওয়ার পরে, ডিফল্ট হিসেবে ৩ দিন (২৫৯২০০ সেকেন্ড) পরে Apigee Edge সিস্টেম থেকে OAuth2 টোকেন মুছে দেওয়া হয়। কিছু ক্ষেত্রে, আপনি এই ডিফল্ট পরিবর্তন করতে চাইতে পারেন। যেমন, প্রচুর টোকেন তৈরি হলে, ডিস্ক স্পেস বাঁচানোর জন্য আপনি হয়তো পার্জ করার সময়সীমা কমাতে চাইবেন।

আপনি প্রাইভেট ক্লাউডের জন্য Edge ব্যবহার করলে, এই বিভাগে ব্যাখ্যা করা সংস্থা সংক্রান্ত প্রপার্টি সেট করে আপনি এই ডিফল্ট পরিবর্তন করতে পারবেন। (মেয়াদ শেষ হয়ে যাওয়া টোকেন ৩ দিন পরে মুছে দেওয়া Edge for Private Cloud ভার্সন 4.19.01 ও তার পরের ভার্সনে প্রযোজ্য। আগের ভার্সনের ক্ষেত্রে, ডিফল্ট পার্জ ইন্টারভ্যাল হল ১৮০ দিন।)

Edge Private Cloud 4.16.01 ও এর পরের ভার্সনের জন্য ডেটা মুছে দেওয়ার সেটিংস আপডেট করা

মনে রাখবেন: এই সেটিংস প্রয়োগ করার পরে জেনারেট করা টোকেনগুলিই শুধু প্রভাবিত হয়; আগে জেনারেট করা টোকেনের ক্ষেত্রে সেটিংস প্রযোজ্য হয় না।

প্রাইভেট ক্লাউড:

এডিট করার জন্য এই ফাইলটি খুলুন:
```
/opt/apigee/customer/application/message-processor.properties
```
টোকেনের মেয়াদ শেষ হওয়ার পরে সেটি মুছে ফেলার আগে কত সেকেন্ড অপেক্ষা করতে হবে তা সেট করতে নিম্নলিখিত প্রপার্টি যোগ করুন:
```
conf_keymanagement_oauth.access.token.purge.after.seconds=<number of seconds>
```
মেসেজ প্রসেসর রিস্টার্ট করুন। যেমন:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

অ্যাক্সেস টোকেনের মেয়াদ কখনও শেষ না হলে, এটি কখনওই সরিয়ে দেওয়া হবে না। আপনি <ExpiresIn> এবং <RefreshTokenExpiresIn> অ্যাট্রিবিউট ব্যবহার করে OAuthV2 নীতিতে টোকেন মেয়াদ শেষ হওয়ার সময় সেট করতে পারবেন।

Edge Private Cloud 4.15.07-এর জন্য পার্জ সেটিংস আপডেট করা হচ্ছে

মনে রাখবেন: এই সেটিংস প্রয়োগ করার পরে জেনারেট করা টোকেন শুধুমাত্র প্রভাবিত হয়; আগে জেনারেট করা টোকেনের ক্ষেত্রে সেটিংস প্রযোজ্য হয় না।

প্রাইভেট ক্লাউড:

OAuthV2 নীতিতে <ExpiresIn> এবং <RefreshTokenExpiresIn> অ্যাট্রিবিউটের জন্য পজিটিভ ভ্যালু সেট করুন। ভ্যালু মিলিসেকেন্ডে আছে। যেমন:
```
<ExpiresIn>1000</ExpiresIn>
<RefreshTokenExpiresIn>10000</RefreshTokenExpiresIn>
```
প্রক্সি আবার ডেপ্লয় করুন।

আপনার প্রতিষ্ঠানের জন্য টোকেন মুছে ফেলার প্রপার্টি আপডেট করতে এই API ব্যবহার করুন:

POST https://<host-name>/v1/organizations/<org-name>

পেলোড:

<Organization name="AutomationOrganization">
 <Description>Desc</Description>
 <Properties>
     <Property name="keymanagement.oauth20.access.token.purge">true</Property>
     <Property name="keymanagement.oauth20.access.token.purge.after.seconds">120</Property>
 </Properties>
</Organization>

মেসেজ প্রসেসর রিস্টার্ট করুন। যেমন:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
এই API, AutomationOrganization নামের সংস্থার জন্য টোকেন মুছে ফেলার প্রপার্টিকে true হিসেবে সেট করে। এই ক্ষেত্রে, টোকেন ও রিফ্রেশ টোকেন দুটির মেয়াদ শেষ হওয়ার ১২০ সেকেন্ড পরে ডেটাবেস থেকে অ্যাক্সেস টোকেন মুছে দেওয়া হবে।

এছাড়াও, <ExpiresIn> এলিমেন্ট দেখুন।

RFC মেনে না চলা আচরণ

OAuthV2 নীতি এমন টোকেন উত্তর দেয় যা নির্দিষ্ট নন-RFC-কম্প্লায়েন্ট প্রপার্টি কন্টেন করে। নিচের সারণীতে OAuthV2 নীতি দ্বারা ফেরত পাঠানো নন-কম্প্লায়েন্ট প্রপার্টি এবং সংশ্লিষ্ট কম্প্লায়েন্ট প্রপার্টি দেখানো হয়েছে।

OAuthV2 রিটার্ন করে:	RFC-কমপ্লায়েন্ট প্রপার্টি হল:
`"token_type":"BearerToken"`	`"token_type":"Bearer"`
`"expires_in":"3600"`	`"expires_in":3600` (সম্মতিপূর্ণ ভ্যালু হল একটি সংখ্যা, কোনও স্ট্রিং নয়।)

এছাড়াও, grant_type = refresh_token-এর ক্ষেত্রে মেয়াদ শেষ হয়ে যাওয়া রিফ্রেশ টোকেনের জন্য সমস্যার উত্তর হল:

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

তবে, RFC-এর সাথে মানানসই উত্তর হল:

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

OAuthV2 নীতি

কী

নমুনা

VerifyAccessToken

VerifyAccessToken

GenerateAccessToken

অ্যাক্সেস টোকেন তৈরি করা

GenerateAuthorizationCode

অনুমোদন কোড জেনারেট করা

RefreshAccessToken

অ্যাক্সেস টোকেন রিফ্রেশ করা

উত্তর ফ্লো টোকেন

রেসপন্স ফ্লোতে অ্যাক্সেস টোকেন তৈরি করা

এলিমেন্ট রেফারেন্স

<OAuthV2> অ্যাট্রিবিউট

<DisplayName> উপাদান

<AccessToken> এলিমেন্ট

<AccessTokenPrefix> এলিমেন্ট

<AppEndUser> এলিমেন্ট

<Attributes/Attribute>

উত্তরে কাস্টম অ্যাট্রিবিউট দেখানো বা লুকানো

<ClientId> এলিমেন্ট

<Code> এলিমেন্ট

<ExpiresIn> এলিমেন্ট

<ExternalAccessToken> এলিমেন্ট

<ExternalAuthorization> এলিমেন্ট

<ExternalAuthorizationCode> এলিমেন্ট

<ExternalRefreshToken> এলিমেন্ট

<GenerateResponse> এলিমেন্ট

<GenerateErrorResponse> এলিমেন্ট

<GrantType>

<Operation> এলিমেন্ট

<PassWord> এলিমেন্ট

<RedirectUri> এলিমেন্ট

রিডাইরেকশন URI সম্পর্কে

<RefreshToken> এলিমেন্ট

<RefreshTokenExpiresIn> এলিমেন্ট

<ResponseType> এলিমেন্ট

<ReuseRefreshToken> এলিমেন্ট

<Scope> এলিমেন্ট

<State> এলিমেন্ট

<StoreToken> এলিমেন্ট

<SupportedGrantTypes>/<GrantType> এলিমেন্ট

<Tokens>/<Token> এলিমেন্ট

<UserName> এলিমেন্ট

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

অনুরোধ ভেরিয়েবলের লোকেশন নির্দিষ্ট করা

ফ্লো ভেরিয়েবল

VerifyAccessToken অপারেশন

GenerateAuthorizationCode অপারেশন

GenerateAccessToken এবং RefreshAccessToken অপারেশন

GenerateAccessTokenImplicitGrant

সমস্যার রেফারেন্স

রানটাইম সমস্যা

ডিপ্লয়মেন্ট সংক্রান্ত সমস্যা

ফল্ট ভেরিয়েবল

সমস্যার উত্তরের উদাহরণ

ভুল নিয়মের উদাহরণ

নীতি স্কিমা

ডিফল্ট OAuth কনফিগারেশনের সাথে কাজ করা

অ্যাক্সেস টোকেন মুছে দেওয়া

Edge Private Cloud 4.16.01 ও এর পরের ভার্সনের জন্য ডেটা মুছে দেওয়ার সেটিংস আপডেট করা

Edge Private Cloud 4.15.07-এর জন্য পার্জ সেটিংস আপডেট করা হচ্ছে

RFC মেনে না চলা আচরণ

সম্পর্কিত বিষয়