استفاده از توکن های OAuth شخص ثالث

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

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

در حالت معمول، Apigee Edge یک توکن OAuth تولید و ذخیره می‌کند و آن را به برنامه فراخوانی باز می‌گرداند. سپس برنامه فراخوان هنگام درخواست سرویس، آن توکن را به Apigee Edge برمی‌گرداند، و Apigee Edge - از طریق خط‌مشی OAuthV2 با Operation = VerifyAccessToken - تأیید می‌کند که توکن معتبر است. این مبحث توضیح می‌دهد که چگونه می‌توانید Apigee Edge را برای ذخیره یک توکن OAuth که در جای دیگری تولید شده است، پیکربندی کنید، در حالی که قسمت تأیید توکن را ثابت نگه دارید، درست مثل اینکه توکن توسط Edge تولید شده است.

مثال

اگر می‌خواهید نمونه‌ای را ببینید که تکنیک توصیف‌شده در این مبحث را نشان می‌دهد، به نمونه مدیریت توکن نمایندگی Apigee نگاهی بیندازید.

این چیه؟

فرض کنید شما یک سیستم مجوز موجود دارید و می‌خواهید از توکن یا مقادیر کد تولید شده توسط آن سیستم به جای توکن OAuth2 یا مقادیر کدی که Edge تولید می‌کند استفاده کنید. سپس می‌توانید درخواست‌های پروکسی API ایمن را با توکن یا کد جایگزین شده ایجاد کنید و Edge آنها را به گونه‌ای تأیید می‌کند که گویی توسط Edge تولید شده‌اند.

برخی از پس زمینه

در حالت معمول، Apigee Edge با تولید یک رشته تصادفی از حروف و اعداد، یک توکن تولید می کند. Apigee Edge با آن توکن، داده‌های دیگری مانند زمان صدور توکن، تاریخ انقضا، فهرست محصولات API که توکن برای آنها معتبر است، و محدوده مرتبط است. همه این اطلاعات را می توان در پاسخی که به طور خودکار توسط خط مشی OAuthV2 که با Operation = GenerateAccessToken پیکربندی شده است، بازگرداند. پاسخ به این شکل است:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

مقدار ویژگی access_token به طور موثر کلید جستجو برای داده های پاسخ است. یک برنامه می‌تواند درخواستی به یک پراکسی API که در Edge میزبانی می‌شود، حاوی توکن حامل zBC90HhCGmGlaMBWeZAai2s3za5j باشد، و Edge - با خط‌مشی OAuthV2 با Operation = VerifyAccessToken - توکن را جستجو می‌کند، همه اطلاعات را بازیابی می‌کند و از آن اطلاعات برای تعیین اینکه آیا استفاده می‌کند یا خیر. توکن برای پروکسی API درخواستی معتبر است یا نه. به این کار اعتبار سنجی توکن می گویند. تمام اطلاعات فوق شامل توکن است. مقدار access_token تنها راهی برای جستجوی آن اطلاعات است.

از طرف دیگر، با دنبال کردن مراحل توضیح داده شده در اینجا، می توانید Edge را برای ذخیره یک توکن پیکربندی کنید تا مقدار access_token آن چیزی باشد که توسط یک سرویس خارجی تولید می شود. همه ابرداده های دیگر ممکن است یکسان باشند. برای مثال، فرض کنید یک سیستم خارج از Apigee Edge دارید که توکن هایی به شکل "TOKEN-< 16 عدد تصادفی >" تولید می کند. در این صورت، ابرداده توکن کامل ذخیره شده توسط Apigee Edge ممکن است:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "TOKEN-1092837373654221",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

در این مورد، یک برنامه می‌تواند درخواستی را به یک پراکسی API که در Edge میزبانی شده است، ارسال کند، که توکن حامل TOKEN-1092837373654221 حمل می‌کند، و Edge - از طریق خط‌مشی OAuthV2 با Operation = VerifyAccessToken - می‌تواند آن را تأیید کند. می‌توانید الگوی واردات مشابهی را برای کدهای مجوز و رمزهای تازه‌سازی اعمال کنید.

بیایید در مورد اعتبارسنجی اعتبار مشتری صحبت کنیم

یکی از پیش نیازهای تولید توکن، اعتبارسنجی مشتری درخواست کننده است. به طور پیش فرض، خط مشی OAuthV2/GenerateAccessToken در Apigee Edge به طور ضمنی اعتبار مشتری را تأیید می کند. معمولاً در یک درخواست برای یک توکن OAuthV2، client_id و client_secret در سربرگ Authorization ارسال می‌شوند که از طریق HTTP Basic Authorization کدگذاری می‌شود (لحظه دوقطه، سپس با کدگذاری base64). خط مشی OAuthV2/GenerateAccessToken در Apigee Edge آن هدر را رمزگشایی می کند و client_id را جستجو می کند و تأیید می کند که client_secret ارسال شده برای آن client_id معتبر است. این کار در صورتی کار می‌کند که اعتبارنامه‌ها برای Apigee Edge شناخته شوند - به عبارت دیگر یک برنامه توسعه‌دهنده در Apigee Edge ذخیره شده است که حاوی یک اعتبار است که خود شامل client_id و client_secret داده شده است.

در صورتی که اعتبار کلاینت توسط Apigee Edge تایید نشود، باید پروکسی API خود را قبل از تولید یک توکن طراحی کنید تا صریحاً از طریق روش‌های دیگری اعتبار کلاینت را تأیید کند. اغلب این از طریق یک خط مشی ServiceCallout است که به یک نقطه پایانی راه دور در شبکه شما متصل می شود.

به هر حال، به طور ضمنی یا صریح، باید اطمینان حاصل کنید که پروکسی API که توکن‌ها را تولید می‌کند، ابتدا اعتبار مشتری را تأیید می‌کند. به خاطر داشته باشید که اعتبار سنجی مشتری مستقل از تولید توکن دسترسی است. می‌توانید Apigee Edge را برای انجام هر دو، یا انجام یکی یا دیگری، یا هیچ‌کدام پیکربندی کنید.

اگر می‌خواهید خط‌مشی OAuthV2/GenerateAccessToken در Apigee Edge اعتبار مشتری را در مقابل فروشگاه Edge تأیید کند، عنصر <ExternalAuthorization> را در پیکربندی خط‌مشی روی false قرار دهید یا آن را به طور کامل حذف کنید. اگر می‌خواهید از یک سرویس مجوز خارجی برای تأیید صریح اعتبار مشتری استفاده کنید، <ExternalAuthorization> را روی true تنظیم کنید.

اگرچه Apigee Edge ممکن است اعتبار کلاینت را تأیید نکند، اما همچنان لازم است که client_id توسط Apigee Edge شناخته و مدیریت شود. هر access_token در Apigee Edge، چه توسط Apigee Edge تولید شده باشد و چه توسط یک سیستم خارجی تولید شده و سپس به Apigee Edge وارد شود، باید به یک برنامه مشتری مرتبط شود - که توسط client_id مشخص شده است. بنابراین حتی در مواردی که خط‌مشی OAuthV2/GenerateAccessToken در Apigee Edge مطابقت client_id و client_secret را تایید نمی‌کند، این خط‌مشی اعتبار می‌دهد که client_id معتبر است، موجود است و لغو نشده است. بنابراین به عنوان یک مرحله تنظیم پیش نیاز، ممکن است مجبور شوید client_id را از طریق API مدیریت Edge وارد کنید.

جریان سیاست برای OAuth شخص ثالث در Apigee

برای استفاده از نشانه‌های سیستم‌های OAuth شخص ثالث در Apigee Edge، جریان تولید نشانه‌های دسترسی باید از یکی از الگوهای زیر پیروی کند.

اعتبارسنجی خارجی اعتبار مشتری

  1. ServiceCallout برای تأیید اعتبار مشتری ورودی و دریافت یک توکن خارجی.
  2. ExtractVariables یا یک مرحله جاوا اسکریپت برای استخراج توکن تولید شده خارجی از پاسخ.
  3. AssignMessage را برای تنظیم متغیر معروف خاص به نام oauth_external_authorization_status تعیین کنید. مقدار باید درست باشد تا نشان دهد اعتبار مشتری معتبر است.
  4. OAuthV2 /GenerateAccessToken با عنصر <ExternalAuthorization> روی true تنظیم شده است، و حداقل یکی از <ExternalAccessToken> ، <ExternalRefreshToken> ، یا <ExternalAuthorizationCode> .

اعتبارسنجی داخلی اعتبار مشتری

  • ServiceCallout برای به دست آوردن یک توکن خارجی.
  • ExtractVariables یا یک مرحله جاوا اسکریپت برای استخراج توکن تولید شده خارجی از پاسخ.
  • OAuthV2 /GenerateAccessToken با عنصر <ExternalAuthorization> تنظیم شده بر روی false ، و حداقل یکی از <ExternalAccessToken> ، <ExternalRefreshToken> ، یا <ExternalAuthorizationCode> .

نکاتی در مورد جریان و پیکربندی خط مشی

  • در صورتی که می خواهید از یک سیستم خارجی برای تأیید اعتبار مشتری استفاده کنید، این به شما بستگی دارد که یک جریان خط مشی ایجاد کنید که آنچه لازم است را انجام دهد. معمولاً از یک خط مشی ServiceCallout برای ارسال اعتبار شناسایی خارجی به سرویس احراز هویت خارجی استفاده می کنید. سرویس احراز هویت خارجی معمولاً یک پاسخ و در صورت معتبر بودن اعتبارنامه، یک نشانه دسترسی نیز برمی‌گرداند.

  • پس از ServiceCallout، پراکسی API باید پاسخ را تجزیه کند تا وضعیت اعتبار، و همچنین access_token تولید شده خارجی و احتمالاً refresh_token را استخراج کند.

  • در خط‌مشی OAuthV2/GenerateAccessToken، عنصر <StoreToken> را روی true و عنصر <ExternalAuthorization> را در صورت لزوم روی true یا false تنظیم کنید.

    هنگامی که خط مشی OAuthV2/GenerateAccessToken اجرا می شود، متغیر oauth_external_authorization_status را می خواند. اگر متغیر تنظیم شده باشد و مقدار درست باشد، Apigee Edge سعی نمی‌کند اعتبار مشتری را تأیید کند. اگر متغیر تنظیم نشده باشد یا مقدار درست نباشد، Apigee Edge تلاش خواهد کرد تا اعتبار مشتری را تأیید کند.

  • سه عنصر برای خط مشی OAuthV2 وجود دارد که به شما امکان می دهد داده های خارجی را برای وارد کردن مشخص کنید: <ExternalAccessToken> ، <ExternalRefreshToken> و <ExternalAuthorizationCode> . هر یک از این عناصر یک متغیر جریان را می پذیرد. خط‌مشی Edge آن متغیر را برای یافتن نشانه دسترسی، کد بازخوانی یا کد مجوز ایجاد شده توسط خارجی می‌خواند. این به شما بستگی دارد که سیاست ها و منطق را برای قرار دادن توکن ها یا کدهای خارجی در متغیرهای مناسب پیاده سازی کنید.

    برای مثال، پیکربندی زیر در خط‌مشی OAuthV2 به Edge می‌گوید که توکن را در متغیر زمینه‌ای به نام external_token جستجو کند.

    <ExternalAccessToken>external_token</ExternalAccessToken>

    شما همچنین باید یک مرحله قبلی داشته باشید که آن متغیر را تنظیم می کند.

  • با توجه به تنظیم متغیر oauth_external_authorization_status ، یک تکنیک رایج برای تنظیم این متغیر استفاده از یک خط مشی AssignMessage با عنصر AssignVariable است، مانند این:

    <AssignMessage name="AssignMessage-SetVariable">
    <DisplayName>Assign Message - Set Variable</DisplayName>
    <AssignVariable>
        <Name>oauth_external_authorization_status</Name>
        <Value>true</Value>
    </AssignVariable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>

    به یاد داشته باشید، این خط مشی باید قبل از خط مشی OAuthV2 با Operation = GenerateAccessToken قرار گیرد.

نمونه سیاست OAuthV2

خط مشی OAuthV2 زیر یک نشانه دسترسی Apigee Edge ایجاد می کند، با توجه به اینکه Edge یک مقدار توکن را در متغیر جریان خارجی external_access_token پیدا می کند.

<OAuthV2 name="OAuth-v20-Store-External-Token">
    <ExternalAccessToken>external_access_token</ExternalAccessToken>
    <ExternalAuthorization>true</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <GenerateResponse enabled="true">
        <Format>FORM_PARAM</Format>
    </GenerateResponse>
    <ReuseRefreshToken>false</ReuseRefreshToken>
    <StoreToken>true</StoreToken>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <ExpiresIn ref='flow.variable'>2400000</ExpiresIn>
</OAuthV2>

در تئوری، می‌توانید این الگو را با هر سرویس مجوز OAuth2 شخص ثالث اعمال کنید.