OAuthV2 নীতি

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

কি

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

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

নমুনা

<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuth-v20-2">
    <DisplayName>OAuth v2.0 2</DisplayName>
    <Operation>VerifyAccessToken</Operation>
    <AccessTokenPrefix>Bearer</AccessTokenPrefix> <!-- Optional, default is Bearer -->
</OAuthV2>

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

<OAuthV2 enabled="true" continueOnError="false" async="false" name="generateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <AppEndUser>Doe</AppEndUser>
    <UserName>jdoe</UserName>
    <PassWord>jdoe</PassWord>
    <GrantType>grant_type</GrantType>
    <ClientId>a_valid_client_id</ClientId>
    <SupportedGrantTypes>
        <GrantType>password</GrantType>
    </SupportedGrantTypes>
</OAuthV2>

var client_id = context.getVariable("local_clientid");
var client_secret = context.getVariable("local_secret");
context.setVariable("request.header.Authorization","Basic "+CryptoJS.enc.Base64.stringify(CryptoJS.enc.Latin1
                                      .parse(client_id + ':' + client_secret)));

" মৌলিক প্রমাণীকরণ শংসাপত্র এনকোডিং " আরও দেখুন।

উপাদানের রেফারেন্স

নীতিমালার রেফারেন্সটি OAuthV2 নীতির উপাদান এবং বৈশিষ্ট্যগুলি বর্ণনা করে।

নিচে দেখানো নমুনা নীতিটি অনেকগুলি সম্ভাব্য কনফিগারেশনের মধ্যে একটি। এই নমুনাটি GenerateAccessToken অপারেশনের জন্য কনফিগার করা একটি OAuthV2 নীতি দেখায়। এতে প্রয়োজনীয় এবং ঐচ্ছিক উপাদান রয়েছে। বিস্তারিত জানার জন্য এই বিভাগে উপাদানের বিবরণ পড়ুন।

<OAuthV2 name="GenerateAccessToken">
  <!-- This policy generates an OAuth 2.0 access token using the client_credentials grant type -->
  <Operation>GenerateAccessToken</Operation>
  <!-- This is in millseconds, so expire in an hour -->
  <ExpiresIn>3600000</ExpiresIn>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.queryparam.grant_type</GrantType>
  <GenerateResponse/>
</OAuthV2>

<OAuthV2> বৈশিষ্ট্যাবলী

<OAuthV2 async="false" continueOnError="false" enabled="true" name="MyOAuthPolicy">

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

<DisplayName> উপাদান

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

<DisplayName>Policy Display Name</DisplayName>

<AccessToken> উপাদান

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

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

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

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

<AccessTokenPrefix> উপাদান

<AccessTokenPrefix>Bearer</AccessTokenPrefix>

ডিফল্টরূপে, VerifyAccessToken আশা করে যে অ্যাক্সেস টোকেনটি একটি Authorization হেডারে Bearer টোকেন হিসেবে পাঠানো হবে। উদাহরণস্বরূপ:

-H "Authorization: Bearer Rft3dqrs56Blirls56a"

বর্তমানে, Bearer হল একমাত্র সমর্থিত প্রিফিক্স।

<AppEndUser> উপাদান

<AppEndUser>request.queryparam.app_enduser</AppEndUser>

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

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

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

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

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

<ClientId> উপাদান

<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>10000</ExpiresIn>

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

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

পাবলিক ক্লাউডের জন্য Apigee Edge ব্যবহার করে, এজ নিম্নলিখিত সত্তাগুলিকে অ্যাক্সেস করার পরে কমপক্ষে 180 সেকেন্ডের জন্য ক্যাশে রাখে।

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

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

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

টোকেন তৈরির পর জোর করে মেয়াদোত্তীর্ণ করার কোনও উপায় এজ সমর্থন করে না। যদি আপনার জোর করে টোকেনের মেয়াদোত্তীর্ণ করার প্রয়োজন হয় (উদাহরণস্বরূপ, কোনও শর্তের উপর ভিত্তি করে), তাহলে একটি সম্ভাব্য সমাধান এই Apigee কমিউনিটি পোস্টে বর্ণনা করা হয়েছে।

ডিফল্টরূপে, মেয়াদোত্তীর্ণ অ্যাক্সেস টোকেনগুলি মেয়াদ শেষ হওয়ার 3 দিন পরে স্বয়ংক্রিয়ভাবে Apigee Edge সিস্টেম থেকে মুছে ফেলা হয়। অ্যাক্সেস টোকেনগুলি মুছে ফেলার পদ্ধতিও দেখুন।

প্রাইভেট ক্লাউড: এজ ফর প্রাইভেট ক্লাউড ইনস্টলেশনের জন্য, ডিফল্ট মান 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. নিশ্চিত করুন যে properties ফাইলটি "apigee" ব্যবহারকারীর মালিকানাধীন:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. মেসেজ প্রসেসর পুনরায় চালু করুন।

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

<ExternalAccessToken> উপাদান

<ExternalAccessToken>request.queryparam.external_access_token</ExternalAccessToken>

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

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

<এক্সটারনালঅথরাইজেশন> উপাদান

<ExternalAuthorization>true</ExternalAuthorization>

যদি এই উপাদানটি মিথ্যা হয় বা উপস্থিত না থাকে, তাহলে Edge সাধারণত Apigee Edge অনুমোদন স্টোরের বিরুদ্ধে client_id এবং client_secret যাচাই করে। যখন আপনি তৃতীয়-পক্ষের OAuth টোকেনগুলির সাথে কাজ করতে চান তখন এই উপাদানটি ব্যবহার করুন। এই উপাদানটি ব্যবহার সম্পর্কে বিস্তারিত জানার জন্য, তৃতীয়-পক্ষের OAuth টোকেন ব্যবহার দেখুন।

<ExternalAuthorizationCode> উপাদান

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

Apigee Edge কে বলে যে একটি বহিরাগত প্রমাণীকরণ কোড কোথায় পাওয়া যাবে (Apigee Edge দ্বারা তৈরি নয় এমন একটি প্রমাণীকরণ কোড)।

request.queryparam.external_auth_code ভেরিয়েবলটি নির্দেশ করে যে বহিরাগত প্রমাণীকরণ কোডটি একটি কোয়েরি প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, যেমন, ?external_auth_code=12345678 । উদাহরণস্বরূপ, একটি 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 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 নামক একটি ফ্লো ভেরিয়েবল নতুন মিন্ট করা auth কোড দিয়ে পূর্ণ করা হয়। মনে রাখবেন যে প্রতিক্রিয়াতে expires_in সেকেন্ডে প্রকাশ করা হয়।

<উপাদান> ত্রুটি প্রতিক্রিয়া তৈরি করুন

<GenerateErrorResponse enabled='true'/>

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

<গ্র্যান্টটাইপ>

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

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

উদাহরণস্বরূপ request.queryparam.grant_type নির্দেশ করে যে পাসওয়ার্ডটি একটি কোয়েরি প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, যেমন, ?grant_type=password । উদাহরণস্বরূপ, একটি HTTP হেডারে grant টাইপ প্রয়োজন করতে, এই মানটি 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 কেবল যাচাই করছে যে সেগুলি উপস্থিত আছে। টোকেন জেনারেশন নীতি কার্যকর হওয়ার আগে মানগুলির অনুরোধ পুনরুদ্ধার করা এবং সেগুলি একটি পরিচয় প্রদানকারীর কাছে পাঠানো API ডেভেলপারের উপর নির্ভর করে।

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

<RedirectUri> উপাদান

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

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

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

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

• (প্রয়োজনীয়) যদি কোনও কলব্যাক URL ডেভেলপার অ্যাপের সাথে নিবন্ধিত থাকে যা অনুরোধের ক্লায়েন্ট কীগুলির সাথে সম্পর্কিত, এবং যদি redirect_uri অনুরোধে উপস্থিত থাকে, তাহলে দুটি অবশ্যই হুবহু মিলবে। যদি তারা মিল না করে, তাহলে একটি ত্রুটি দেখাবে। Edge-এ ডেভেলপার অ্যাপ নিবন্ধন এবং একটি কলব্যাক URL নির্দিষ্ট করার বিষয়ে তথ্যের জন্য, Register apps and manage API keys দেখুন।

• (ঐচ্ছিক) যদি একটি কলব্যাক 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 তে সেট করুন। অ্যাক্সেস টোকেন এবং অনুমোদন কোডের অনুরোধ আরও দেখুন।

<RefreshToken> উপাদান

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

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

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

<RefreshTokenExpiresIn> উপাদান

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

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

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

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

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

প্রাইভেট ক্লাউড: এজ ফর প্রাইভেট ক্লাউড ইনস্টলেশনের জন্য, ডিফল্ট মান 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. নিশ্চিত করুন যে properties ফাইলটি "apigee" ব্যবহারকারীর মালিকানাধীন:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. মেসেজ প্রসেসর পুনরায় চালু করুন।

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

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

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

এই উপাদানটি এজকে ক্লায়েন্ট অ্যাপটি কোন ধরণের অনুদানের অনুরোধ করছে তা জানায়। এটি শুধুমাত্র অনুমোদন কোড এবং অন্তর্নিহিত অনুদানের ধরণের প্রবাহের সাথে ব্যবহৃত হয়।

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

<ReuseRefreshToken> উপাদান

<ReuseRefreshToken>true</ReuseRefreshToken>

যখন true তে সেট করা হয়, তখন বিদ্যমান রিফ্রেশ টোকেনটি মেয়াদ শেষ না হওয়া পর্যন্ত পুনরায় ব্যবহার করা হয়। যদি false , তাহলে একটি বৈধ রিফ্রেশ টোকেন উপস্থাপন করা হলে Apigee Edge দ্বারা একটি নতুন রিফ্রেশ টোকেন জারি করা হয়।

<স্কোপ> উপাদান

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

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

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

<Scope>A B</Scope>

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

<স্থির> উপাদান

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

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

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

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

 <StoreToken>true</StoreToken>

<ExternalAuthorization> উপাদানটি true হলে এই উপাদানটিকে true সেট করুন। <StoreToken> উপাদানটি Apigee Edge কে বহিরাগত অ্যাক্সেস টোকেন সংরক্ষণ করতে বলে। অন্যথায়, এটি স্থায়ী হবে না।

<সম্পর্কিত>গ্রান্টটাইপ>/<গ্রান্টটাইপ> উপাদান

<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> উপাদানটিও দেখুন (যা একটি উচ্চ-স্তরের উপাদান যা Apigee Edge-কে ক্লায়েন্ট অনুরোধে পাস করা grant_type প্যারামিটারের জন্য কোথায় সন্ধান করা উচিত তা নির্দিষ্ট করতে ব্যবহৃত হয়। Edge নিশ্চিত করবে যে grant_type প্যারামিটারের মান সমর্থিত অনুদানের ধরণগুলির মধ্যে একটির সাথে মেলে)।

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

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

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

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

This element is used with the password grant type only . With the password grant type, user credentials (password and username) must be made available to the OAuthV2 policy. The <PassWord> and <UserName> elements are used to specify variables where Edge can find these values. If these elements are not specified, the policy expects to find the values (by default) in form parameters named username and password . If the values are not found, the policy throws an error. You can use the <PassWord> and <UserName> elements to reference any flow variable containing the credentials.

For example, you can pass the username in a query parameter and set the <UserName> element like this: <UserName>request.queryparam.username</UserName> . To require the username in an HTTP header, set this value to 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 .

Verifying access tokens

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.

Flow variables

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