فعال کردن بازیابی و لغو نشانه‌های دسترسی 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"
}

برای یادگیری نحوه‌ی برقراری تماس‌های API که این بازیابی‌ها و ابطال‌ها را انجام می‌دهند، به Smart Docs زیر مراجعه کنید:

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

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

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

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

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

• لبه برای استقرار ابر خصوصی

  در Apigee Edge برای فضای ابری خصوصی (در محل)، شما کاملاً مسئول پیکربندی هستید. برای اطلاعات بیشتر، به بخش عملیات و پیکربندی مراجعه کنید.

• هیبرید آپیجی

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

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

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

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

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

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

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

شما می‌توانید از فراخوانی Get Permission for a Resource API برای مشاهده‌ی اینکه کدام نقش‌ها مجوزهای get و put را برای منبع oauth2 دارند، استفاده کنید.

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

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

انجام شده توسط پشتیبانی 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
• از یک متغیر جریان که شناسه کاربر نهایی را ارائه می‌دهد استفاده کنید