این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

احراز هویت و مجوز در پروتکل داده گوگل

اخطار : این صفحه درباره APIهای قدیمی Google، Google Data APIها است. فقط مربوط به APIهایی است که در فهرست راهنمای Google Data APIs فهرست شده اند، که بسیاری از آنها با APIهای جدیدتر جایگزین شده اند. برای اطلاعات در مورد یک API جدید خاص، به مستندات API جدید مراجعه کنید. برای اطلاعات در مورد تأیید درخواست‌ها با یک API جدیدتر، به تأیید اعتبار و مجوز حساب‌های Google مراجعه کنید.

برنامه های شخص ثالث اغلب برای انواع خاصی از فعالیت ها نیاز به دسترسی محدود به حساب Google کاربر دارند. برای اطمینان از عدم سوء استفاده از داده های کاربر، کلیه درخواست های دسترسی باید توسط دارنده حساب تأیید شوند. کنترل دسترسی دارای دو جزء است، احراز هویت و مجوز.

خدمات احراز هویت به کاربران اجازه می دهد تا با استفاده از حساب Google وارد برنامه شما شوند.

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

خدمات احراز هویت و مجوز اغلب به طور جمعی به عنوان احراز هویت شناخته می شوند.

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

Google Sign-In راه ساده ای را ارائه می دهد که به افراد اجازه می دهد از اعتبار Google خود برای ورود به سایت شما استفاده کنند. این شامل مجموعه ای از ابزارهایی است که به راحتی در دستگاه های مختلف ادغام می شوند.
OAuth 2.0 یک پروتکل مجوز برای همه APIهای Google است. OAuth 2.0 به جای اینکه برنامه شما را ملزم به انجام مستقیم امضای رمزنگاری کند، برای امنیت به SSL متکی است. این پروتکل به برنامه شما اجازه می‌دهد تا دسترسی به داده‌های مرتبط با حساب Google کاربر را درخواست کند.
ورود با OAuth 2.0 ( OpenID Connect ) با ورود کاربران با حساب های Google خود احراز هویت می شود. این جایگزینی برای OpenID است و کاربران OpenID باید برای مهاجرت به Login با OAuth 2.0 برنامه ریزی کنند.

اگر برنامه شما یک ابزار است (برای استفاده در iGoogle یا سایر کانتینرهای OpenSocial)، به بخش احراز هویت برای ابزارک ها مراجعه کنید.

توجه : این سند برای ارائه یک نمای کلی از هر روش احراز هویت در نظر گرفته شده است. برای اطلاعات دقیق در مورد هر روش، به مستندات کامل APIهای تأیید اعتبار حساب Google مراجعه کنید.

همچنین برای بحث در مورد استفاده از API حساب‌های Google به گروه API حساب‌های Google مراجعه کنید.

OAuth - مجوز برای وب و برنامه های نصب شده

بسیاری از سرویس‌های Google اجازه دسترسی شخص ثالث به داده‌های تولید شده توسط کاربر، مانند داده‌های تقویم یا اسناد را می‌دهند، تا زمانی که دسترسی توسط کاربر مجاز باشد. این ویژگی به کاربران این امکان را می‌دهد تا داده‌ها را بین برنامه‌های Google و برنامه‌های شخص ثالث برای اهداف مختلف به اشتراک بگذارند و تبادل کنند.

Google از دو نسخه OAuth برای دسترسی مجاز به داده های Google کاربر پشتیبانی می کند: OAuth 1.0 و OAuth 2.0، که هر دو به برنامه های کاربردی وب و برنامه های نصب شده دسترسی دارند.

OAuth 2.0 برای وب و برنامه های نصب شده

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

OAuth 1.0 برای برنامه های کاربردی وب

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

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

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

استفاده از OAuth با برنامه های کاربردی وب

همه APIهای Google Data از OAuth پشتیبانی می‌کنند، یک استاندارد باز برای مجوز استفاده از داده‌ها در برنامه‌های کاربردی وب. همه برنامه‌های کاربردی وب که درخواست‌های OAuth را ارائه می‌کنند باید یک گواهی امنیتی بارگذاری کنند و در Google ثبت نام کنند. برای اطلاعات بیشتر به ثبت نام برای برنامه های کاربردی مبتنی بر وب مراجعه کنید.

Google Data APIs Client Libraries روش هایی را برای کمک به شما در استفاده از OAuth در برنامه وب خود ارائه می دهند. به طور خاص، روش‌هایی برای ساخت توکن درخواست، مجوز دادن به توکن درخواست و مبادله رمز درخواست مجاز با یک نشانه دسترسی وجود دارد. کتابخانه‌ها همچنین الگوریتم‌های امضای لازم را هنگام درخواست به سرویس Google Data کنترل می‌کنند. برای مثال‌های گسترده از نحوه استفاده از OAuth با کتابخانه‌های سرویس گیرنده Google Data API، به استفاده از OAuth با کتابخانه‌های سرویس گیرنده Google Data API مراجعه کنید.

فرآیند مجوز OAuth

فرآیند مجوز OAuth شامل مجموعه ای از تعاملات بین برنامه وب شما، سرورهای مجوز Google و کاربر نهایی است.

در سطح پایه، فرآیند به شرح زیر است:

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

هنگامی که برنامه شما در ابتدا درخواست دسترسی به داده‌های کاربر را می‌دهد، Google یک توکن درخواست غیرمجاز برای برنامه شما صادر می‌کند.

اگر کاربر قبلاً وارد نشده باشد، Google از کاربر می‌خواهد وارد شود. سپس Google صفحه مجوزی را نشان می‌دهد که به کاربر اجازه می‌دهد ببیند برنامه شما به چه داده‌های سرویس Google درخواست دسترسی دارد.

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

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

آماده شدن برای OAuth

قبل از اینکه بتوانید برنامه خود را برای استفاده از سرویس Google Authorization با OAuth تنظیم کنید، باید کارهای زیر را انجام دهید.

تصمیم گیری در مورد ثبت برنامه وب خود

برای ارائه تضمین‌های بیشتر به کاربران خود از امنیت داده‌هایشان، می‌توانید برنامه وب خود را در Google ثبت کنید و درخواست‌های خود را با گواهی امنیتی ثبت‌شده امضا کنید. برخی از فیدهای Google Data API فقط برای برنامه های ثبت شده در دسترس هستند. برای تعیین اینکه آیا آن API فقط با برنامه های ثبت شده کار می کند یا خیر، به اسناد مربوط به Google Data API مورد علاقه خود مراجعه کنید.

درخواست شما باید هر درخواست OAuth را امضا کند. اگر انتخاب می کنید که از امضای RSA-SHA1 برای امضای درخواست های خود استفاده کنید، باید یک گواهی امنیتی را به عنوان بخشی از فرآیند ثبت نام آپلود کنید.

از طرف دیگر، می توانید از امضای HMAC-SHA1 برای امضای درخواست های خود استفاده کنید. برای امضاهای HMAC-SHA1 هیچ گواهی لازم نیست. در عوض، Google یک مقدار consumer secret OAuth ایجاد می کند که پس از ثبت نام در صفحه ثبت دامنه شما نمایش داده می شود.

برای اطلاعات بیشتر در مورد فرآیند ثبت نام، به ثبت نام برای برنامه های کاربردی وب مراجعه کنید.

تعیین محدوده داده هایی که برنامه شما به آن دسترسی خواهد داشت

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

به طور کلی، شما باید یک نشانه برای محدودترین دامنه درخواست کنید که شامل داده های مورد نیاز شما باشد. برای مثال، اگر برنامه شما نیاز به دسترسی به فید «همه تقویم‌ها» کاربر دارد، باید یک نشانه برای دامنه http://www.google.com/calendar/feeds/default/allcalendars/full درخواست کنید.

راه اندازی مکانیزمی برای مدیریت توکن های OAuth

هنگامی که یک نشانه دسترسی OAuth برای داده های کاربر دریافت می کنید، باید از آن نشانه دسترسی برای تمام تعاملات بعدی با سرویس مشخص شده Google از طرف کاربر استفاده کنید.

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

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

تنظیم مکانیزمی برای درخواست دسترسی به سرویس Google

هر درخواست به یک سرویس Google باید امضا شود، و باید شامل یک نشانه دسترسی OAuth معتبر باشد. به طور کلی، هر درخواست در قالب یک درخواست HTTP GET با نشانه دسترسی و امضا در هدر انجام می شود. درخواست هایی که داده های جدید می نویسند باید از HTTP POST استفاده کنند.

برای اطلاعات بیشتر در مورد قالب درخواست مناسب برای هر API Google Data ، به مستندات آن API مراجعه کنید.

پیاده سازی OpenID (اختیاری)

اگر OpenID را برای احراز هویت کاربر پیاده‌سازی می‌کنید، از پروتکل ترکیبی برای ترکیب این دو فرآیند استفاده کنید. با OpenID+OAuth ، وظایف دریافت رمز درخواست و مجوز دادن به آن به عنوان بخشی از درخواست OpenID با پسوندهای OAuth انجام می شود. همانند OAuthGetRequestToken ، این افزونه‌ها برای شناسایی سرویس‌های Google مورد استفاده قرار می‌گیرند. یک پاسخ موفقیت آمیز به درخواست OpenID حاوی یک نشانه درخواست مجاز است. هنگامی که این نشانه دریافت شد، از OAuthGetAccessToken برای مبادله آن با یک توکن دسترسی استفاده کنید.

کار با توکن های OAuth

برای استفاده از OAuth، برنامه شما باید تماس های درخواست توکن امضا شده و خوش فرم ایجاد کند و پاسخ ها را به ترتیب زیر انجام دهد:

دریافت رمز درخواست غیرمجاز ( OAuthGetRequestToken )
مجوز درخواست رمز ( OAuthAuthorizeToken )
رمز درخواست مجاز را با یک نشانه دسترسی مبادله کنید ( OAuthGetAccessToken )

همه درخواست‌های OAuth باید امضا شوند، چه درخواست شما ثبت شده باشد یا نه. برای اطلاعات بیشتر، به امضای درخواست‌های OAuth مراجعه کنید.

می‌توانید با درخواست و دریافت نشانه‌های مجوز در زمین بازی OAuth آزمایش کنید.

برای مستندات دقیق، به مرجع OAuth API مراجعه کنید.

تنظیم URL بازگشت به تماس

می‌توانید مقداری برای oauth_callback در یک درخواست OAuthGetRequestToken تعیین کنید تا مشخص کنید که Google کاربر را پس از تأیید درخواست دسترسی شما به کجا هدایت می‌کند. URL برگشت به تماس می تواند شامل پارامترهای پرس و جو باشد. تغییر مسیر شامل همان پارامترهای پرس و جو و همچنین نشانه درخواست مجاز است که برنامه شما باید بتواند آن را تجزیه کند.

به عنوان مثال، هنگام پشتیبانی از چندین زبان، می توانید یک پارامتر پرس و جو را اضافه کنید که نسخه برنامه ای را که کاربر در حال مشاهده آن است، شناسایی می کند. مقدار oauth_callback "http://www.yoursite.com/Retrievetoken?Lang=de" منجر به تغییر مسیر "http://www.yoursite.com/Retrievetoken?Lang=de&oauth_token=DQAADKEDE" می شود. تجزیه توکن و پارامتر زبان تضمین می کند که کاربر به نسخه صحیح سایت هدایت می شود.

اگر پارامتر oauth_callback گنجانده نشود، Google پس از تأیید درخواست دسترسی شما، کاربر را به صفحه وبی هدایت می‌کند که شماره تأیید را نشان می‌دهد ( به مثال نگاه کنید ). قبل از اینکه بتوانید رمز درخواست مجاز را دریافت کنید، کاربر باید به صورت دستی به برنامه شما برگردد و شماره تأیید را وارد کند.

شناسایی اپلیکیشن شما برای کاربران

Google معمولاً هنگام درخواست رضایت دسترسی از کاربر، نام یک برنامه را نمایش می دهد ( به مثال مراجعه کنید ).

اگر برنامه شما ثبت نشده است، از پارامتر xoauth_displayname در درخواست OAuthGetRequestToken خود برای تعیین نام برنامه خود استفاده کنید. اگر آن پارامتر مشخص نشده باشد، Google نام دامنه URL ارائه شده توسط پارامتر oauth_callback را نمایش می دهد. اگر URL بازگشت به تماس ارائه نشود، Google رشته "ناشناس" را نمایش می دهد.

اگر برنامه شما ثبت شده است، این پارامتر را تنظیم نکنید. به طور پیش فرض، گوگل نام نمایشی مشخص شده در هنگام ثبت نام را نشان می دهد. اگر در درخواست OAuthGetRequestToken خود یک نام نمایشی تنظیم کنید، Google از این نام به جای نام نمایشی ثبت شده شما استفاده می کند و پیامی مبنی بر اینکه هویت برنامه شما قابل تأیید نیست ارسال می کند.

توجه: برای تنظیم پارامتر xoauth_displayname در OAuth Playground ، قبل از واکشی نشانه درخواست، کادر «پیشرفته» را علامت بزنید.

کار با دامنه های Google Apps

اگر برنامه شما برای کاربرانی در دامنه حساب‌های Google میزبانی شده طراحی شده است، هنگام تأیید یک نشانه، از پارامتر hd استفاده کنید. برای اطلاعات بیشتر در مورد پارامتر hd ، به مدیریت کاربران با چندین حساب مراجعه کنید.

اطلاعات بیشتر در مورد OAuth

برای اطلاعات دقیق در مورد اجرای OAuth توسط Google، از جمله نحوه ثبت برنامه خود و ایجاد پارامترهای OAuth لازم، به این منابع اضافی مراجعه کنید:

استفاده از OAuth با Google Data APIs Client Libraries
مقاله: استفاده از OAuth با Google Data API ، از جمله شرح OAuth Playground، ابزاری تعاملی برای آزمایش OAuth.
OAuth for Web Applications (مستندات کامل)
ثبت نام برای برنامه های کاربردی مبتنی بر وب
تولید کلید و گواهی
مشخصات OAuth

بازگشت به بالا

استفاده از OAuth با برنامه های نصب شده

همه APIهای Google Data از OAuth پشتیبانی می‌کنند، یک استاندارد باز برای مجاز کردن استفاده از داده‌ها در برنامه‌ها. برای استفاده از OAuth، برنامه های نصب شده نیازی به ثبت نام در Google ندارند.

فرآیند مجوز OAuth

فرآیند مجوز OAuth شامل مجموعه ای از تعاملات بین برنامه شما، سرورهای مجوز Google و کاربر نهایی است.

در سطح پایه، فرآیند به شرح زیر است:

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

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

آماده شدن برای OAuth

تعیین محدوده داده هایی که برنامه شما به آن دسترسی خواهد داشت

راه اندازی مکانیزمی برای مدیریت توکن های OAuth

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

اگر برنامه شما از چندین حساب کاربری پشتیبانی می کند، باید پیگیری کنید که هر توکن با کدام حساب مرتبط است.

تنظیم مکانیزمی برای درخواست دسترسی به سرویس Google

برای اطلاعات بیشتر در مورد قالب درخواست مناسب برای هر API Google Data ، به مستندات آن API مراجعه کنید.

کار با توکن های OAuth

دریافت رمز درخواست غیرمجاز ( OAuthGetRequestToken )
مجوز درخواست رمز ( OAuthAuthorizeToken )
رمز درخواست مجاز را با یک نشانه دسترسی مبادله کنید ( OAuthGetAccessToken )

همه درخواست‌های OAuth باید امضا شوند، چه درخواست شما ثبت شده باشد یا نه. برای اطلاعات بیشتر، به امضای درخواست‌های OAuth مراجعه کنید. برنامه های نصب شده باید از دستورالعمل های یک برنامه ثبت نشده پیروی کنند.

می‌توانید با درخواست و دریافت نشانه‌های مجوز در زمین بازی OAuth آزمایش کنید.

برای مستندات دقیق، به مرجع OAuth API مراجعه کنید.

شناسایی اپلیکیشن شما برای کاربران

Google معمولاً هنگام درخواست رضایت دسترسی از کاربر، نام یک برنامه را نمایش می دهد ( به مثال مراجعه کنید ).

از پارامتر xoauth_displayname در درخواست OAuthGetRequestToken خود برای تعیین نام برنامه خود استفاده کنید. اگر آن پارامتر مشخص نشده باشد، Google نام دامنه URL ارائه شده توسط پارامتر oauth_callback را نمایش می دهد. اگر URL بازگشت به تماس ارائه نشود، Google رشته "ناشناس" را نمایش می دهد.

راه اندازی یک مرورگر وب

به عنوان بخشی از فرآیند مجوز OAuth، برنامه شما باید درخواست OAuthAuthorizeToken را ارائه دهد. سپس کاربر باید وارد صفحه وب گوگل شود و درخواست دسترسی برنامه شما را تأیید کند.

حالت تشخیص خودکار باید برای اکثر برنامه ها استفاده شود
حالت دستگاه باید برای برنامه هایی استفاده شود که نمی توانند یک مرورگر وب کامل را راه اندازی کنند.
حالت توسعه باید فقط در مراحل اولیه توسعه استفاده شود.

حالت تشخیص خودکار

در صورت امکان، برنامه شما باید یک پنجره مرورگر راه اندازی کند و یک درخواست OAuthAuthorizeToken برای باز کردن صفحه Google ارائه دهد. وقتی Google توکن مجاز را برمی گرداند، برنامه شما باید این را تشخیص دهد و تمرکز خود را از مرورگر وب به دست آورد.

این حالت مستلزم آن است که یک URL بازگشت به تماس ارائه کنید که کاربر پس از تأیید درخواست دسترسی شما به آن هدایت شود. این URL باید به عنوان پارامتر oauth_callback درخواست OAuthGetRequestToken و به عنوان پارامتر verifier درخواست OAuthGetAccessToken ارائه شود.

برای بهبود تجربه کاربر، برنامه شما باید سعی کند به طور خودکار تشخیص دهد که کاربر به این URL هدایت می شود و بلافاصله خود را در پیش زمینه قرار دهد و یک درخواست OAuthGetAccessToken برای تکمیل فرآیند OAuth ارائه دهد.

برای اطلاعات بیشتر و بهترین شیوه‌ها، به تأیید تشخیص خودکار مراجعه کنید.

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

حالت دستگاه

اگر برنامه شما نمی‌تواند یک مرورگر وب کامل راه‌اندازی کند، این امکان نیز وجود دارد که دستگاه‌های دارای مشتری بدون مرورگر وب مجوز دهند .

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

حالت توسعه

این حالت فقط برای استفاده در مراحل اولیه توسعه یک برنامه کاربردی توصیه می شود.

همانطور که در حالت تشخیص خودکار، برنامه شما باید یک مرورگر راه اندازی کند و کاربر باید درخواست شما را تأیید کند. با این حال، به جای ایجاد یک صفحه وب برای URL بازگشت به تماس، می توانید مقدار پارامتر oauth_callback را روی "oob" (خارج از باند) تنظیم کنید.

در این صورت، پس از تأیید درخواست شما توسط کاربر، Google کاربر را به صفحه حساب‌های Google هدایت می‌کند که شماره تأیید را نشان می‌دهد (به مثال مراجعه کنید).

قبل از اینکه بتوانید درخواست OAuthGetAccessToken را ارائه دهید، کاربر باید به برنامه شما برگردد و شماره تأیید را وارد کند.

اطلاعات بیشتر در مورد OAuth

استفاده از OAuth با Google Data APIs Client Libraries
مقاله: استفاده از OAuth با Google Data API ، از جمله شرح OAuth Playground، ابزاری تعاملی برای آزمایش OAuth.
OAuth برای برنامه های نصب شده (مستندات کامل)
تولید کلید و گواهی
مشخصات OAuth

بازگشت به بالا

استفاده از AuthSub برای مجوز

AuthSub یک API مجوز اختصاصی Google است که به عنوان جایگزینی برای OAuth برای اکثر APIهای Google در دسترس است. در صورت امکان باید از استفاده از AuthSub خودداری کنید. اگر قبلاً برنامه‌هایی دارید که از AuthSub استفاده می‌کنند، باید به OAuth یا پروتکل ترکیبی مهاجرت کنید.

فرآیند مجوز AuthSub

مجوز با AuthSub شامل دنباله ای از تعاملات بین سه نهاد است: برنامه وب، خدمات Google و کاربر. این نمودار توالی را نشان می دهد:

فرآیند مجوز

زمانی که برنامه وب نیاز به دسترسی به سرویس Google کاربر داشته باشد، یک تماس AuthSub با سرویس پروکسی مجوز Google برقرار می کند.
سرویس مجوز با ارائه یک صفحه درخواست دسترسی پاسخ می دهد. این صفحه تحت مدیریت Google از کاربر می‌خواهد که به سرویس Google خود اجازه دهد یا دسترسی نداشته باشد. ممکن است ابتدا از کاربر خواسته شود که وارد حساب کاربری خود شود.
کاربر تصمیم می گیرد که آیا دسترسی به برنامه وب را اعطا کند یا رد کند. اگر کاربر دسترسی را رد کند، به جای بازگشت به برنامه وب، به صفحه Google هدایت می شود.
اگر کاربر اجازه دسترسی بدهد، سرویس مجوز کاربر را به برنامه وب هدایت می کند. تغییر مسیر حاوی یک نشانه مجوز برای یک بار استفاده است. می توان آن را با یک توکن با عمر طولانی معاوضه کرد.
برنامه وب با درخواستی با سرویس Google تماس می گیرد و از کد مجوز استفاده می کند تا به عنوان نماینده کاربر عمل کند.
اگر سرویس Google رمز را بشناسد، داده های درخواستی را ارائه می دهد.

کار با AuthSub

گنجاندن AuthSub در برنامه وب شما به این وظایف نیاز دارد:

تصمیم بگیرید که آیا برنامه وب خود را ثبت کنید یا خیر.
برنامه‌های وب ثبت‌شده این مزیت را دارند که توسط Google شناسایی می‌شوند. اخطار استاندارد نمایش داده شده به کاربران در صفحه ورود به سیستم Google تغییر یا حذف شده است. علاوه بر این، برنامه‌های وب ثبت‌شده به جای صرفاً URL فراخوان، با یک نام توصیفی شناسایی می‌شوند. به خاطر داشته باشید که برخی از سرویس‌های Google تنها به برنامه‌های وب ثبت‌نشده دسترسی محدودی را امکان‌پذیر می‌کنند. اگر تصمیم به ثبت نام دارید، از این فرآیند ثبت نام خودکار استفاده کنید.
در صورت ثبت نام، می توانید گواهی امنیتی و کلیدها را نیز ارائه دهید. برنامه‌های وب ثبت‌شده با گواهی در پرونده می‌توانند نشانه‌های امنی را برای استفاده در هنگام درخواست داده از یک سرویس Google دریافت کنند. (در صورت لزوم می توانند از نشانه های غیر ایمن نیز استفاده کنند.)
تصمیم بگیرید که از چه نوع نشانه هایی استفاده کنید و چگونه آنها را مدیریت کنید.
یک نشانه مجوز دریافت شده از Google در نظر گرفته شده است تا برای تمام تعاملات بعدی با سرویس Google مشخص شده برای آن کاربر استفاده شود. نوع توکنی که برای استفاده انتخاب می‌کنید - یکبار مصرف یا جلسه - به نوع تعاملی که برنامه وب شما با سرویس Google خواهد داشت بستگی دارد. به عنوان مثال، اگر این تعامل یک رویداد یکبار مصرف یا نادر باشد، ممکن است یک توکن یکبار مصرف کافی باشد.
اگر انتخاب کنید که نشانه‌های جلسه را دریافت کنید و به طور منظم از آنها برای دسترسی به سرویس Google استفاده کنید، برنامه وب شما باید ذخیره‌سازی رمز را مدیریت کند، از جمله ردیابی کاربر و سرویس Google که توکن برای آن معتبر است. حساب‌های Google برای مدیریت تعداد زیادی توکن تنظیم نشده است و در واقع اجازه نمی‌دهد بیش از ده توکن معتبر (به‌ازای هر کاربر، برای هر برنامه وب) در هر زمان برجسته باشد. این محدودیت به یک برنامه وب اجازه می دهد تا در صورت لزوم چندین توکن برای پوشش خدمات مختلف دریافت کند. هر بار که برنامه وب نیاز به دسترسی به یک سرویس Google دارد، از دریافت یک توکن جدید پشتیبانی نمی کند. اگر تصمیم به ذخیره نشانه های جلسه دارید، باید با توکن ها به همان اندازه ایمن رفتار شود که هر اطلاعات حساس دیگری که در سرور ذخیره شده است.
از طرف دیگر، تا زمانی که مکانیزم ابطال توکن را تنظیم کرده باشید، می توانید انتخاب کنید که به طور منظم توکن های تازه دریافت کنید. برنامه شما باید قبل از درخواست رمز دیگر، رمز موجود را باطل کند. در این سناریو، کاربر باید هر بار که یک توکن جدید درخواست می‌کند وارد سیستم شود و به آن دسترسی بدهد.
محدوده مورد نیاز سرویس Google را برای دسترسی تعیین کنید.
هر سرویس Google تعیین می کند که چه مقدار و چه نوع دسترسی اجازه می دهد. این دسترسی به عنوان یک مقدار محدوده بیان می شود. محدوده یک سرویس ممکن است یک URL ساده باشد که کل سرویس را شناسایی می کند، یا ممکن است دسترسی محدودتری را مشخص کند. برخی از سرویس ها دسترسی را به شدت محدود می کنند، مانند اجازه دسترسی فقط خواندنی به اطلاعات محدود. برای دریافت محدوده های مجاز برای سرویس Google که می خواهید به آن دسترسی داشته باشید، به اسناد مربوط به آن سرویس مراجعه کنید. شما باید دقیق ترین توکن ممکن را درخواست کنید. برای مثال، اگر می‌خواهید به ویژگی فید Atom جیمیل دسترسی پیدا کنید، از محدوده «http://www.google.com/calendar/feeds/» استفاده کنید، نه «http://www.google.com/calendar/». خدمات Google با درخواست های گسترده بسیار محدودتر است.
مکانیزمی را برای درخواست و دریافت نشانه مجوز تنظیم کنید.
مکانیسم باید یک فراخوانی AuthSubRequest به خوبی شکل بگیرد، از جمله مشخص کردن مقادیر URL بعدی و محدوده مناسب (تعیین شده در مرحله 3). اگر از نشانه‌های امن استفاده می‌کنید و/یا نشانه‌های جلسه را مدیریت می‌کنید، درخواست باید شامل مقادیری برای این متغیرها نیز باشد.
URL بعدی می تواند شامل پارامترهای پرس و جو باشد. به عنوان مثال، هنگام پشتیبانی از چندین زبان، یک پارامتر پرس و جو را اضافه کنید که نسخه برنامه وب را که کاربر در حال مشاهده است، شناسایی می کند. مقدار بعدی http://www.yoursite.com/Retrievetoken?Lang=de منجر به تغییر مسیر http://www.yoursite.com/Retrievetoken?Lang=de&token=DQAADKEDE می شود. تجزیه توکن و پارامتر Lang تضمین می کند که کاربر به نسخه صحیح سایت هدایت می شود.
در شرایط خاص، استفاده از پارامتر hd می‌تواند به ساده‌سازی تجربه کاربران شما در زمانی که از آنها خواسته می‌شود اجازه دسترسی به سایت حساب‌های Google را بدهند، کمک کند. در بیشتر موارد، این فرآیند یک موضوع ساده برای ورود به حساب کاربری آنها و انتخاب اینکه آیا اعطای دسترسی است یا خیر است. با این حال، کاربرانی که بیش از یک حساب Google دارند (یک حساب جی‌میل معمولی و/یا یک یا چند حساب میزبانی شده در Google Apps)، ممکن است نیاز داشته باشند فرآیند «ورود جهانی» اضافی را برای شناسایی حسابی که می‌خواهند به آن دسترسی داشته باشند، دنبال کنند. اگر برنامه شما برای یک دامنه مدیریت شده خاص طراحی شده است، می توانید این مراحل اضافی را با استفاده از این پارامتر برای شناسایی آن دامنه حذف کنید. همچنین اگر برنامه شما به خدماتی دسترسی دارد که در حساب‌های میزبانی شده در دسترس نیستند، می‌توانید از پارامتر hd استفاده کنید - تنظیم مقدار روی «پیش‌فرض» مجوز را فقط به حساب‌های معمولی محدود می‌کند. وقتی مقدار hd تنظیم شد، Google به طور خودکار حساب صحیح را برای مجوز انتخاب می کند.
مکانیسم توکن باید مجهز باشد تا تغییر مسیر دریافت شده از Google را که حاوی توکن یکبار مصرف است، تجزیه کند و با آن اقدام کند. از آنجایی که توکن های مجوز مختص یک کاربر هستند، برنامه شما باید بتواند یک توکن را با کاربر خود مرتبط کند. گزینه ترجیحی این است که قبل از درخواست توکن، یک کوکی برای کاربر صادر کنید. سپس، هنگامی که Google کاربر را با یک توکن ضمیمه شده به سایت شما هدایت می کند، برنامه شما می تواند کوکی را بخواند و توکن را با شناسایی صحیح کاربر مرتبط کند.
مکانیسم‌هایی را برای درخواست نشانه‌های جلسه و ذخیره یا لغو آن‌ها، در صورت لزوم، تنظیم کنید.
بسته به تصمیمات مدیریت توکنی که در مرحله 2 گرفته اید، ممکن است لازم باشد مکانیسم هایی برای دریافت و لغو نشانه های جلسه ایجاد کنید ( AuthSubSessionToken و AuthSubRevokeToken ). برای آزمایش مکانیسم‌های جلسه و ابطال، از AuthSubTokenInfo استفاده کنید، که نشان می‌دهد آیا یک نشانه داده شده معتبر است یا خیر. اگر توکن‌ها را ذخیره می‌کند، برنامه باید هم شناسه کاربر و هم سرویس (حوزه) تحت پوشش توکن را ردیابی کند.
مکانیزمی را برای درخواست دسترسی به سرویس Google تنظیم کنید.
برای اطلاعات در مورد فرمت درخواست مناسب به اسناد سرویس Google مراجعه کنید. همه درخواست‌ها به یک سرویس Google باید شامل یک کد مجوز معتبر باشد. به طور کلی، درخواست به یک سرویس Google به شکل HTTP GET (یا POST در صورت نوشتن داده‌های جدید) است که توکن در سربرگ درخواست ارجاع داده می‌شود.
هدر درخواست باید به شکل زیر باشد:
```
Authorization: AuthSub token="token"
```
جایی که توکن نشانه مجوز، یکبار مصرف یا جلسه است که در پاسخ به درخواست AuthSub از Google دریافت می‌شود. اگر توکن امن است، باید با امضای دیجیتال همراه باشد. برای دستورالعمل‌ها و مثال‌ها به « درخواست‌های امضا » مراجعه کنید.
مثال زیر سرصفحه درخواست برای تماس با سرویس فید تقویم Google را نشان می دهد. این درخواست حاوی یک نشانه غیر ایمن است:
```
GET /calendar/feeds/default/private/full HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AuthSub token="GD32CMCL25aZ-v____8B"
User-Agent: Java/1.5.0_06
Host: www.google.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
```

اطلاعات بیشتر در مورد AuthSub

برای اطلاعات در مورد AuthSub، از جمله ثبت برنامه خود در Google و توضیح مفصل مبادله یک نشانه یک بار مصرف برای یک نشانه جلسه، به این منابع اضافی مراجعه کنید:

احراز هویت AuthSub برای برنامه های کاربردی وب (مستندات کامل)
استفاده از AuthSub با Google Data APIs Client Libraries
تولید کلیدها و گواهینامه ها (AuthSub ایمن)
امضای درخواست با AuthSub (AuthSub ایمن)
ثبت نام برای برنامه های کاربردی مبتنی بر وب

بازگشت به بالا

Using ClientLogin for authorization

ClientLogin is a Google proprietary authorization API, available as an alternative to OAuth for most Google APIs. You should avoid using ClientLogin if possible. If you already have applications that use ClientLogin, you should migrate to OAuth or the hybrid protocol.

Authentication for Installed Applications: ClientLogin

ClientLogin allows your users to log into their Google account from inside your application. The application then contacts Google with the login data and requests access to a specified Google Data API. Once the login information has been successfully authenticated, Google returns a token, which your application will reference each time it requests access to the user's account, such as to get or post data. The token remains valid for a set length of time, defined by whichever Google service you're working with.

Note : The Google Data APIs Client Libraries provide methods to help you use ClientLogin in your installed applications. Specifically, there are methods for acquiring an authentication token, handling CAPTCHA challenges, recalling the auth token for later use, and sending the correct Authorization header with every request. If you are working with one of the libraries, see Using ClientLogin with the Google Data APIs Client Libraries .

The ClientLogin authorization process

Authorization with ClientLogin involves a sequence of interactions between three entities: the installed application, Google services, and the user. This diagram illustrates the sequence:

Authorization process

When the third-party application needs to access a user's Google service, it retrieves the user's login name and password.
The third-party application then makes a ClientLogin call to Google's Authorization service.
If the Google Authorization service decides additional vetting is necessary, it returns failure response with a CAPTCHA token and challenge, in the form of a URL for a CAPTCHA image.
If a CAPTCHA challenge is received, the third-party application displays the CAPTCHA image for the user and solicits an answer from the user.
If requested, the user submits an answer to the CAPTCHA challenge.
The third-party application makes a new ClientLogin call, this time including the CAPTCHA answer and token (received with the failure response).
On a successful login attempt (with or without CAPTCHA challenge), the Google Authorization service returns a token to the application.
The application contacts the Google service with a request for data access, referencing the token received from the Google Authorization service.
If the Google service recognizes the token, it supplies the requested data access.

Using ClientLogin

Use this interface in your installed application to programmatically access a user's Google account. After collecting login information from the user, call ClientLogin to request access to the user's account. Once the login information has been successfully authenticated, Google returns a token, which your application will reference each time it requests access to the user's account. The token remains valid for a set length of time, which is defined by whichever Google service you're working with.

Incorporating ClientLogin into your application requires these tasks:

Create a UI element to capture login data from the user.
The UI needs to solicit a user name (email address including domain) and password. The UI should also be capable of displaying a CAPTCHA image using the URL received from Google, if one is required, and soliciting a correct answer from the user. Ideally, your UI will include a link to Google Accounts login page ("https://www.google.com/accounts/Login") in the event that the user needs to sign up for a new account or do other account maintenance.
Write code to generate a well-formed HTTPS POST ClientLogin request and transmit it.
This code needs to contain logic to handle a CAPTCHA challenge and include both the logintoken and logincaptcha parameters. The application should also be able to detect when the user omits required information--or repeats incorrect data after a login failure--and display an error without sending a superfluous request.
Handle responses from Google.
There are four possible responses to a login request:
- success (an HTTP 200)
- failure (an HTTP 403) with an explanatory error code
- invalid request, generally resulting from a malformed request
- failure with a CAPTCHA challenge
A success response contains an authorization token labeled "Auth". This token must be included in all subsequent requests to the Google service for this account. Authorization tokens should be closely guarded and should not be given to any other application, as they represent access to the user's account. The time limit on the token varies depending on which service issued it.
A failure response includes one or more error codes and a URL with the error message that can be displayed for the user. Please note that ClientLogin does not differentiate between a failure due to an incorrect password or one due to an unrecognized user name (for example, if the user has not yet signed up for an account). Your application needs to handle all possible error messages as appropriate.
A failure response with a CAPTCHA challenge means that Google has decided, for whatever reason, that additional security measures should be taken. This response is accompanied by a CAPTCHA image URL and a token representing the specific CAPTCHA challenge.
Handle a CAPTCHA challenge from Google.
To handle the challenge, the application must display the CAPTCHA image and solicit an answer from the user. To display the CAPTCHA image, use the value of CaptchaUrl returned with the failure response, prefixing it with the Google Accounts URL: "http://www.google.com/accounts/". Once the user provides an answer, the application should resend the login request, this time including the CAPTCHA token ( logintoken ) and the user's answer ( logincaptcha ). Google validates the user's answer before authorizing access to the account.
There is an alternative for developers who do not want to manage the process's of getting and transmitting a user CAPTCHA response. In response to a CAPTCHA challenge, the application can direct the user to the Google hosted page: "https://www.google.com/accounts/DisplayUnlockCaptcha". Once the user has successfully responded to the challenge, the Google server trusts the computer in use. The application can then resend the original login request to obtain the authorization token.

Note: Google does not validate the login attempt prior to issuing a CAPTCHA challenge. This means a login attempt could fail even after a CAPTCHA challenge.

* CAPTCHA is a trademark of Carnegie Mellon University

بازگشت به بالا

Authentication for Gadgets

OAuth Proxy

If you're building a gadget using the standard Gadgets API , you can leverage a feature of the gadget platform called the OAuth Proxy to access the Google Data APIs. OAuth ( described above ) is an authentication standard that allows users to access their private data in a gadget hosting service such as iGoogle, MySpace, or Orkut, or share their data with another website or gadget. The OAuth Proxy is designed to make development easier for gadget developers by hiding many of OAuth's authentication details. The Proxy is based on an open-source project called Shindig , which is an implementation of the gadget specification.

Note : The OAuth Proxy is only supported for gadgets that use the gadgets.* API and run in OpenSocial containers. It is not supported for the legacy gadgets API .

Authentication flow

Your gadget must obtain an OAuth token before it can access a user's data. The OAuth Proxy manages the authentication flow for you. The first time a user installs your gadget, the following process takes place:

Your gadget loads for the first time and attempts to access the user's data using one of the Google Data APIs.
The request fails because the user hasn't granted access. The response object contains a URL (in response.oauthApprovalUrl ) for the OAuth approval page. Your gadget should provide a method to launch a new window with that URL.
On the approval page, the user chooses to grant or deny access to your gadget. If successful, the user is taken to the oauth_callback page you specify. For the best user experience, use http://oauth.gmodules.com/gadgets/oauthcallback .
Next, the user closes the popup window. To notify your gadget that the user has approved, you can use a popup handler to detect the approval window closing. Alternatively, your gadget can display a link (eg " I've approved access ") for the user to click after this window closes.
Your gadget attempts to access the Google Data API a second time by re-requesting the user's data. This attempt is successful.
Your gadget is authenticated and can begin operating normally.

Gadget setup

To access one or more of the Google Data APIs, you first need to tell your gadget to use OAuth as the authentication method. Add an <OAuth> element in the <ModulePrefs> section of your gadget's XML:

<ModulePrefs>
...
<OAuth>
  <Service name="google">
    <Access url="https://www.google.com/accounts/OAuthGetAccessToken" method="GET" />
    <Request url="https://www.google.com/accounts/OAuthGetRequestToken?
                  scope=http://www.blogger.com/feeds/%20http://www.google.com/calendar/feeds/" method="GET" />
    <Authorization url="https://www.google.com/accounts/OAuthAuthorizeToken?
                        oauth_callback=http://oauth.gmodules.com/gadgets/oauthcallback" />
  </Service>
</OAuth>
...
</ModulePrefs>

In this section, only change the following query parameters:

scope: A required parameter in the Request URL. Your gadget can access data from the scope (s) used in this parameter. In this example, the gadget can access Blogger and Calendar data. A gadget can request data for a single scope or multiple scopes, as this example does.
oauth_callback: An optional parameter in the Authorization URL. The OAuth approval page redirects to this URL after the user has approved access to data. You should set this parameter to http://oauth.gmodules.com/gadgets/oauthcallback to provide the best user experience when users install your gadget. That page provides a snippet of JavaScript that automatically closes the popup window. Alternatively, you can set this parameter to point to your own "approved" page, or you can simply leave the parameter blank.

Accessing an authenticated Google Data API feed

Once your gadget has authenticated the user, accessing a Google Data API is straightforward with the Google Data APIs JavaScript client library. For information on how to use the library in the OAuth Proxy, see Using the JavaScript Client Library .

More information about Gadgets

For complete information on creating Google Data API Gadgets, including details on the OAuth Proxy, an article on how to get started, and the gadgets.* spec, see these additional resources:

Using the JavaScript Client Library
Creating a Google Data APIs Gadget (article)
Writing OAuth Gadgets (full gadget documentation)
Gadgets API documentation

بازگشت به بالا