شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات
با نوع اعطای اعتبار مشتری، یک برنامه اعتبارنامه خود (شناسه مشتری و راز مشتری) را به نقطه پایانی در Apigee Edge میفرستد که برای ایجاد یک نشانه دسترسی تنظیم شده است. اگر اعتبارنامه ها معتبر باشند، Edge یک نشانه دسترسی به برنامه مشتری برمی گرداند.
در مورد این موضوع
این مبحث شرح کلی نوع اعطای اعتبار مشتری OAuth 2.0 را ارائه می دهد و نحوه اجرای این جریان را در Apigee Edge مورد بحث قرار می دهد.
موارد استفاده کنید
معمولاً، این نوع کمک هزینه زمانی استفاده میشود که برنامه مالک منبع نیز باشد. به عنوان مثال، یک برنامه ممکن است نیاز به دسترسی به یک سرویس ذخیره سازی مبتنی بر ابر پشتیبان برای ذخیره و بازیابی داده هایی داشته باشد که برای انجام کار خود استفاده می کند، نه داده هایی که به طور خاص متعلق به کاربر نهایی است. این جریان نوع اعطا به طور دقیق بین یک برنامه مشتری و سرور مجوز رخ می دهد. کاربر نهایی در این جریان نوع کمک مالی شرکت نمی کند.
نقش ها
نقش ها «بازیگران» را مشخص می کنند که در جریان OAuth شرکت می کنند. بیایید مروری اجمالی از نقشهای اعتبار کلاینت انجام دهیم تا به نشان دادن جایی که Apigee Edge در آن قرار میگیرد کمک کنیم. برای بحث کامل در مورد نقشهای OAuth 2.0، مشخصات IETF OAuth 2.0 را ببینید.
- برنامه مشتری - برنامه ای که نیاز به دسترسی به منابع محافظت شده کاربر دارد. به طور معمول، با این جریان، برنامه به جای اینکه به صورت محلی روی لپتاپ یا دستگاه کاربر باشد، روی سرور اجرا میشود.
- Apigee Edge -- در این جریان، Apigee Edge سرور مجوز OAuth است. نقش آن تولید نشانههای دسترسی، اعتبارسنجی نشانههای دسترسی و ارسال درخواستهای مجاز برای منابع محافظتشده به سرور منبع است.
- سرور منبع -- سرویس پشتیبان که داده های محافظت شده ای را ذخیره می کند که برنامه مشتری برای دسترسی به آنها به مجوز نیاز دارد. اگر از پروکسی های API میزبانی شده در Apigee Edge محافظت می کنید، Apigee Edge نیز سرور منبع است.
نمونه کد
میتوانید یک نمونه کامل و کاربردی از نوع اعطای اعتبار مشتری را در GitHub پیدا کنید. برای پیوند به نمونه های بیشتر به منابع اضافی زیر مراجعه کنید.
نمودار جریان
نمودار جریان زیر جریان اعتبار مشتری را با Apigee Edge به عنوان سرور مجوز ارائه می دهد. به طور کلی، Edge همچنین سرور منبع در این جریان است -- یعنی پراکسی های API منابع محافظت شده هستند.
مراحل در اعتبار مشتری جریان دارد
در اینجا خلاصهای از مراحل مورد نیاز برای پیادهسازی نوع اعطای کد اعتبار مشتری که در آن Apigee Edge به عنوان سرور مجوز خدمت میکند، آمده است. به یاد داشته باشید، با این جریان، اپلیکیشن کلاینت به سادگی شناسه مشتری و راز سرویس گیرنده خود را ارائه می کند و اگر معتبر باشند، Apigee Edge یک توکن دسترسی برمی گرداند.
پیش نیاز: برنامه مشتری باید در Apigee Edge ثبت شده باشد تا شناسه مشتری و کلیدهای مخفی مشتری به دست آید. برای جزئیات به ثبت برنامه های مشتری مراجعه کنید.
1. مشتری یک رمز دسترسی درخواست می کند
برای دریافت رمز دسترسی، کلاینت یک فراخوانی API را با مقادیر شناسه مشتری و راز مشتری که از یک برنامه توسعه دهنده ثبت شده به دست آمده است، به Edge ارسال می کند. علاوه بر این، پارامتر grant_type=client_credentials باید به عنوان پارامتر پرس و جو ارسال شود. (با این حال، می توانید خط مشی OAuthV2 را برای پذیرش این پارامتر در سرصفحه یا بدنه درخواست پیکربندی کنید - برای جزئیات بیشتر به خط مشی OAuthV2 مراجعه کنید).
به عنوان مثال:
$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials&client_id=ns4fQc14Zg4hKFCNaSzArVuwszX95X&client_secret=ZIjFyTsNgQNyxI'
توجه: اگرچه میتوانید مقادیر client_id و client_secret را بهعنوان پارامترهای query همانطور که در بالا نشان داده شده است، ارسال کنید، این کار خوبی است که آنها را به عنوان یک رشته کد شده URL base64 در هدر Authorization ارسال کنید. برای انجام این کار، باید از ابزار یا ابزار رمزگذاری base64 استفاده کنید تا دو مقدار را به همراه دو نقطه از هم جدا کنید. مانند این: aBase64EncodeFunction(clientidvalue:clientsecret). بنابراین، مثال بالا به این صورت رمزگذاری می شود:
result = aBase64EncodeFunction(ns4fQc14Zg4hKFCNaSzArVuwszX95X:ZIjFyTsNgQNyxI) // به نقطه ای که این دو مقدار را جدا می کند توجه کنید.
نتیجه کدگذاری رشته فوق توسط base64 این است: bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg==
سپس درخواست توکن را به این صورت انجام دهید:
$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic bnM0ZlFjMTRaZzRoS0ZDTmFTekFyVnV3c3pYOTVYOlpJakZ5VHNOZ1FOeXhJOg=='
2. Edge اعتبارنامه ها را تایید می کند
توجه داشته باشید که تماس API به نقطه پایانی /accesstoken ارسال می شود. این نقطه پایانی دارای یک خطمشی ضمیمه شده است که اعتبار برنامه را تأیید میکند. یعنی این خطمشی، کلیدهای ارسالشده را با کلیدهایی که Apigee Edge هنگام ثبت برنامه ایجاد کردهاند، مقایسه میکند. اگر میخواهید درباره نقاط پایانی OAuth در Edge اطلاعات بیشتری کسب کنید، به پیکربندی نقاط پایانی و خطمشیهای OAuth مراجعه کنید.
3. Edge پاسخی را برمیگرداند
اگر اعتبارنامه ها درست باشد، Edge یک نشانه دسترسی را به مشتری برمی گرداند. اگر نه، یک خطا برگردانده می شود.
4. مشتری با API محافظت شده تماس می گیرد
اکنون، با یک نشانه دسترسی معتبر، مشتری میتواند با API محافظتشده تماس بگیرد. در این سناریو، درخواستها به Apigee Edge (پراکسی) انجام میشود و Edge مسئول اعتبارسنجی نشانه دسترسی قبل از ارسال فراخوانی API به سرور منبع هدف است. برای مثال، فراخوانی API محافظت شده را در زیر ببینید.
پیکربندی جریان ها و سیاست ها
Edge به عنوان سرور مجوز، درخواستهای توکنهای دسترسی را پردازش میکند. بهعنوان توسعهدهنده API، باید یک پروکسی با یک جریان سفارشی برای رسیدگی به درخواستهای توکن و افزودن و پیکربندی یک خطمشی OAuthV2 ایجاد کنید. این بخش نحوه پیکربندی آن نقطه پایانی را توضیح می دهد.
پیکربندی جریان سفارشی
ساده ترین راه برای نشان دادن نحوه پیکربندی جریان پروکسی API، نشان دادن تعریف جریان XML است. در اینجا نمونه ای از جریان پروکسی API است که برای پردازش درخواست نشانه دسترسی طراحی شده است. به عنوان مثال، هنگامی که یک درخواست وارد می شود و پسوند مسیر با /accesstoken مطابقت دارد، سیاست GetAccessToken فعال می شود. برای مروری سریع از مراحل مورد نیاز برای ایجاد یک جریان سفارشی مانند این، پیکربندی نقاط پایانی و خطمشیهای OAuth را ببینید.
<Flows> <Flow name="GetAccessToken"> <!-- This policy flow is triggered when the URI path suffix matches /oauth/accesstoken. Publish this URL to app developers to use when obtaining an access token using an auth code --> <Condition>proxy.pathsuffix == "/oauth/accesstoken"</Condition> <Request> <Step><Name>GetAccessToken</Name></Step> </Request> </Flow> </Flows>
جریان را با یک خط مشی پیکربندی کنید
شما باید یک خط مشی را به شرح زیر به نقطه پایانی پیوست کنید. برای مرور سریع مراحل لازم برای افزودن یک خط مشی OAuthV2 به نقطه پایانی پروکسی ، پیکربندی نقاط پایانی و خطمشیهای OAuth را ببینید.
رمز دسترسی را دریافت کنید
این خط مشی به مسیر /accesstoken
پیوست شده است. از سیاست OAuthV2 با عملیات GenerateAccessToken مشخص شده استفاده می کند.
<OAuthV2 name="GetAccessToken"> <Operation>GenerateAccessToken</Operation> <ExpiresIn>3600000</ExpiresIn> <SupportedGrantTypes> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <GenerateResponse/> </OAuthV2>
فراخوانی API برای به دست آوردن نشانه دسترسی یک POST است و شامل یک سرصفحه Authorization با client_id + client+secret کدگذاری شده base64 و پارامتر query grant_type=client_credentials است. همچنین می تواند شامل پارامترهای اختیاری برای دامنه و وضعیت باشد. به عنوان مثال:
$ curl -i -H 'Content-Type: application/x-www-form-urlencoded' -X POST 'https://docs-test.apigee.net/oauth/accesstoken' -d 'grant_type=client_credentials' -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVgT1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ'
پیوست کردن خط مشی رمز دسترسی تأیید
برای محافظت از API خود با امنیت OAuth 2.0، باید یک خط مشی OAuthV2 را با عملیات VerifyAccessToken اضافه کنید. این خطمشی بررسی میکند که درخواستهای دریافتی دارای نشانه دسترسی معتبر هستند. اگر توکن معتبر باشد، Edge درخواست را پردازش می کند. اگر معتبر نباشد، Edge یک خطا برمیگرداند. برای مراحل اولیه، به تأیید نشانههای دسترسی مراجعه کنید.
<OAuthV2 async="false" continueOnError="false" enabled="true" name="VerifyAccessToken"> <DisplayName>VerifyAccessToken</DisplayName> <ExternalAuthorization>false</ExternalAuthorization> <Operation>VerifyAccessToken</Operation> <SupportedGrantTypes/> <GenerateResponse enabled="true"/> <Tokens/> </OAuthV2>
فراخوانی API محافظت شده
برای فراخوانی یک API که با امنیت OAuth 2.0 محافظت شده است، باید یک نشانه دسترسی معتبر ارائه کنید. الگوی صحیح این است که توکن را در هدر Authorization قرار دهید، به شرح زیر: توجه داشته باشید که نشانه دسترسی به عنوان "یک نشانه حامل" نیز نامیده می شود.
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
همچنین به ارسال نشانه دسترسی مراجعه کنید.
منابع اضافی
- Apigee آموزش آنلاین برای توسعه دهندگان API ارائه می دهد، از جمله یک دوره در مورد امنیت API ، که شامل OAuth می شود.
- خطمشی OAuthV2 - دارای مثالهای زیادی است که نشان میدهد چگونه درخواستها به سرور مجوز و نحوه پیکربندی خطمشی OAuthV2 را نشان میدهد.