پیاده سازی نوع اعطای رمز عبور

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

نوع اعطای رمز عبور مالک منبع (یا "رمز عبور") بیشتر در مواردی استفاده می شود که برنامه بسیار مورد اعتماد است. در این پیکربندی، کاربر اعتبار سرور منبع خود (نام کاربری/رمز عبور) را در اختیار برنامه مشتری قرار می‌دهد، که آنها را در یک درخواست نشانه دسترسی به Apigee Edge ارسال می‌کند. یک سرور هویت اعتبارنامه ها را تأیید می کند، و اگر معتبر باشند، Edge اقدام به برش یک نشانه دسترسی می کند و آن را به برنامه برمی گرداند.

در مورد این موضوع

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

نمونه هایی که ممکن است مفید باشند

  • درخواست دسترسی: نوع اعطای رمز عبور : به شما نشان می دهد که چگونه یک درخواست توکن تشکیل دهید، سیاست OAuthV2 را برای نوع اعطای رمز عبور پیکربندی کنید، و چگونه یک نقطه پایانی را برای خط مشی در Edge پیکربندی کنید.
  • oauth-validate-key-secret : یک نمونه پراکسی در GitHub که می توانید آن را در Edge مستقر کرده و امتحان کنید. این یک مثال سرتاسری است که نوع اعطای رمز عبور را نشان می دهد. این بهترین روش را نشان می دهد، که احراز هویت اعتبار برنامه مشتری (کلید/محرمانه) قبل از ارسال اعتبار کاربر به ارائه دهنده هویت است.

ویدیو

ویدئو: این ویدئو را در مورد اجرای نوع اعطای رمز عبور مشاهده کنید.

موارد استفاده کنید

این نوع کمک هزینه برای برنامه های بسیار قابل اعتماد یا دارای امتیاز در نظر گرفته شده است زیرا کاربر باید اعتبار سرور منبع خود را به برنامه بدهد. به طور معمول، برنامه یک صفحه ورود به سیستم ارائه می دهد که در آن کاربر اعتبار خود را وارد می کند.

نمودار جریان

نمودار جریان زیر جریان نوع اعطای رمز عبور مالک منبع را با Apigee Edge به عنوان سرور مجوز نشان می دهد.

نکته: برای دیدن یک نسخه بزرگتر از این نمودار، روی آن کلیک راست کرده و آن را در یک برگه جدید باز کنید، یا آن را ذخیره کنید و در یک نمایشگر تصویر باز کنید.

مراحل در جریان نوع اعطای رمز عبور

در اینجا خلاصه ای از مراحل مورد نیاز برای اجرای نوع اعطای رمز عبور که در آن Apigee Edge به عنوان سرور مجوز خدمت می کند، آورده شده است.

پیش نیاز: برنامه مشتری باید در Apigee Edge ثبت شده باشد تا شناسه مشتری و کلیدهای مخفی مشتری به دست آید. برای جزئیات به ثبت برنامه های مشتری مراجعه کنید.

1. کاربر جریان را شروع می کند و اعتبارنامه ها را وارد می کند

هنگامی که برنامه نیاز به دسترسی به منابع محافظت شده کاربر دارد (به عنوان مثال، کاربر روی دکمه ای در برنامه کلیک می کند)، کاربر به یک فرم ورود هدایت می شود.

2. برنامه یک رمز دسترسی از Apigee Edge درخواست می کند

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

در اینجا یک نمونه درخواست POST است که شامل پارامترهای مورد نیاز برای این نوع کمک هزینه است:

$ curl -i \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
  -d 'grant_type=password&username=the-user-name&password=the-users-password' \
  https://docs-test.apigee.net/oauth/token

از طرف دیگر، این دستور می تواند به صورت زیر انجام شود، با استفاده از گزینه -u برای ایجاد هدر Basic Authentication با کد base64 برای شما.

$ curl -i \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -u sqH8ooHexTz8C02IX9ORo6rhgq1iSrAl:Z4ljtJdneBOjPMAU \
  -d 'grant_type=password&username=the-user-name&password=the-users-password' \
  https://docs-test.apigee.net/oauth/token

(هر یک از این دستورات باید همه در یک خط باشد.)

اعتبار کاربر در پارامترهای فرم موجود است، در حالی که اعتبار مشتری در هدر احراز هویت اولیه HTTP کدگذاری می شود. برای توضیح دقیق این تماس API، از جمله جزئیات مربوط به سرصفحه تأیید پایه مورد نیاز، به بخش اعطای رمز عبور « درخواست نشانه‌های دسترسی و کدهای مجوز » مراجعه کنید.

3. Edge برنامه مشتری را تأیید می کند

قبل از ارسال نام کاربری و رمز عبور کاربر به ارائه‌دهنده هویت، Edge باید بداند که برنامه مشتری که درخواست را ارائه می‌کند، یک برنامه معتبر و قابل اعتماد است. یکی از راه های انجام این کار استفاده از احراز هویت کلید API در تماس API است. در برخی موارد، ممکن است بخواهید هم کلید مشتری و هم راز را تأیید کنید. یک نمونه پراکسی وجود دارد که این تکنیک جایگزین را در مخزن api-platform-samples در GitHub نشان می دهد.

4. Edge اعتبار ورود را پردازش می کند

پس از تأیید اعتبار برنامه مشتری، می‌توانید از خط‌مشی Callout یا JavaScript برای تماس با سرویس هویت استفاده کنید و اطلاعات کاربری کاربر را ارسال کنید. برای مثال، می‌تواند یک سرویس LDAP یا هر سرویسی باشد که می‌خواهید برای تأیید اعتبار استفاده کنید. برای جزئیات بیشتر درباره این خط‌مشی‌ها، به Extract Variables Policy و JavaScript مراجعه کنید.

اگر سرویس هویت اعتبارنامه ها را تأیید کند و یک پاسخ 200 را برگرداند، Edge به پردازش درخواست ادامه می دهد. در غیر این صورت، Edge پردازش را متوقف می کند و یک خطا را به برنامه مشتری برمی گرداند.

5. سیاست OAuthV2 اجرا می شود

اگر اعتبارنامه ها معتبر هستند، مرحله پردازش بعدی اجرای یک خط مشی OAuthV2 است که برای نوع اعطای رمز عبور پیکربندی شده است. در اینجا یک مثال است. عناصر <UserName> و <PassWord> مورد نیاز هستند، و می توانید آنها را از متغیرهای جریانی که با خط مشی ExtractVariables ذخیره شده اند، بازیابی کنید. برای اطلاعات مرجع دقیق در مورد این خط‌مشی، به سیاست OAuthV2 مراجعه کنید.

<OAuthV2 name="GetAccessToken">
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn>360000000</ExpiresIn> 
  <SupportedGrantTypes> 
     <GrantType>password</GrantType> 
  </SupportedGrantTypes> 
  <GrantType>request.queryparam.grant_type</GrantType> 
  <UserName>login</UserName>
  <PassWord>password</PassWord>
  <GenerateResponse/> 
</OAuthV2>

در صورت موفقیت آمیز بودن این خط مشی، پاسخی حاوی یک نشانه دسترسی به مشتری ایجاد می شود. پاسخ در قالب JSON است. در اینجا یک مثال است. توجه داشته باشید که access_token یکی از عناصر است: 

{
    "issued_at": "1420258685042",
    "scope": "READ",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "refresh_token_issued_at": "1420258685042",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799",
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6",
    "organization_name": "docs",
    "refresh_token_expires_in": "0",
    "refresh_count": "0"
}

6. مشتری با API محافظت شده تماس می گیرد

اکنون، با یک کد دسترسی معتبر، مشتری می تواند با API محافظت شده تماس بگیرد. در این سناریو، درخواست‌ها به Apigee Edge (پراکسی) انجام می‌شود و Edge مسئول اعتبارسنجی نشانه دسترسی قبل از ارسال فراخوانی API به سرور منبع هدف است. توکن های دسترسی در یک هدر Authorization ارسال می شوند. به عنوان مثال: 

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