گوگل متعهد به پیشبرد برابری نژادی برای جوامع سیاه پوست است. ببینید چگونه.

استفاده از OAuth 2.0 برای دسترسی به API های Google

API های گوگل با استفاده از OAuth تأیید 2.0 پروتکل برای احراز هویت و مجوز. Google از سناریوهای رایج OAuth 2.0 مانند برنامه های کاربردی دستگاه سرور وب ، سمت مشتری ، نصب شده و ورودی محدود پشتیبانی می کند.

برای شروع، به دست آوردن OAuth تأیید اعتبار 2.0 مشتری از Google API Console . سپس برنامه مشتری شما یک رمز دسترسی از سرور مجوز گوگل درخواست می کند ، توکن از پاسخ استخراج می کند و رمز را به API Google که می خواهید به آن دسترسی پیدا کنید ارسال می کند. برای یک تظاهرات تعاملی از استفاده از OAuth 2.0 با Google (از جمله گزینه برای استفاده از اعتبار مشتری خود را)، آزمایش با OAuth تأیید 2.0 زمین بازی .

این صفحه مروری بر سناریوهای مجوز OAuth 2.0 که Google پشتیبانی می کند ، و پیوندهایی به محتوای دقیق تر را ارائه می دهد. برای جزئیات در مورد استفاده از OAuth 2.0 برای احراز هویت، و ایجاد حساب کاربری اتصال .

مراحل اساسی

همه برنامه ها هنگام دسترسی به Google API با استفاده از OAuth 2.0 از الگوی اساسی پیروی می کنند. در یک سطح بالا ، پنج مرحله را دنبال می کنید:

1. اخذ OAuth تأیید 2.0 اعتبار از Google API Console.

مشاهده Google API Console برای به دست آوردن OAuth تأیید 2.0 اعتبار مانند یک شناسه مشتری و مشتری مخفی که به هر دو گوگل و نرم افزار خود را شناخته شده است. مجموعه مقادیر بر اساس نوع برنامه ای که می سازید متفاوت است. به عنوان مثال ، یک برنامه JavaScript نیازی به راز ندارد ، اما یک برنامه وب سرور نیاز دارد.

2. از سرور مجوز گوگل رمز دسترسی دریافت کنید.

قبل از اینکه برنامه شما با استفاده از Google API بتواند به داده های خصوصی دسترسی پیدا کند ، باید یک رمز دسترسی بدست آورد که اجازه دسترسی به آن API را می دهد. یک رمز دسترسی مجزا می تواند درجات مختلفی از دسترسی به چندین API را فراهم کند. یک پارامتر متغیر به نام scope کنترل مجموعه ای از منابع و عملیات که دسترسی مجوز رمز. در طول درخواست دسترسی رمز، نرم افزار خود را یک یا چند مقدار در می فرستد scope پارامتر.

روش های مختلفی برای ایجاد این درخواست وجود دارد و آنها بسته به نوع برنامه ای که در حال ساخت آن هستید متفاوت هستند. به عنوان مثال ، یک برنامه JavaScript ممکن است با استفاده از مرورگر هدایت به Google ، یک رمز دسترسی را درخواست کند ، در حالی که برنامه نصب شده روی دستگاهی که هیچ مرورگری ندارد از درخواست های سرویس وب استفاده می کند.

برخی از درخواست ها به مرحله احراز هویت نیاز دارند که کاربر با حساب Google خود وارد سیستم می شود. پس از ورود به سیستم ، از کاربر سال می شود که آیا مایل است یک یا چند مجوز را که برنامه شما درخواست می کند ، اعطا کند. این فرایند رضایت کاربر نامیده می شود.

اگر کاربر حداقل یک مجوز اعطا کند ، سرور مجوز Google به برنامه شما یک کد دسترسی (یا یک کد مجوز که برنامه شما می تواند برای به دست آوردن یک رمز دسترسی استفاده کند) و لیستی از محدوده های دسترسی که توسط آن رمز اعطا می شود ، می فرستد. اگر کاربر اجازه ندهد ، سرور خطایی را برمی گرداند.

در صورت نیاز به دسترسی ، و نه در جلو ، معمولاً بهترین درخواست برای درخواست دامنه است. به عنوان مثال ، برنامه ای که می خواهد از ذخیره یک رویداد در یک تقویم پشتیبانی کند ، تا زمانی که کاربر دکمه "افزودن به تقویم" را فشار ندهد ، نباید از تقویم Google درخواست کند. دیدن مجوز افزایشی .

3- دامنه دسترسی اعطا شده توسط کاربر را بررسی کنید.

محدوده های موجود در پاسخ رمز دسترسی را با محدوده های مورد نیاز برای دسترسی به ویژگی ها و عملکرد برنامه خود ، وابسته به دسترسی به Google API مرتبط مقایسه کنید. بدون دسترسی به API مربوطه ، هیچکدام از ویژگی های برنامه شما قادر به کار نیست را غیرفعال کنید.

دامنه موجود در درخواست شما ممکن است با دامنه موجود در پاسخ شما مطابقت نداشته باشد ، حتی اگر کاربر به همه محدوده های درخواستی اجازه داده باشد. برای دامنه مورد نیاز برای دسترسی به اسناد مربوط به هر API Google مراجعه کنید. یک API ممکن است مقادیر رشته ای چند دامنه را به یک دامنه دسترسی واحد ترسیم کند ، رشته دامنه یکسانی را برای تمام مقادیر مجاز در درخواست بازگرداند. به عنوان مثال: از API گوگل افراد ممکن است دامنه بازگشت https://www.googleapis.com/auth/contacts زمانی که یک برنامه درخواست کاربران اجازه دامنه https://www.google.com/m8/feeds/ ؛ روش API گوگل مردم people.updateContact نیاز به یک دامنه داده از https://www.googleapis.com/auth/contacts .

4- رمز دسترسی را به یک API ارسال کنید.

پس از یک برنامه به دست آوردن دسترسی نشانه، آن این رمز به یک API گوگل در می فرستد درخواست هدر HTTP مجوز . امکان ارسال توکن به عنوان پارامترهای رشته کوئری URI وجود دارد ، اما ما آن را توصیه نمی کنیم ، زیرا پارامترهای URI می توانند در پرونده های لاگ که کاملاً ایمن نیستند ، درآیند. همچنین ، استفاده از REST نامگذاری پارامترهای URI غیرضروری خوب است. توجه داشته باشید که پشتیبانی query-string در اول ژوئن 2021 منسوخ می شود.

نشانه های دسترسی تنها برای مجموعه ای از عملیات و منابع شرح داده شده در معتبر هستند scope از نشانه درخواست. به عنوان مثال ، اگر رمز دسترسی برای Google Calendar API صادر شده باشد ، به Google Contact API اجازه دسترسی نمی دهد. با این وجود می توانید چندین بار آن رمز دسترسی را برای انجام اقدامات مشابه به Google Calendar API ارسال کنید.

5. در صورت لزوم رمز دسترسی را تازه کنید.

طول عمر نشانه های دسترسی محدود است. اگر برنامه شما بیش از عمر یک رمز دسترسی نیاز به دسترسی به یک API Google داشته باشد ، می تواند یک نشانه تازه سازی به دست آورد. یک نشانه تازه سازی به برنامه شما امکان می دهد نشانه های دسترسی جدیدی بدست آورد.

سناریوها

برنامه های وب سرور

نقطه پایانی Google OAuth 2.0 از برنامه های وب سرور پشتیبانی می کند که از زبانها و چارچوبهایی مانند PHP ، Java ، Python ، Ruby و ASP.NET استفاده می کنند.

توالی مجوز از زمانی شروع می شود که برنامه شما مرورگری را به URL Google هدایت می کند. URL شامل پارامترهای جستجو است که نوع دسترسی درخواستی را نشان می دهد. Google تأیید اعتبار کاربر ، انتخاب جلسه و رضایت کاربر را کنترل می کند. نتیجه یک کد مجوز است که برنامه می تواند آن را با یک رمز دسترسی و یک نشانه تازه سازی مبادله کند.

این برنامه باید رمز بازخوانی را برای استفاده در آینده ذخیره کند و از رمز دسترسی برای دسترسی به Google API استفاده کند. هنگامی که رمز دسترسی منقضی شد ، برنامه از نشانه تازه سازی برای به دست آوردن رمز جدید استفاده می کند.

برنامه شما یک درخواست رمز به سرور مجوز گوگل می فرستد ، یک کد مجوز دریافت می کند ، کد را با یک رمز مبادله می کند و از رمز برای فراخوانی نقطه پایانی Google API استفاده می کند.

برای جزئیات، با استفاده از OAuth 2.0 برای برنامه های وب سرور .

برنامه های نصب شده

نقطه پایانی Google OAuth 2.0 از برنامه هایی که روی دستگاه هایی مانند رایانه ، دستگاه های همراه و رایانه لوحی نصب شده اند پشتیبانی می کند. هنگامی که شما یک ID مشتری از طریق ایجاد Google API Console ، مشخص است که این نرم افزار نصب شده است، پس از آن آندروید، برنامه Chrome، سیستم عامل iOS، جهانی ویندوز بستر های نرم افزاری (UWP)، و یا برنامه Desktop را انتخاب کنید به عنوان نوع برنامه.

این فرآیند منجر به شناسه مشتری و در بعضی موارد رمز مشتری می شود که شما آن را در کد منبع برنامه خود جاسازی می کنید. (در این زمینه ، بدیهی است که راز مشتری به عنوان یک راز تلقی نمی شود.)

توالی مجوز از زمانی شروع می شود که برنامه شما مرورگر را به URL Google هدایت می کند. URL شامل پارامترهای جستجو است که نوع دسترسی درخواستی را نشان می دهد. Google تأیید اعتبار کاربر ، انتخاب جلسه و رضایت کاربر را کنترل می کند. نتیجه یک کد مجوز است که برنامه می تواند آن را با یک رمز دسترسی و یک نشانه تازه سازی مبادله کند.

این برنامه باید رمز بازخوانی را برای استفاده در آینده ذخیره کند و از رمز دسترسی برای دسترسی به Google API استفاده کند. هنگامی که رمز دسترسی منقضی شد ، برنامه از نشانه تازه سازی برای به دست آوردن رمز جدید استفاده می کند.

برنامه شما یک درخواست رمز به سرور مجوز گوگل می فرستد ، یک کد مجوز دریافت می کند ، کد را با یک رمز مبادله می کند و از رمز برای فراخوانی نقطه پایانی Google API استفاده می کند.

برای جزئیات، با استفاده از OAuth 2.0 برای برنامه های نصب .

برنامه های سمت مشتری (JavaScript)

نقطه پایانی Google OAuth 2.0 از برنامه های JavaScript که در مرورگر اجرا می شوند پشتیبانی می کند.

توالی مجوز از زمانی شروع می شود که برنامه شما مرورگری را به URL Google هدایت می کند. URL شامل پارامترهای جستجو است که نوع دسترسی درخواستی را نشان می دهد. Google تأیید اعتبار کاربر ، انتخاب جلسه و رضایت کاربر را کنترل می کند.

نتیجه یک رمز دسترسی است ، که مشتری باید آن را تأیید کند قبل از اینکه آن را در درخواست API Google وارد کند. هنگامی که رمز به پایان می رسد ، برنامه روند کار را تکرار می کند.

برنامه JS شما یک درخواست رمز به سرور مجوز Google می فرستد ، توکن دریافت می کند ، اعتبار را تایید می کند و از رمز برای فراخوانی نقطه پایانی API Google استفاده می کند.

برای جزئیات، با استفاده از OAuth 2.0 برای برنامه های کاربردی Client-side را .

برنامه های کاربردی در دستگاه های ورودی محدود

نقطه پایانی Google OAuth 2.0 از برنامه هایی پشتیبانی می کند که روی دستگاه های ورودی محدود مانند کنسول های بازی ، دوربین فیلمبرداری و چاپگرها اجرا می شوند.

توالی مجوز با درخواست یک برنامه وب از یک برنامه Google URL برای کد مجوز آغاز می شود. پاسخ شامل پارامترهای مختلفی از جمله URL و کدی است که برنامه به کاربر نشان می دهد.

کاربر URL و کد را از دستگاه دریافت می کند ، سپس به یک دستگاه یا رایانه جداگانه با قابلیت ورودی غنی تر می رود. کاربر یک مرورگر را راه اندازی می کند ، به URL مشخص شده می رود ، وارد سیستم می شود و کد را وارد می کند.

در همین حال ، برنامه در یک بازه زمانی مشخص از یک URL Google نظر سنجی می کند. پس از تأیید دسترسی کاربر ، پاسخ از سرور Google حاوی یک رمز دسترسی و یک نشانه تازه سازی است. این برنامه باید رمز بازخوانی را برای استفاده در آینده ذخیره کند و از رمز دسترسی برای دسترسی به Google API استفاده کند. هنگامی که رمز دسترسی منقضی شد ، برنامه از نشانه تازه سازی برای به دست آوردن رمز جدید استفاده می کند.

کاربر در دستگاه جداگانه ای که دارای مرورگر است وارد می شود

برای جزئیات، با استفاده از OAuth 2.0 برای دستگاه های .

حساب های سرویس

API های Google مانند Prediction API و Google Cloud Storage می توانند به نمایندگی از برنامه شما بدون دسترسی به اطلاعات کاربر عمل کنند. در این شرایط برنامه شما باید هویت خود را به API ثابت کند ، اما رضایت کاربر لازم نیست. به همین ترتیب ، در سناریوهای سازمانی ، برنامه شما می تواند درخواست دسترسی غیر مجاز به برخی منابع را داشته باشد.

برای این نوع از تعاملات سرور به سرور شما نیاز به یک حساب کاربری سرویس است که یک حساب کاربری است که متعلق به برنامه خود را به جای به یک فرد کاربر نهایی. برنامه شما از طرف حساب سرویس با Google API تماس می گیرد و رضایت کاربر لازم نیست. (در سناریوهای غیر سرویس-حساب ، برنامه شما از طرف کاربران نهایی با Google API تماس می گیرد و گاهی اوقات رضایت کاربر لازم است.)

اعتبار یک حساب کاربری سرویس، که شما را از به دست آوردن Google API Console، شامل یک آدرس ایمیل تولید است که منحصر به فرد، یک ID مشتری، و حداقل یک عمومی / جفت کلید خصوصی. شما از شناسه مشتری و یک کلید خصوصی برای ایجاد JWT امضا شده و ساخت درخواست دسترسی رمز در قالب مناسب استفاده می کنید. سپس برنامه شما درخواست رمز را به سرور مجوز Google OAuth 2.0 ارسال می کند ، که رمز دسترسی را برمی گرداند. برنامه از رمز برای دسترسی به Google API استفاده می کند. هنگامی که رمز به پایان می رسد ، برنامه روند کار را تکرار می کند.

برنامه سرور شما برای درخواست رمز از سرور مجوز Google از JWT استفاده می کند ، سپس برای فراخوانی نقطه پایانی Google API از رمز استفاده می کند. هیچ کاربر نهایی درگیر نیست.

برای جزئیات بیشتر، نگاه کنید به اسناد و مدارک خدمات حساب .

اندازه نشانه

اندازه نمادها تا محدودیت های زیر می تواند متفاوت باشد:

  • کدهای مجوز: 256 بایت
  • نشانه های دسترسی: 2048 بایت
  • تازه کردن نشانه ها: 512 بایت

نشانه های دسترسی توسط Google Cloud بازگشت API امنیت رمز سرویس به طور مشابه به گوگل API OAuth حفظ نشانه 2.0 دسترسی ساختار اما محدودیت اندازه های مختلف رمز. برای جزئیات، مشاهده مستندات API .

Google حق تغییر اندازه رمز را در این محدودیت ها برای خود محفوظ است ، و برنامه شما باید متناسب با آن از اندازه های متغیر رمز پشتیبانی کند.

تاریخ انقضا رمز را تازه کنید

شما باید پیش بینی کنید که احتمالاً یک کد تازه اعلان شده دیگر کار نکند ، کد خود را بنویسید. یک نشانه تازه سازی ممکن است به یکی از این دلایل متوقف شود:

  • کاربر با دسترسی برنامه خود را لغو .
  • رمز تازه سازی شش ماه است که استفاده نشده است.
  • کاربر رمزهای ورود خود را تغییر داده و رمز بازخوانی شامل دامنه های Gmail است.
  • حساب کاربری از حداکثر تعداد علائم تجدید پذیر (زنده) بیشتر شده است.
  • کاربر به یک سازمان Google Cloud Platform تعلق دارد که دارای سیاست های کنترل جلسه است.

به یک پروژه Google Cloud Platform با صفحه رضایت OAuth که برای نوع کاربر خارجی پیکربندی شده و وضعیت انتشار "Testing" ، کد تازه سازی در 7 روز منقضی می شود.

در حال حاضر برای هر شناسه Google به ازای شناسه مشتری OAuth 2.0 ، 50 علامت تازه سازی محدود شده است. در صورت رسیدن به حد مجاز ، ایجاد یک نشانه تازه سازی جدید به طور خودکار قدیمی ترین نشانه تازه سازی را بدون اخطار فاقد اعتبار می کند. این محدودیت به صدق نمی کند حساب های خدمات .

همچنین در تعداد کل نشانه های تازه سازی که یک حساب کاربری یا حساب خدمات می تواند در تمام مشتریان داشته باشد محدودیت بیشتری وجود دارد. بیشتر کاربران عادی از این حد فراتر نمی روند اما ممکن است حساب توسعه دهنده ای که برای آزمایش یک پیاده سازی استفاده کرده است.

اگر شما نیاز به اجازه برنامه های متعدد، ماشین آلات، و یا دستگاه، یک راه حل است برای محدود کردن تعدادی از مشتریان که شما در هر حساب Google اجازه 15 یا 20. اگر شما یک هستند مدیر گوگل فضای کاری ، شما می توانید کاربران دیگری با دسترسی مدیریتی و ایجاد از آنها برای اجازه دادن به برخی از مشتریان استفاده کنید.

رسیدگی به سیاست های کنترل جلسه برای سازمان های Google Cloud Platform (GCP)

مدیران سازمان GCP ممکن احراز هویت مجدد مکرر از کاربران نیاز به در حالی که آنها دسترسی به منابع GCP، با استفاده از قابلیت کنترل از جلسه Google ابر . این اثرات سیاست های دسترسی به Google Cloud Console از گوگل ابر SDK (همچنین به عنوان CLI gcloud شناخته شده است) و هر نرم افزاری از OAuth شخص ثالث است که نیاز به دامنه پلت فرم ابر. اگر یک کاربر یک سیاست کنترل نشست در محل و سپس از انقضای مدت زمان جلسه، تماس API خود را خطا خواهد شد شبیه به آنچه که می افتد اگر بازخوانی کد لغو شد - تماس با یک نوع خطا مواجه میشود invalid_token ؛ از نوع خطای فرعی می توان برای تشخیص بین رمز علامت لغو و خرابی ناشی از سیاست کنترل جلسه استفاده کرد. از آنجا که مدت زمان جلسه می تواند بسیار محدود باشد (بین 1 ساعت تا 24 ساعت) ، این سناریو باید با راه اندازی مجدد یک جلسه خودکار ، به خوبی انجام شود.

به همین ترتیب ، شما نباید از اعتبار کاربر برای استقرار سرور به سرور استفاده کنید یا آنها را تشویق کنید. اگر اعتبار کاربری برای کارها یا عملیات طولانی مدت در سرور مستقر شود و مشتری سیاست های کنترل جلسه را بر روی چنین کاربرانی اعمال کند ، برنامه سرور از کار می افتد زیرا با پایان منقضی شدن جلسه ، راهی برای تأیید اعتبار مجدد کاربر وجود ندارد

برای کسب اطلاعات بیشتر در مورد چگونگی کمک به مشتریان خود استقرار این ویژگی، اشاره به این مقاله راهنما مدیر متمرکز شده است.

کتابخانه های مشتری

کتابخانه های مشتری زیر با چارچوب های محبوب ادغام شده اند ، که اجرای OAuth 2.0 را ساده تر می کند. با گذشت زمان ویژگی های بیشتری به کتابخانه ها اضافه می شود.