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

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

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

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

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

مثال‌هایی که ممکن است برایتان مفید باشند

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

ویدئو

موارد استفاده

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

نمودار جریان

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

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

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

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

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

اگر سرویس هویت، اعتبارنامه‌ها را تأیید کند و پاسخ ۲۰۰ را برگرداند، 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"
}

۶. کلاینت، API محافظت‌شده را فراخوانی می‌کند.

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

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