OAuthV2 নীতি

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

কি

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

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

নমুনা

AccessToken যাচাই করুন

AccessToken যাচাই করুন

এই OAuthV2 নীতি কনফিগারেশন (VerifyAccessToken অপারেশন সহ) যাচাই করে যে Apigee 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

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

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

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

প্রতিটি সমর্থিত অনুদান প্রকারের জন্য কীভাবে অ্যাক্সেস টোকেনগুলির জন্য অনুরোধ করা যায় তা দেখানো উদাহরণগুলির জন্য, অ্যাক্সেস টোকেন এবং অনুমোদনের কোডগুলির অনুরোধ করা দেখুন৷ বিষয়ের মধ্যে এই অপারেশনগুলির উদাহরণ রয়েছে:

অথরাইজেশন কোড তৈরি করুন

অনুমোদন কোড তৈরি করুন

অনুমোদন কোডের অনুরোধ কিভাবে দেখাতে হয় তার উদাহরণের জন্য, একটি অনুমোদন কোড অনুরোধ করা দেখুন।

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

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

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

প্রতিক্রিয়া প্রবাহ টোকেন

প্রতিক্রিয়া প্রবাহে একটি অ্যাক্সেস টোকেন তৈরি করুন

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

প্রথমে, আসুন নমুনা নীতিটি দেখি:

<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 অননুমোদিত ত্রুটির সাথে ব্যর্থ হবে যদিও নীতিতে সঠিক লগইন পরামিতিগুলি নির্দিষ্ট করা আছে৷ এই সমস্যা সমাধানের জন্য, আপনাকে একটি অনুমোদন অনুরোধ শিরোনাম সেট করতে হবে।

অনুমোদন শিরোনামে অবশ্যই বেস64-এনকোডেড ক্লায়েন্ট_আইডি:ক্লায়েন্ট_সিক্রেট সহ একটি মৌলিক অ্যাক্সেস স্কিম থাকতে হবে।

আপনি OAuthV2 নীতির ঠিক আগে জাভাস্ক্রিপ্ট নীতির সাথে এই শিরোনামটি যোগ করতে পারেন, যেমন। "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 নীতির উপাদান এবং বৈশিষ্ট্য বর্ণনা করে।

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

উপস্থিতি ঐচ্ছিক
টাইপ স্ট্রিং

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

ডিফল্ট:

N/A

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
অপারেশনের সাথে ব্যবহার করা হয়:
  • AccessToken যাচাই করুন

<AccessTokenPrefix> উপাদান

<AccessTokenPrefix>Bearer</AccessTokenPrefix>

ডিফল্টরূপে, VerifyAccessToken প্রত্যাশা করে যে অ্যাক্সেস টোকেনটি একটি অনুমোদন শিরোনামে একটি বহনকারী টোকেন হিসাবে পাঠানো হবে। যেমন:

-H "Authorization: Bearer Rft3dqrs56Blirls56a"

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

ডিফল্ট:

বহনকারী

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান:

বহনকারী

অপারেশনের সাথে ব্যবহার করা হয়:
  • AccessToken যাচাই করুন

<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 অ্যাক্সেস টোকেনগুলির পুনরুদ্ধার এবং প্রত্যাহার সক্ষম করুন দেখুন৷

ডিফল্ট:

N/A

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান:

রানটাইমে নীতিতে অ্যাক্সেসযোগ্য যেকোনো ফ্লো ভেরিয়েবল।

অনুদান প্রকারের সাথে ব্যবহৃত:
  • অনুমোদন_কোড
  • অন্তর্নিহিত
  • পাসওয়ার্ড
  • ক্লায়েন্ট_প্রমাণপত্র

<অ্যাট্রিবিউটস/অ্যাট্রিবিউট>

<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 উপাদানটিকে সত্যে সেট করেন, টোকেনের সম্পূর্ণ JSON উপস্থাপনা প্রতিক্রিয়াতে ফেরত দেওয়া হয়, আপনার সেট করা যেকোনো কাস্টম বৈশিষ্ট্য সহ। কিছু ক্ষেত্রে, আপনি প্রতিক্রিয়াতে আপনার কিছু বা সমস্ত কাস্টম বৈশিষ্ট্য লুকিয়ে রাখতে চাইতে পারেন যাতে সেগুলি ক্লায়েন্ট অ্যাপগুলিতে দৃশ্যমান না হয়।

ডিফল্টরূপে, কাস্টম বৈশিষ্ট্য প্রতিক্রিয়ায় উপস্থিত হয়। আপনি যদি সেগুলি লুকিয়ে রাখতে চান, আপনি প্রদর্শনের প্যারামিটারটিকে মিথ্যাতে সেট করতে পারেন। যেমন:

<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 নীতি ব্যবহার করে আসল অ্যাক্সেস টোকেন থেকে আসল কাস্টম মানগুলি পুনরুদ্ধার করতে হতে পারে।
  • একটি পোস্টপ্রসেসিং জাভাস্ক্রিপ্ট নীতি ব্যবহার করুন ম্যানুয়ালি কোনো কাস্টম বৈশিষ্ট্য যা আপনি প্রতিক্রিয়া দেখতে চান না বের করতে.

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

ডিফল্ট:

N/A

উপস্থিতি:

ঐচ্ছিক

বৈধ মান:
  • name - বৈশিষ্ট্যের নাম
  • ref - বৈশিষ্ট্যের মান। একটি প্রবাহ পরিবর্তনশীল থেকে আসতে পারে.
  • display - (ঐচ্ছিক) প্রতিক্রিয়াতে কাস্টম বৈশিষ্ট্যগুলি উপস্থিত হবে কিনা তা আপনাকে নির্দিষ্ট করতে দেয়৷ true হলে, কাস্টম বৈশিষ্ট্যগুলি প্রতিক্রিয়াতে উপস্থিত হয় (যদি GenerateResponse সক্রিয় থাকে)। false হলে, কাস্টম বৈশিষ্ট্যগুলি প্রতিক্রিয়াতে অন্তর্ভুক্ত করা হয় না। ডিফল্ট মান trueপ্রতিক্রিয়াতে কাস্টম বৈশিষ্ট্যগুলি প্রদর্শন করা বা লুকানো দেখুন।
অনুদান প্রকারের সাথে ব্যবহৃত:
  • অনুমোদন_কোড
  • অন্তর্নিহিত
  • পাসওয়ার্ড
  • ক্লায়েন্ট_প্রমাণপত্র
  • refresh_token
  • GenerateAuthorizationCode অপারেশনের সাথেও ব্যবহার করা যেতে পারে।

<ClientId> উপাদান

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

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

ডিফল্ট:

request.formparam.client_id (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে)

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান: প্রবাহ পরিবর্তনশীল: request.formparam.client_id
অনুদান প্রকারের সাথে ব্যবহৃত:
  • অনুমোদন_কোড
  • পাসওয়ার্ড
  • অন্তর্নিহিত
  • ক্লায়েন্ট_প্রমাণপত্র

GenerateAuthorizationCode অপারেশনের সাথেও ব্যবহার করা যেতে পারে।

<কোড> উপাদান

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

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

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

ডিফল্ট:

request.formparam.code (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে)

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান: রানটাইমে নীতিতে অ্যাক্সেসযোগ্য যেকোনো ফ্লো ভেরিয়েবল
অনুদান প্রকারের সাথে ব্যবহৃত: অনুমোদন_কোড

<ExpiresIn> উপাদান

<ExpiresIn>10000</ExpiresIn> 

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

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

পাবলিক ক্লাউডের জন্য Apigee Edge- এর সাথে, 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. নিশ্চিত করুন যে বৈশিষ্ট্য ফাইলটি "apigee" ব্যবহারকারীর মালিকানাধীন:
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. মেসেজ প্রসেসর রিস্টার্ট করুন।
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

ডিফল্ট:

নির্দিষ্ট করা না থাকলে, সিস্টেমটি সিস্টেম স্তরে কনফিগার করা একটি ডিফল্ট মান প্রয়োগ করে।

উপস্থিতি:

ঐচ্ছিক

প্রকার: পূর্ণসংখ্যা
বৈধ মান:
অনুদান প্রকারের সাথে ব্যবহৃত:
  • অনুমোদন_কোড
  • অন্তর্নিহিত
  • পাসওয়ার্ড
  • ক্লায়েন্ট_প্রমাণপত্র
  • refresh_token

এছাড়াও GenerateAuthorizationCode অপারেশনের সাথে ব্যবহৃত হয়।

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

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

ডিফল্ট:

মিথ্যা

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান: সত্য বা মিথ্যা
অনুদান প্রকারের সাথে ব্যবহৃত:
  • অন্তর্নিহিত
  • পাসওয়ার্ড
  • ক্লায়েন্ট_প্রমাণপত্র
  • refresh_token
  • এছাড়াও GenerateAuthorizationCode অপারেশনের সাথে ব্যবহার করা যেতে পারে।

<GenerateErrorResponse> উপাদান

<GenerateErrorResponse enabled='true'/>

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

ডিফল্ট:

মিথ্যা

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান: সত্য বা মিথ্যা
অনুদান প্রকারের সাথে ব্যবহৃত:
  • অন্তর্নিহিত
  • পাসওয়ার্ড
  • ক্লায়েন্ট_প্রমাণপত্র
  • refresh_token
  • এছাড়াও GenerateAuthorizationCode অপারেশনের সাথে ব্যবহার করা যেতে পারে।

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

<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 (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে)

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান: একটি পরিবর্তনশীল, যেমন উপরে ব্যাখ্যা করা হয়েছে।
অনুদান প্রকারের সাথে ব্যবহৃত:
  • অনুমোদন_কোড
  • পাসওয়ার্ড
  • অন্তর্নিহিত
  • ক্লায়েন্ট_প্রমাণপত্র
  • refresh_token

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

<Operation>GenerateAuthorizationCode</Operation>

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

ডিফল্ট:

যদি <Operation> নির্দিষ্ট করা না থাকে, এজ <SupportedGrantTypes> এর তালিকা দেখে। শুধুমাত্র এই অনুদান ধরনের অপারেশন সফল হবে. অন্য কথায়, আপনি <Operation> বাদ দিতে পারেন যদি আপনি <SupportedGrantTypes> তালিকায় একটি <GrantType> উল্লেখ করেন। যদি <Operation> বা <SupportedGrantTypes> কোনটিই নির্দিষ্ট করা না থাকে, তাহলে ডিফল্ট অনুদানের ধরন হল authorization_code। অর্থাৎ, authorization_code অনুদান টাইপ অনুরোধ সফল হবে, কিন্তু অন্য সব ব্যর্থ হবে.

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান:

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

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

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

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

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

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

ডিফল্ট:

request.formparam.password (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে)

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান: রানটাইমে নীতিতে উপলব্ধ যেকোন প্রবাহ পরিবর্তনশীল।
অনুদান প্রকারের সাথে ব্যবহৃত: পাসওয়ার্ড

<RedirectUri> উপাদান

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

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

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

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

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

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

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

ডিফল্ট:

request.formparam.redirect_uri (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে)

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান: রানটাইমে নীতিতে অ্যাক্সেসযোগ্য যেকোন প্রবাহ পরিবর্তনশীল
অনুদান প্রকারের সাথে ব্যবহৃত:
  • অনুমোদন_কোড
  • অন্তর্নিহিত

GenerateAuthorizationCode অপারেশনের সাথেও ব্যবহৃত হয়।

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

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

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

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

ডিফল্ট:

request.formparam.refresh_token (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে)

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান: রানটাইমে নীতিতে অ্যাক্সেসযোগ্য যেকোন প্রবাহ পরিবর্তনশীল
অনুদান প্রকারের সাথে ব্যবহৃত:
  • 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. নিশ্চিত করুন যে বৈশিষ্ট্য ফাইলটি "apigee" ব্যবহারকারীর মালিকানাধীন:
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. মেসেজ প্রসেসর রিস্টার্ট করুন।
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

ডিফল্ট:

63072000000 ms (2 বছর) (কার্যকর 05 আগস্ট, 2024)

উপস্থিতি:

ঐচ্ছিক

প্রকার: পূর্ণসংখ্যা
বৈধ মান:
অনুদান প্রকারের সাথে ব্যবহৃত:
  • অনুমোদন_কোড
  • পাসওয়ার্ড
  • refresh_token

<ResponseType> উপাদান

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

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

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

ডিফল্ট:

request.formparam.response_type (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে)

উপস্থিতি:

ঐচ্ছিক। আপনি যদি ডিফল্ট আচরণ ওভাররাইড করতে চান তাহলে এই উপাদানটি ব্যবহার করুন।

প্রকার: স্ট্রিং
বৈধ মান: হয় code (অনুমোদন কোড অনুদান প্রকারের জন্য) বা token (অন্তর্ভুক্ত অনুদান প্রকারের জন্য)
অনুদান প্রকারের সাথে ব্যবহৃত:
  • অন্তর্নিহিত
  • GenerateAuthorizationCode অপারেশনের সাথেও ব্যবহৃত হয়।

<ReuseRefreshToken> উপাদান

<ReuseRefreshToken>true</ReuseRefreshToken>

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

ডিফল্ট:

false

উপস্থিতি:

ঐচ্ছিক

প্রকার: বুলিয়ান
বৈধ মান:

true বা false

অনুদান প্রকারের সাথে ব্যবহৃত:
  • refresh_token

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

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

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

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

<Scope>A B</Scope>

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

ডিফল্ট:

সুযোগ নেই

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান:

যদি জেনারেট* নীতির সাথে ব্যবহার করা হয়, একটি প্রবাহ পরিবর্তনশীল।

যদি VerifyAccessToken এর সাথে ব্যবহার করা হয়, তাহলে স্কোপের নামের (স্ট্রিং) একটি স্থান-বিচ্ছিন্ন তালিকা।

অনুদান প্রকারের সাথে ব্যবহৃত:
  • অনুমোদন_কোড
  • অন্তর্নিহিত
  • পাসওয়ার্ড
  • ক্লায়েন্ট_প্রমাণপত্র
  • GenerateAuthorizationCode এবং VerifyAccessToken অপারেশনের সাথেও ব্যবহার করা যেতে পারে।

<State> উপাদান

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

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

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

ডিফল্ট:

রাষ্ট্র নেই

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান: রানটাইমে নীতিতে অ্যাক্সেসযোগ্য যেকোনো ফ্লো ভেরিয়েবল
অনুদান প্রকারের সাথে ব্যবহৃত:
  • সব
  • GenerateAuthorizationCode অপারেশনের সাথেও ব্যবহার করা যেতে পারে

<StoreToken> উপাদান

 <StoreToken>true</StoreToken> 

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

ডিফল্ট:

মিথ্যা

উপস্থিতি:

ঐচ্ছিক

প্রকার: বুলিয়ান
বৈধ মান: সত্য বা মিথ্যা
অনুদান প্রকারের সাথে ব্যবহৃত:
  • অনুমোদন_কোড
  • পাসওয়ার্ড
  • ক্লায়েন্ট_প্রমাণপত্র

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

<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 প্যারামিটারের সন্ধান করবে যা একটি ক্লায়েন্ট অনুরোধে পাস করা হয়। এজ নিশ্চিত করবে যে grant_type প্যারামিটারের মান একটির সাথে মিলে যায়। সমর্থিত অনুদান প্রকার)।

ডিফল্ট:

অনুমোদন _কোড এবং অন্তর্নিহিত

উপস্থিতি:

প্রয়োজন

প্রকার: স্ট্রিং
বৈধ মান:
  • ক্লায়েন্ট_প্রমাণপত্র
  • অনুমোদন_কোড
  • পাসওয়ার্ড
  • অন্তর্নিহিত

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

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

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

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

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

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

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

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

ডিফল্ট:

request.formparam.username (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে)

উপস্থিতি:

ঐচ্ছিক

প্রকার: স্ট্রিং
বৈধ মান: যেকোনো পরিবর্তনশীল সেটিং।
অনুদান প্রকারের সাথে ব্যবহৃত: পাসওয়ার্ড

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

একবার একটি এপিআই প্রক্সি জন্য একটি টোকেন এন্ডপয়েন্ট সেট আপ করা হলে, একটি সংশ্লিষ্ট OAUTHV2 নীতি যা VerifyAccessToken অপারেশনটি নির্দিষ্ট করে যা সুরক্ষিত সংস্থানটি প্রকাশ করে এমন প্রবাহের সাথে সংযুক্ত থাকে।

উদাহরণস্বরূপ, কোনও এপিআই -তে সমস্ত অনুরোধ অনুমোদিত তা নিশ্চিত করার জন্য, নিম্নলিখিত নীতিটি অ্যাক্সেস টোকেন যাচাইকরণ প্রয়োগ করে:

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

নীতিটি সুরক্ষিত হওয়ার জন্য এপিআই রিসোর্সের সাথে সংযুক্ত রয়েছে। কোনও এপিআই -তে সমস্ত অনুরোধ যাচাই করা হয়েছে তা নিশ্চিত করার জন্য, প্রক্সিেন্ডপয়েন্টের অনুরোধ প্রিফ্লোতে নীতিটি সংযুক্ত করুন, নিম্নরূপ:

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

নিম্নলিখিত al চ্ছিক উপাদানগুলি যাচাইকরণ টোকেন অপারেশনের জন্য ডিফল্ট সেটিংসকে ওভাররাইড করতে ব্যবহার করা যেতে পারে।

নাম বর্ণনা
ব্যাপ্তি

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

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

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

অনুরোধ পরিবর্তনশীল অবস্থান নির্দিষ্ট করে

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

নীচের উদাহরণটি দেখায় যে আপনি কীভাবে প্রয়োজনীয় অনুমোদনের কোড পরামিতিগুলির অবস্থানটি এইচটিটিপি শিরোনাম হিসাবে নির্দিষ্ট করতে পারেন:

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

যাচাই -অ্যাক্সেস টোকেন অপারেশন

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

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

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

(কেবলমাত্র এপিগি হাইব্রিড) কেন অ্যাক্সেস টোকেন বাতিল করা হয় তা নির্দেশ করে।

মান প্রত্যাহার করা 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} নিবন্ধিত ক্লায়েন্ট অ্যাপের একটি নামযুক্ত কাস্টম বৈশিষ্ট্য।

বিকাশকারী-নির্দিষ্ট ভেরিয়েবল

যদি অ্যাপ.এপ টাইপটি "সংস্থা" হয়, তবে সংস্থার বৈশিষ্ট্যগুলি পপুলেটেড হয় এবং যদি অ্যাপ্লিকেশন.এপ টাইপ "বিকাশকারী" হয় তবে বিকাশকারী বৈশিষ্ট্যগুলি পপুলেটেড হয়।

ভেরিয়েবল বর্ণনা
বিকাশকারী-নির্দিষ্ট ভেরিয়েবল
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} সংস্থার একটি নামী কাস্টম বৈশিষ্ট্য।

জেনারেটঅ্যান্ডোরাইজেশনকোড অপারেশন

জেনারেট আন্টিওহোরাইজেশনকোড অপারেশন সফলভাবে সম্পাদন করার সময় এই ভেরিয়েবলগুলি সেট করা হয়:

উপসর্গ: oauthv2authcode.{policy_name}.{variable_name}

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

পরিবর্তনশীল বর্ণনা
code নীতি কার্যকর করার সময় অনুমোদনের কোড উত্পন্ন হয়।
redirect_uri নিবন্ধিত ক্লায়েন্ট অ্যাপের সাথে যুক্ত পুনঃনির্দেশ ইউআরআই।
scope ক্লায়েন্টের অনুরোধে al চ্ছিক OAuth সুযোগ পাস হয়েছে।
client_id ক্লায়েন্ট আইডি ক্লায়েন্টের অনুরোধে পাস করেছে।

জেনারেটএসেসটোকেন এবং রিফ্রেশঅ্যাকসেস টোকেন অপারেশন

জেনারেটএকসেসটোকেন এবং রিফ্রেশঅ্যাকসেসটোকেন অপারেশনগুলি সফলভাবে সম্পাদন করার সময় এই ভেরিয়েবলগুলি সেট করা হয়। নোট করুন যে রিফ্রেশ টোকেন ভেরিয়েবলগুলি ক্লায়েন্টের শংসাপত্রগুলি অনুদান ধরণের প্রবাহের জন্য প্রযোজ্য নয়।

উপসর্গ: oauthv2accesstoken.{policy_name}.{variable_name}

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

পরিবর্তনশীল নাম বর্ণনা
access_token অ্যাক্সেস টোকেন যা উত্পন্ন হয়েছিল।
client_id এই টোকেনের সাথে যুক্ত বিকাশকারী অ্যাপের ক্লায়েন্ট আইডি।
expires_in টোকেনের জন্য মেয়াদোত্তীর্ণ মান। বিশদের জন্য <এক্সপায়ারসিন> উপাদানটি দেখুন। নোট করুন যে প্রতিক্রিয়াতে, মেয়াদোত্তীর্ণ_ইন কয়েক সেকেন্ডে প্রকাশ করা হয়।
scope টোকেনের জন্য কনফিগার করা স্কোপগুলির তালিকা। OAuth2 স্কোপগুলির সাথে কাজ করা দেখুন।
status হয় approved বা revoked
token_type BearerToken সেট করা হয়।
developer.email টোকেনের সাথে সম্পর্কিত বিকাশকারী অ্যাপের মালিক নিবন্ধিত বিকাশকারীর ইমেল ঠিকানা।
organization_name Org যেখানে প্রক্সি কার্যকর করে।
api_product_list টোকেনের সংশ্লিষ্ট বিকাশকারী অ্যাপের সাথে যুক্ত পণ্যগুলির একটি তালিকা।
refresh_count
refresh_token রিফ্রেশ টোকেন যা উত্পন্ন হয়েছিল। নোট করুন যে ক্লায়েন্টের শংসাপত্র অনুদানের ধরণের জন্য রিফ্রেশ টোকেনগুলি উত্পন্ন হয় না।
refresh_token_expires_in রিফ্রেশ টোকেনের জীবনকাল, সেকেন্ডে।
refresh_token_issued_at এই সময়ের মান হ'ল সংশ্লিষ্ট 32-বিট টাইমস্ট্যাম্প পরিমাণের স্ট্রিং উপস্থাপনা। উদাহরণস্বরূপ, 'বুধ, 21 আগস্ট 2013 19:16:47 ইউটিসি' 1377112607413 এর টাইমস্ট্যাম্প মানের সাথে মিলে যায়।
refresh_token_status হয় approved বা revoked

জেনারেটএসেসেসটোকেনআইএমপিএলসিটিগ্র্যান্ট

এই ভেরিয়েবলগুলি সেট করা হয় যখন জেনারেটএসেসেসটোকনিমপ্লিকিটি অপারেশন অন্তর্নিহিত অনুদান প্রকার প্রবাহের জন্য সফলভাবে সম্পাদন করে।

উপসর্গ: oauthv2accesstoken.{policy_name}.{variable_name}

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

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

ত্রুটি উল্লেখ

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Fault code HTTP status Cause Thrown by operations
steps.oauth.v2.access_token_expired 401 The access token is expired.

VerifyAccessToken
InvalidateToken

steps.oauth.v2.access_token_not_approved 401 The access token was revoked. VerifyAccessToken
steps.oauth.v2.apiresource_doesnot_exist 401 The requested resource does not exist any of the API products associated with the access token. VerifyAccessToken
steps.oauth.v2.FailedToResolveAccessToken 500 The policy expected to find an access token in a variable specified in the <AccessToken> element, but the variable could not be resolved. GenerateAccessToken
steps.oauth.v2.FailedToResolveAuthorizationCode 500 The policy expected to find an authorization code in a variable specified in the <Code> element, but the variable could not be resolved. GenerateAuthorizationCode
steps.oauth.v2.FailedToResolveClientId 500 The policy expected to find the Client ID in a variable specified in the <ClientId> element, but the variable could not be resolved. GenerateAccessToken
GenerateAuthorizationCode
GenerateAccessTokenImplicitGrant
RefreshAccessToken
steps.oauth.v2.FailedToResolveRefreshToken 500 The policy expected to find a refresh token in a variable specified in the <RefreshToken> element, but the variable could not be resolved. RefreshAccessToken
steps.oauth.v2.FailedToResolveToken 500 The policy expected to find a token in a variable specified in the <Tokens> element, but the variable could not be resolved.

ValidateToken
InvalidateToken

steps.oauth.v2.InsufficientScope 403 The access token presented in the request has a scope that does not match the scope specified in the verify access token policy. To learn about scope, see Working with OAuth2 scopes. VerifyAccessToken
steps.oauth.v2.invalid_access_token 401 The access token sent from the client is invalid. VerifyAccessToken
steps.oauth.v2.invalid_client 401

This error name is returned when the <GenerateResponse> property of the policy is set to true and the client ID sent in the request is invalid. Check to be sure you are using the correct client key and secret values for the Developer App associated with your proxy. Typically, these values are sent as a Base64 encoded Basic Authorization header.

Note: It is recommended that you change existing fault rule conditions to catch both the invalid_client and InvalidClientIdentifier names. See the 16.09.21 Release Notes for more information and an example.

GenerateAccessToken
RefreshAccessToken
steps.oauth.v2.InvalidRequest 400 This error name is used for multiple different kinds of errors, typically for missing or incorrect parameters sent in the request. If <GenerateResponse> is set to false, use fault variables (described below) to retrieve details about the error, such as the fault name and cause. GenerateAccessToken
GenerateAuthorizationCode
GenerateAccessTokenImplicitGrant
RefreshAccessToken
steps.oauth.v2.InvalidAccessToken 401 The authorization header does not have the word "Bearer", which is required. For example: Authorization: Bearer your_access_token VerifyAccessToken
steps.oauth.v2.InvalidAPICallAsNoApiProductMatchFound 401

The API proxy is not in the Product associated with the access token.

Tips: Be sure that the product associated with the access token is configured correctly. For example, if you use wildcards in resource paths, be sure the wildcards are being used correctly. See Create API products for details.

See also this Apigee Community post for more guidance on causes for this error.

VerifyAccessToken
steps.oauth.v2.InvalidClientIdentifier 500

This error name is returned when the <GenerateResponse> property of the policy is set to false and the client ID sent in the request is invalid. Check to be sure you are using the correct client key and secret values for the Developer App associated with your proxy. Typically, these values are sent as a Base64 encoded Basic Authorization header.

Note: In this situation, this error used to be called invalid_client. It is recommended that you change existing fault rule conditions to catch both the invalid_client and InvalidClientIdentifier names. See the 16.09.21 Release Notes for more information and an example.

GenerateAccessToken
RefreshAccessToken

steps.oauth.v2.InvalidParameter 500 The policy must specify either an access token or an authorization code, but not both. GenerateAuthorizationCode
GenerateAccessTokenImplicitGrant
steps.oauth.v2.InvalidTokenType 500 The <Tokens>/<Token> element requires you to specify the token type (for example, refreshtoken). If the client passes the wrong type, this error is thrown. ValidateToken
InvalidateToken
steps.oauth.v2.MissingParameter 500 The response type is token, but no grant types are specified. GenerateAuthorizationCode
GenerateAccessTokenImplicitGrant
steps.oauth.v2.UnSupportedGrantType 500

The client specified a grant type that is unsupported by the policy (not listed in the <SupportedGrantTypes> element).

Note: There is currently a bug where unsupported grant type errors are not thrown correctly. If an unsupported grant type error occurs, the proxy does not enter the Error Flow, as expected.

GenerateAccessToken
GenerateAuthorizationCode
GenerateAccessTokenImplicitGrant
RefreshAccessToken

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Error name Cause
InvalidValueForExpiresIn

For the <ExpiresIn> element, valid values are positive integers and -1.

InvalidValueForRefreshTokenExpiresIn For the <RefreshTokenExpiresIn> element, valid values are positive integers and -1.
InvalidGrantType An invalid grant type is specified in the <SupportedGrantTypes> element. See the policy reference for a list of valid types.
ExpiresInNotApplicableForOperation Be sure that the operations specified in the <Operations> element support expiration. For example, the VerifyToken operation does not.
RefreshTokenExpiresInNotApplicableForOperation Be sure that the operations specified in the <Operations> element support refresh token expiration. For example, the VerifyToken operation does not.
GrantTypesNotApplicableForOperation Be sure that the grant types specified in <SupportedGrantTypes> are supported for the specified operation.
OperationRequired

You must specify an operation in this policy using the <Operation> element.

Note: If the <Operation> element is missing, the UI throws a schema validation error.

InvalidOperation

You must specify a valid operation in this policy using the <Operation> element.

Note: If the <Operation> element is invalid, the UI throws a schema validation error.

TokenValueRequired You must specify a token <Token> value in the <Tokens> element.

Fault variables

These variables are set when this policy triggers an error at runtime.

Variables Where Example
fault.name="fault_name" fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code. fault.name = "InvalidRequest"
oauthV2.policy_name.failed policy_name is the user-specified name of the policy that threw the fault. oauthV2.GenerateAccesstoken.failed = true
oauthV2.policy_name.fault.name policy_name is the user-specified name of the policy that threw the fault. oauthV2.GenerateAccesstoken.fault.name = InvalidRequest

Note: For the VerifyAccessToken operation, the fault name includes this suffix: keymanagement.service
For example: keymanagement.service.invalid_access_token

oauthV2.policy_name.fault.cause policy_name is the user-specified name of the policy that threw the fault. oauthV2.GenerateAccesstoken.cause = Required param : grant_type

Example error response

These responses are sent back to the client if the <GenerateResponse> element is true.

If <GenerateResponse> is true, the policy returns errors in this format for operations that generate tokens and codes. For a complete list, see see OAuth HTTP error response reference.

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

If <GenerateResponse> is true, the policy returns errors in this format for verify and validate operations. For a complete list, see see OAuth HTTP error response reference.

{  
   {  
      "fault":{  
         "faultstring":"Invalid Access Token",
         "detail":{  
            "errorcode":"keymanagement.service.invalid_access_token"
         }
      }
   }

Example fault rule

<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 কনফিগারেশন নিয়ে কাজ করা

অ্যাপিগি প্রান্তে প্রতিটি সংস্থা (এমনকি একটি নিখরচায় ট্রায়াল অর্গ) একটি OAuth টোকেন এন্ডপয়েন্টের সাথে বিধান করা হয়। শেষ পয়েন্টটি এপিআই প্রক্সিতে ওআউথ নামক নীতিগুলির সাথে পূর্বনির্ধারিত। আপনি অ্যাপিগি প্রান্তে একটি অ্যাকাউন্ট তৈরি করার সাথে সাথে আপনি টোকেন এন্ডপয়েন্টটি ব্যবহার শুরু করতে পারেন। বিশদগুলির জন্য, ওআউথ এন্ডপয়েন্টগুলি বোঝার দেখুন।

অ্যাক্সেস টোকেন শুদ্ধ করা

ডিফল্টরূপে, OAuth2 টোকেনগুলি এপিগি এজ সিস্টেম থেকে 3 দিন (259200 সেকেন্ড) থেকে শুদ্ধ হয় তবে অ্যাক্সেস টোকেন এবং রিফ্রেশ টোকেন (যদি এটি উপস্থিত থাকে) উভয়ই মেয়াদোত্তীর্ণ হওয়ার পরে। কিছু ক্ষেত্রে, আপনি এই ডিফল্টটি পরিবর্তন করতে চাইতে পারেন। উদাহরণস্বরূপ, আপনি যদি বিপুল সংখ্যক টোকেন উত্পন্ন হয় তবে আপনি ডিস্কের স্থান সংরক্ষণের জন্য শুদ্ধ সময়টি সংক্ষিপ্ত করতে চাইতে পারেন।

আপনি যদি ব্যক্তিগত মেঘের জন্য প্রান্তে থাকেন তবে আপনি এই বিভাগে বর্ণিত হিসাবে সংস্থার বৈশিষ্ট্যগুলি সেট করে এই ডিফল্টটি পরিবর্তন করতে পারেন। (মেয়াদোত্তীর্ণ টোকেনের 3 দিনের শুদ্ধতা প্রাইভেট ক্লাউড সংস্করণ 4.19.01 এবং তার পরে প্রান্তে প্রযোজ্য। পূর্ববর্তী সংস্করণগুলির জন্য, ডিফল্ট শুদ্ধ ব্যবধান 180 দিন হয়))

এজ প্রাইভেট ক্লাউড 4.16.01 এবং পরবর্তী সংস্করণগুলির জন্য পিউর সেটিংস আপডেট করা হচ্ছে

দ্রষ্টব্য: এই সেটিংস প্রয়োগের পরে উত্পন্ন টোকেনগুলি প্রভাবিত হয়; সেটিংস আগে উত্পন্ন টোকেনগুলিতে প্রযোজ্য নয়।

এজ প্রাইভেট ক্লাউড 4.15.07 এর জন্য শুদ্ধ সেটিংস আপডেট করা হচ্ছে

দ্রষ্টব্য: এই সেটিংস প্রয়োগের পরে উত্পন্ন টোকেনগুলি প্রভাবিত হয়; সেটিংস আগে উত্পন্ন টোকেনগুলিতে প্রযোজ্য নয়।

নন-আরএফসি-অনুগত আচরণ

OAUTHV2 নীতিটি একটি টোকেন প্রতিক্রিয়া প্রদান করে যাতে নির্দিষ্ট অ- আরএফসি-অনুগত বৈশিষ্ট্য রয়েছে। নিম্নলিখিত টেবিলটি OAUTHV2 নীতি এবং সংশ্লিষ্ট মেনে চলার বৈশিষ্ট্য দ্বারা ফিরে আসা অ-কমপ্লায়েন্ট বৈশিষ্ট্যগুলি দেখায়।

Oauthv2 রিটার্ন: আরএফসি-অনুগত সম্পত্তি হ'ল:
"token_type":"BearerToken" "token_type":"Bearer"
"expires_in":"3600" "expires_in":3600

(অনুগত মানটি একটি সংখ্যা, স্ট্রিং নয়))

এছাড়াও, যখন grant_type = refresh_token হয় তখন মেয়াদোত্তীর্ণ রিফ্রেশ টোকেনের জন্য ত্রুটি প্রতিক্রিয়া:

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

তবে, আরএফসি-অনুগত প্রতিক্রিয়া হ'ল:

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

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