فعال کردن بازیابی و ابطال ژتون‌های دسترسی OAuth 2.0 براساس شناسه کاربر نهایی، شناسه برنامه، یا هر دو

درحال مشاهده اسناد Apigee Edge هستید.
به اسناد Apigee X بروید. اطلاعات

این بخش نحوه فعال کردن بازیابی و ابطال ژتون‌های دسترسی OAuth 2.0 را براساس شناسه کاربر نهایی، شناسه برنامه، یا هر دو شرح می‌دهد. ویژگی شناسه کاربر نهایی نیازمند راه‌اندازی ویژه است که در این موضوع توضیح داده شده است. منظور ما از کاربر نهایی، کاربر برنامه‌ای است که API را فراخوانی می‌کند.

چه زمانی دسترسی به شناسه کاربر نهایی را فعال کنیم

گاهی اوقات، ذخیره کردن شناسه کاربر در یک کد دسترسی مفید است. ویژگی دسترسی به شناسه کاربر نهایی را فقط درصورتی فعال کنید که مورد استفاده خوبی برای آن داشته باشید. برای مثال:

• ویژگی‌ای برای وب‌سایت یا برنامه شما که در آن کاربران بتوانند ببینند به کدام برنامه‌های شخص ثالث اجازه داده‌اند و گزینه‌ای برای لغو دسترسی به آن برنامه‌ها ارائه دهید.
• ویژگی‌ای که به کاربر مجاز امکان می‌دهد همه نشان‌های دسترسی منسوب به یک «برنامه توسعه‌دهنده» خاص را لغو کند.

درباره کدهای دسترسی OAuth

شناسه‌های برنامه به‌طور خودکار به یک کد دسترسی OAuth اضافه می‌شوند. بنابراین، پس‌از فعال کردن دسترسی به کد برای سازمان همان‌طور که در زیر توضیح داده شده است، می‌توانید کدهای دسترسی را براساس شناسه برنامه باطل کنید.

برای بازیابی و ابطال کردن کدهای دسترسی OAuth 2.0 براساس شناسه کاربر نهایی، شناسه کاربر نهایی باید در کدهای دسترسی وجود داشته باشد. روش زیر نحوه افزودن شناسه کاربر نهایی به رمز موجود را شرح می‌دهد.

به‌طور پیش‌فرض، وقتی Edge یک کد دسترسی OAuth 2.0 تولید می‌کند، کد دارای قالب نشان‌داده‌شده در زیر است:

{
 "issued_at" : "1421847736581",
 "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
 "scope" : "READ",
 "status" : "approved",
 "api_product_list" : "[PremiumWeatherAPI]",
 "expires_in" : "3599", //--in seconds
 "developer.email" : "tesla@weathersample.com",
 "organization_id" : "0",
 "token_type" : "BearerToken",
 "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP",
 "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL",
 "organization_name" : "myorg",
 "refresh_token_expires_in" : "0", //--in seconds
 "refresh_count" : "0"
}

به موارد زیر توجه کنید:

• فیلد application_name حاوی UUID برنامه مرتبط با این رمز است. اگر بازیابی و فسخ کدهای دسترسی OAuth 2.0 را براساس شناسه برنامه فعال کنید، این شناسه برنامه‌ای است که استفاده می‌کنید.
• فیلد access_token حاوی مقدار کد دسترسی OAuth 2.0 است.

هیچ فیلدی برای شناسه کاربر نهایی در کد دسترسی OAuth پیش‌فرض وجود ندارد. برای فعال کردن بازیابی و ابطال ژتون‌های دسترسی OAuth 2.0 براساس شناسه کاربر نهایی، باید خط‌مشی OAuth 2.0 را به‌گونه‌ای پیکربندی کنید که شناسه کاربر را در ژتون بگنجاند، همان‌طور که در رویه زیر توضیح داده شده است. توجه داشته باشید که اگر فقط می‌خواهید کدهای دسترسی OAuth 2.0 را براساس شناسه برنامه بازیابی و لغو کنید، نیازی به فعال کردن دسترسی براساس شناسه کاربر نهایی نیست.

شناسه کاربر نهایی را به نقطه پایانی ایجاد کد می‌فرستید. می‌توانید شناسه کاربر نهایی را به‌عنوان پارامتر پُرسمان، پارامتر فرم، یا در سرایند (همان‌طور که در ادامه این موضوع توضیح داده شده است) ارسال کنید. پس‌از پیکربندی Edge برای افزودن شناسه کاربر نهایی به نشان، این شناسه به‌عنوان فیلد app_enduser اضافه می‌شود، همان‌طور که در زیر نشان داده شده است:

{
 "issued_at" : "1421847736581",
 "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
 "scope" : "READ",
 "app_enduser" : "6ZG094fgnjNf02EK",
 "status" : "approved",
 "api_product_list" : "[PremiumWeatherAPI]",
 "expires_in" : "3599", //--in seconds
 "developer.email" : "tesla@weathersample.com",
 "organization_id" : "0",
 "token_type" : "BearerToken",
 "client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP",
 "access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL",
 "organization_name" : "myorg",
 "refresh_token_expires_in" : "0", //--in seconds
 "refresh_count" : "0"
}

برای آشنایی با نحوه انجام دادن تماس‌های «میانای برنامه‌سازی کاربردی» که این بازیابی‌ها و ابطال‌ها را انجام می‌دهند، «مستندات هوشمند» زیر را ببینید:

• لغو دسترسی OAuth2 کد براساس شناسه کاربر نهایی یا برنامه
• دریافت کد دسترسی OAuth2 با شناسه کاربر نهایی یا برنامه

فعال کردن دسترسی به کدهای OAuth 2.0 با شناسه کاربر و شناسه برنامه

نحوه فعال کردن دسترسی به کدهای OAuth 2.0 براساس شناسه کاربر و شناسه برنامه به نحوه استقرار Edge بستگی دارد:

• استقرار ابری

  استقرار مبتنی بر ابر Edge به این معنی است که بیشتر پیکربندی توسط Apigee انجام می‌شود. شما فقط مسئول پیکربندی خط‌مشی OAuth 2.0 برای افزودن شناسه کاربر به کد دسترسی هستید. برای اطلاعات بیشتر، رویه زیر را ببینید.

• Edge برای استقرار «ابر خصوصی»

  در Apigee Edge for Private Cloud (در محل)، مسئولیت کامل پیکرببندی برعهده شما است. برای اطلاعات بیشتر، عملیات و پیکربندی را ببینید.

• Apigee hybrid

  دسترسی به نشان‌های OAuth 2.0 براساس شناسه کاربر به‌طور پیش‌فرض فعال است. شما فقط مسئول پیکربندی خط‌مشی OAuth 2.0 برای افزودن شناسه کاربر به کد دسترسی هستید. برای اطلاعات بیشتر، «مرحله ۵» از رویه زیر را ببینید.

فعال کردن دسترسی در فضای ابری

مرحله ۱: فعال کردن سازمان برای پشتیبانی از این ویژگی

این ویژگی باید برای هر سازمانی که می‌خواهید از این ویژگی پشتیبانی کند فعال شود.

برای به‌روزرسانی سازمانتان، با پشتیبانی Apigee Edge تماس بگیرید.

مرحله ۲: ارائه «اجازه‌های منبع oauth2» به نقش‌های opsadmin و orgadmin

فقط نقش‌های orgadmin و opsadmin شما باید اجازه‌هایی برای انجام این فراخوانی‌های بازیابی (get) و لغو (put) به منبع oauth2 براساس شناسه کاربر نهایی یا شناسه برنامه داشته باشند.

می‌توانید از فراخوانی میانای برنامه‌سازی کاربردی دریافت اجازه برای منبع استفاده کنید تا ببینید کدام نقش‌ها اجازه‌های get و put برای منبع oauth2 را دارند.

اگر نیاز دارید اجازه‌ای را اضافه یا حذف کنید، با پشتیبانی Apigee Edge تماس بگیرید تا به‌روزرسانی‌ها را انجام دهند.

مرحله ۳: کپی کردن نشان‌های دسترسی OAuth 2.0 موجود در گره‌های Cassandra

انجام‌شده توسط پشتیبانی Apigee: در این کار، نسخه‌هایی از رموز دسترسی OAuth 2.0 موجود در سازمان‌های تحت‌تأثیر کپی و در گره‌های Cassandra شما ذخیره خواهد شد. این رویه روی گره‌های Cassandra برای هریک از غلاف‌های Apigee Edge شما اجرا خواهد شد. این کار به تماس‌های API بازیابی و ابطال اجازه می‌دهد تا دربرابر همه کد‌های دسترسی OAuth 2.0 شما، هم کد‌های موجود و هم کد‌های جدیداً تولیدشده، اجرا شوند.

مرحله ۴: پیکربندی خط‌مشی OAuth 2.0 برای تولید کردن نمودارهای دسترسی که شامل شناسه‌های کاربر نهایی است

خط‌مشی OAuth 2.0 را که برای تولید نمودارهای دسترسی استفاده می‌شود پیکربندی کنید تا شناسه کاربر نهایی را در نمودار بگنجاند. با افزودن شناسه‌های کاربر نهایی به کد دسترسی، می‌توانید واکشی‌ها و لغو‌ها را براساس شناسه کاربر نهایی انجام دهید.

برای پیکربندی خط‌مشی به‌طوری که شناسه کاربر نهایی در کد دسترسی گنجانده شود، باید متغیر ورودی حاوی شناسه کاربر نهایی را مشخص کنید. از برچسب <AppEndUser> برای مشخص کردن متغیر استفاده کنید.

خط‌مشی OAuth 2.0 زیر، با نام GenerateAccessTokenClient، یک نمودار دسترسی OAuth 2.0 تولید می‌کند. به اضافه شدن برچسب <AppEndUser> که پررنگ شده است توجه کنید:

<OAuthV2 async="false" continueOnError="false" enabled="true" name="GenerateAccessTokenClient">
  <DisplayName>OAuth 2.0.0 1</DisplayName>
  <ExternalAuthorization>false</ExternalAuthorization>
  <Operation>GenerateAccessToken</Operation>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GenerateResponse enabled="true"/>
  <GrantType>request.queryparam.grant_type</GrantType>
  <AppEndUser>request.header.appuserID</AppEndUser>
  <ExpiresIn>960000</ExpiresIn>
</OAuthV2>

سپس می‌توانید از فرمان cURL زیر برای تولید کردن کد دسترسی OAuth 2.0 استفاده کنید و شناسه کاربر را به‌عنوان سرایند appuserID عبور دهید:

curl -H "appuserID:6ZG094fgnjNf02EK" /
  https://myorg-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials /
  -X POST /
  -d 'client_id=k3nJyFJIA3p62TKIkLO6OJNi87GYXFmP&client_secret=gk58jK5lIp943AY4'

در این مثال، appuserID به‌عنوان سرایند درخواست ارسال می‌شود. می‌توانید اطلاعات را به روش‌های مختلف به‌عنوان بخشی از درخواست ارسال کنید. برای مثال، به‌عنوان جایگزین، می‌توانید:

• از متغیر پارامتر فرم استفاده کنید: request.formparam.appuserID
• از متغیر جریانی که شناسه کاربر نهایی را ارائه می‌دهد استفاده کنید