پیاده‌سازی نوع اعطای گذرواژه

درحال مشاهده اسناد 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 ثبت شده باشد تا کلیدهای رمز کارخواه و شناسه کارخواه را دریافت کند. برای جزئیات بیشتر، ثبت برنامه‌های کارخواه را ببینید.

۱. کاربر جریان را آغاز می‌کند و اطلاعات اعتباری را وارد می‌کند

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

۲. برنامه از 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 برای curl استفاده کنید تا سرصفحه «اصالت‌سنجی پایه» با کدبندی 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، ازجمله جزئیات مربوط به سرایند «احراز هویت پایه» الزامی، بخش اعطای گذرواژه در «درخواست کدهای مجوز و رمزهای دسترسی» را ببینید.

۳. ‫Edge برنامه کارخواه را اعتبارسنجی می‌کند

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

۴. ‫Edge اعتبارنامه ورود به سیستم را پردازش می‌کند

پس‌از اینکه برنامه مشتری اعتبارسنجی شد، می‌توانید از خط‌مشی «خدمات پیامک» یا JavaScript برای فراخوانی سرویس هویت استفاده کنید و اطلاعات اعتباری کاربر را ارسال کنید. برای مثال، می‌تواند سرویس LDAP یا هر سرویسی باشد که می‌خواهید از آن برای اعتبارسنجی اطلاعات اعتباری استفاده کنید. برای جزئیات این خط‌مشی‌ها، خط‌مشی «استخراج متغیرها» و خط‌مشی «جاوا اسکریپت» را ببینید.

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

۵. خط‌مشی 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"
}

‫۶. کارخواه میانای برنامه‌سازی کاربردی محافظت‌شده را فراخوانی می‌کند

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

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