OAuth 2.0 برای برنامه های iOS و دسکتاپ

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

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

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

این جریان مجوزدهی مشابه جریانی است که برای برنامه‌های وب سرور استفاده می‌شود. تفاوت اصلی این است که برنامه‌های نصب شده باید مرورگر سیستم را باز کنند و یک URI تغییر مسیر محلی برای مدیریت پاسخ‌های سرور مجوزدهی گوگل ارائه دهند.

کتابخانه‌ها و نمونه‌ها

برای برنامه‌های iOS، توصیه می‌کنیم از آخرین نسخهٔ « Sign In With Google iOS SDK» استفاده کنید. این SDK مجوزدهی کاربر را مدیریت می‌کند و پیاده‌سازی آن نسبت به پروتکل سطح پایین‌تری که در این راهنما توضیح داده شده، ساده‌تر است.

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

پیش‌نیازها

فعال کردن APIها برای پروژه شما

هر برنامه‌ای که APIهای گوگل را فراخوانی می‌کند، باید آن APIها را در ... فعال کند. API Console.

برای فعال کردن API برای پروژه خود:

  1. Open the API Library در Google API Console.
  2. If prompted, select a project, or create a new one.
  3. API Library تمام APIهای موجود را که بر اساس خانواده محصول و محبوبیت گروه‌بندی شده‌اند، فهرست می‌کند. اگر API مورد نظر برای فعال‌سازی در لیست قابل مشاهده نیست، از جستجو برای یافتن آن استفاده کنید یا روی مشاهده همه در خانواده محصولی که به آن تعلق دارد کلیک کنید.
  4. API مورد نظر خود را انتخاب کنید و سپس روی دکمه‌ی فعال‌سازی کلیک کنید.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

ایجاد اعتبارنامه‌های مجوز

هر برنامه‌ای که از OAuth 2.0 برای دسترسی به APIهای گوگل استفاده می‌کند، باید دارای اعتبارنامه‌های احراز هویت باشد که برنامه را به سرور OAuth 2.0 گوگل معرفی کند. مراحل زیر نحوه ایجاد اعتبارنامه برای پروژه شما را توضیح می‌دهد. سپس برنامه‌های شما می‌توانند از این اعتبارنامه‌ها برای دسترسی به APIهایی که برای آن پروژه فعال کرده‌اید، استفاده کنند.

  1. Go to the Clients page.
  2. روی ایجاد کلاینت کلیک کنید.
  3. بخش‌های زیر انواع کلاینت‌هایی را که سرور تأیید گوگل پشتیبانی می‌کند، شرح می‌دهند. نوع کلاینتی را که برای برنامه شما توصیه می‌شود انتخاب کنید، کلاینت OAuth خود را نامگذاری کنید و سایر فیلدهای فرم را به صورت مناسب تنظیم کنید.
آی‌او‌اس
  1. نوع اپلیکیشن iOS را انتخاب کنید.
  2. یک نام برای کلاینت OAuth وارد کنید. این نام در پوشه پروژه شما نمایش داده می‌شود. Clients page برای شناسایی مشتری.
  3. شناسه بسته نرم‌افزاری برنامه خود را وارد کنید. شناسه بسته نرم‌افزاری، مقدار کلید CFBundleIdentifier در فایل منبع لیست ویژگی اطلاعات برنامه شما ( info.plist ) است. این مقدار معمولاً در قسمت General یا قسمت Signing & Capabilities ویرایشگر پروژه Xcode نمایش داده می‌شود. شناسه بسته نرم‌افزاری همچنین در بخش General Information صفحه App Information برنامه در سایت App Store Connect اپل نمایش داده می‌شود.

    تأیید کنید که از شناسه بسته صحیح برای برنامه خود استفاده می‌کنید، زیرا اگر از ویژگی بررسی برنامه استفاده می‌کنید، نمی‌توانید آن را تغییر دهید.

  4. (اختیاری)

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

    1. برنامه Apple App Store را در دستگاه iOS یا iPadOS خود باز کنید.
    2. برنامه خود را جستجو کنید.
    3. دکمه اشتراک‌گذاری (علامت مربع و فلش رو به بالا) را انتخاب کنید.
    4. کپی کردن پیوند را انتخاب کنید.
    5. لینک را در یک ویرایشگر متن جایگذاری کنید. شناسه اپ استور بخش پایانی URL است.

      مثال: https://apps.apple.com/app/google/id 284815942

  5. (اختیاری)

    شناسه تیم خود را وارد کنید. برای اطلاعات بیشتر به بخش «شناسه تیم خود را در مستندات حساب توسعه‌دهنده اپل پیدا کنید» مراجعه کنید.

    توجه: اگر App Check را برای کلاینت خود فعال می‌کنید، فیلد Team ID الزامی است.
  6. (اختیاری)

    بررسی برنامه (App Check) را برای برنامه iOS خود فعال کنید. وقتی بررسی برنامه (App Check) را فعال می‌کنید، از سرویس App Attest اپل برای تأیید صحت درخواست‌های OAuth 2.0 که از کلاینت OAuth شما ارسال می‌شوند و از برنامه شما می‌آیند، استفاده می‌شود. این به کاهش خطر جعل هویت برنامه کمک می‌کند. درباره فعال کردن بررسی برنامه (App Check) برای برنامه iOS خود بیشتر بدانید .

  7. روی ایجاد کلیک کنید.
یو دبلیو پی
  1. نوع برنامه Universal Windows Platform را انتخاب کنید.
  2. یک نام برای کلاینت OAuth وارد کنید. این نام در پوشه پروژه شما نمایش داده می‌شود. Clients page برای شناسایی مشتری.
  3. شناسه فروشگاه مایکروسافت ۱۲ کاراکتری برنامه خود را وارد کنید. می‌توانید این مقدار را در مرکز شرکای مایکروسافت در صفحه شناسه برنامه در بخش مدیریت برنامه پیدا کنید.
  4. روی ایجاد کلیک کنید.

برای برنامه‌های UWP، آدرس اینترنتی (URI) ریدایرکت با استفاده از شناسه امنیتی بسته (SID) منحصر به فرد برنامه شما تشکیل می‌شود. می‌توانید Package SID برنامه خود را در فایل Package.appxmanifest در پروژه ویژوال استودیو خود پیدا کنید.

وقتی شناسه کلاینت خود را در کنسول Google Cloud ایجاد می‌کنید، باید URI تغییر مسیر را با فرمت زیر و با استفاده از مقدار حروف کوچک Package SID خود مشخص کنید:

ms-app://YOUR_APP_PACKAGE_SID

برای برنامه‌های UWP، طرح URI سفارشی نمی‌تواند بیش از ۳۹ کاراکتر باشد، همانطور که در مستندات مایکروسافت مشخص شده است.

شناسایی محدوده‌های دسترسی

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

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

سند OAuth 2.0 API Scopes شامل لیست کاملی از scopeهایی است که ممکن است برای دسترسی به APIهای گوگل از آنها استفاده کنید.

دریافت توکن‌های دسترسی OAuth 2.0

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

مرحله ۱: ایجاد یک تأییدکننده کد و چالش

گوگل از پروتکل Proof Key for Code Exchange (PKCE) پشتیبانی می‌کند تا جریان برنامه نصب شده را ایمن‌تر کند. برای هر درخواست مجوز، یک تأییدکننده کد منحصر به فرد ایجاد می‌شود و مقدار تبدیل‌شده آن، به نام "code_challenge"، برای دریافت کد مجوز به سرور مجوز ارسال می‌شود.

تأییدکننده کد را ایجاد کنید

یک code_verifier ​​یک رشته تصادفی رمزنگاری با آنتروپی بالا است که از کاراکترهای بدون رزرو [AZ] / [az] / [0-9] / "-" / "." / "_" / "~" با حداقل طول ۴۳ کاراکتر و حداکثر طول ۱۲۸ کاراکتر استفاده می‌کند.

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

چالش کد را ایجاد کنید

دو روش برای ایجاد چالش کد پشتیبانی می‌شود.

روش‌های تولید چالش کد
S256 (توصیه می‌شود) چالش کد، هش SHA256 کدگذاری شده Base64URL (بدون padding) از تأییدکننده کد است.
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
ساده چالش کد همان مقداری است که تأییدکننده کد تولید شده در بالا دارد.
code_challenge = code_verifier

مرحله ۲: ارسال درخواست به سرور OAuth 2.0 گوگل

برای دریافت مجوز کاربر، درخواستی را به سرور مجوز گوگل به آدرس https://accounts.google.com/o/oauth2/v2/auth ارسال کنید. این نقطه پایانی، جستجوی فعال نشست را مدیریت می‌کند، کاربر را احراز هویت می‌کند و رضایت کاربر را دریافت می‌کند. این نقطه پایانی فقط از طریق SSL قابل دسترسی است و اتصالات HTTP (غیر SSL) را رد می‌کند.

سرور احراز هویت از پارامترهای رشته پرس و جوی زیر برای برنامه‌های نصب شده پشتیبانی می‌کند:

پارامترها
client_id مورد نیاز

شناسه کلاینت برای برنامه شما. می‌توانید این مقدار را در Cloud ConsoleClients page.

redirect_uri مورد نیاز

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

این مقدار باید دقیقاً با یکی از URI های تغییر مسیر مجاز برای کلاینت OAuth 2.0 که در کلاینت خود پیکربندی کرده‌اید، مطابقت داشته باشد. Cloud ConsoleClients pageاگر این مقدار با یک URI مجاز مطابقت نداشته باشد، خطای redirect_uri_mismatch دریافت خواهید کرد.

جدول مقدار پارامتر redirect_uri مناسب برای هر روش را نشان می‌دهد:

مقادیر redirect_uri
طرح URI سفارشی com.example.app : redirect_uri_path

یا

com.googleusercontent.apps.123 : redirect_uri_path
  • com.example.app نماد DNS معکوس دامنه تحت کنترل شماست. طرح سفارشی باید شامل یک نقطه باشد تا معتبر باشد.
  • com.googleusercontent.apps.123 نماد DNS معکوس شناسه کلاینت است.
  • redirect_uri_path یک جزء مسیر اختیاری است، مانند /oauth2redirect . توجه داشته باشید که مسیر باید با یک اسلش شروع شود، که با URL های HTTP معمولی متفاوت است.
آدرس IP حلقه برگشتی http://127.0.0.1: port یا http://[::1]: port

آدرس IP مربوط به loopback را از پلتفرم خود جستجو کنید و یک شنونده HTTP را روی یک پورت تصادفی موجود شروع کنید. port با شماره پورت واقعی که برنامه شما به آن گوش می‌دهد، جایگزین کنید.

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

response_type مورد نیاز

تعیین می‌کند که آیا نقطه پایانی Google OAuth 2.0 کد مجوز را برمی‌گرداند یا خیر.

مقدار پارامتر را برای برنامه‌های نصب شده روی code تنظیم کنید.

scope مورد نیاز

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

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

code_challenge توصیه شده

یک code_verifier کدگذاری شده را مشخص می‌کند که به عنوان یک چالش سمت سرور در طول تبادل کد مجوز استفاده خواهد شد. برای اطلاعات بیشتر به create code challenge مراجعه کنید.

code_challenge_method توصیه شده

مشخص می‌کند که از چه روشی برای رمزگذاری یک code_verifier که در طول تبادل کد مجوز استفاده خواهد شد، استفاده شده است. این پارامتر باید با پارامتر code_challenge استفاده شود. مقدار code_challenge_method در صورت عدم وجود در درخواستی که شامل code_challenge است، به صورت پیش‌فرض روی plain تنظیم می‌شود. تنها مقادیر پشتیبانی شده برای این پارامتر S256 یا plain هستند.

state توصیه شده

هر مقدار رشته‌ای را که برنامه شما برای حفظ وضعیت بین درخواست مجوز شما و پاسخ سرور مجوز استفاده می‌کند، مشخص می‌کند. سرور پس از اینکه کاربر درخواست دسترسی برنامه شما را تأیید یا رد کرد، مقدار دقیقی را که شما به عنوان یک جفت name=value در شناسه قطعه URL ( # ) از redirect_uri ارسال می‌کنید، برمی‌گرداند.

شما می‌توانید از این پارامتر برای چندین هدف استفاده کنید، مانند هدایت کاربر به منبع صحیح در برنامه‌تان، ارسال nonceها و کاهش جعل درخواست بین سایتی. از آنجایی که redirect_uri شما قابل حدس زدن است، استفاده از مقدار state می‌تواند اطمینان شما را از اینکه اتصال ورودی نتیجه یک درخواست احراز هویت است، افزایش دهد. اگر یک رشته تصادفی ایجاد کنید یا هش یک کوکی یا مقدار دیگری را که وضعیت کلاینت را ثبت می‌کند، کدگذاری کنید، می‌توانید پاسخ را اعتبارسنجی کنید تا علاوه بر این، اطمینان حاصل شود که درخواست و پاسخ از یک مرورگر سرچشمه گرفته‌اند و در برابر حملاتی مانند جعل درخواست بین سایتی محافظت ایجاد کنید. برای مثالی از نحوه ایجاد و تأیید یک توکن state ، به مستندات OpenID Connect مراجعه کنید.

login_hint اختیاری

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

مقدار پارامتر را روی یک آدرس ایمیل یا شناسه sub تنظیم کنید، که معادل شناسه گوگل کاربر است.

نمونه URL های مجوز

تب‌های زیر نمونه‌هایی از URLهای مجوزدهی را برای گزینه‌های مختلف URI ریدایرکت نشان می‌دهند.

URLها به جز مقدار پارامتر redirect_uri یکسان هستند. URLها همچنین شامل پارامترهای الزامی response_type و client_id و همچنین پارامتر اختیاری state هستند. هر URL شامل پرش به خط جدید و فاصله برای خوانایی بیشتر است.

طرح URI سفارشی 

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

آدرس IP حلقه برگشتی 

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

مرحله ۳: گوگل از کاربر رضایت می‌خواهد

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

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

خطاها

درخواست‌ها به نقطه پایانی احراز هویت OAuth 2.0 گوگل ممکن است به جای جریان‌های احراز هویت و مجوز مورد انتظار، پیام‌های خطای کاربرپسند را نمایش دهند. کدهای خطای رایج و راه‌حل‌های پیشنهادی عبارتند از:

admin_policy_enforced

حساب گوگل به دلیل سیاست‌های مدیر Google Workspace خود قادر به تأیید یک یا چند محدوده درخواستی نیست. برای اطلاعات بیشتر در مورد اینکه چگونه یک مدیر می‌تواند دسترسی به همه محدوده‌ها یا محدوده‌های حساس و محدود شده را تا زمانی که دسترسی به طور صریح به شناسه کلاینت OAuth شما اعطا نشده باشد، محدود کند، به مقاله راهنمای مدیریت Google Workspace با عنوان «کنترل دسترسی برنامه‌های شخص ثالث و داخلی به داده‌های Google Workspace» مراجعه کنید.

disallowed_useragent

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

توسعه‌دهندگان iOS و macOS ممکن است هنگام باز کردن درخواست‌های مجوز در WKWebView با این خطا مواجه شوند. توسعه‌دهندگان باید به جای آن از کتابخانه‌های iOS مانند Google Sign-In برای iOS یا OpenID Foundation’s AppAuth برای iOS استفاده کنند.

توسعه‌دهندگان وب ممکن است زمانی که یک برنامه iOS یا macOS یک لینک وب عمومی را در یک عامل کاربر تعبیه‌شده باز می‌کند و کاربر از سایت شما به نقطه پایانی مجوز OAuth 2.0 گوگل هدایت می‌شود، با این خطا مواجه شوند. توسعه‌دهندگان باید اجازه دهند لینک‌های عمومی در کنترل‌کننده لینک پیش‌فرض سیستم عامل، که شامل کنترل‌کننده‌های لینک جهانی یا برنامه مرورگر پیش‌فرض است، باز شوند. کتابخانه SFSafariViewController نیز یک گزینه پشتیبانی شده است.

org_internal

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

deleted_client

کلاینت OAuth که برای ایجاد درخواست استفاده شده بود، حذف شده است. حذف می‌تواند به صورت دستی یا خودکار در مورد کلاینت‌های بلااستفاده انجام شود. کلاینت‌های حذف شده را می‌توان ظرف 30 روز از زمان حذف بازیابی کرد. اطلاعات بیشتر .

invalid_grant

اگر از یک تأییدکننده کد و چالش استفاده می‌کنید، پارامتر code_callenge نامعتبر است یا وجود ندارد. مطمئن شوید که پارامتر code_challenge به درستی تنظیم شده است.

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

redirect_uri_mismatch

redirect_uri ارسال شده در درخواست مجوز با یک URI تغییر مسیر مجاز برای شناسه کلاینت OAuth مطابقت ندارد. URI های تغییر مسیر مجاز را در Google Cloud ConsoleClients page.

ممکن است redirect_uri ارسالی برای نوع کلاینت نامعتبر باشد.

پارامتر redirect_uri ممکن است به جریان OAuth out-of-band (OOB) اشاره داشته باشد که منسوخ شده و دیگر پشتیبانی نمی‌شود. برای به‌روزرسانی ادغام خود به راهنمای مهاجرت مراجعه کنید.

invalid_request

درخواستی که ارائه دادید، مشکلی داشت. این مشکل می‌تواند به دلایل مختلفی باشد:

  • درخواست به درستی قالب بندی نشده است
  • درخواست پارامترهای مورد نیاز را نداشت
  • این درخواست از روش احراز هویتی استفاده می‌کند که گوگل از آن پشتیبانی نمی‌کند. تأیید کنید که ادغام OAuth شما از روش ادغام توصیه‌شده استفاده می‌کند.
  • یک طرح سفارشی پشتیبانی نشده برای uri تغییر مسیر استفاده شده است. اگر پیام خطای «طرح URI سفارشی در برنامه‌های اندروید یا کروم پشتیبانی نمی‌شود» را مشاهده کردید، درباره جایگزین‌های طرح URI سفارشی بیشتر بدانید .

مرحله ۴: مدیریت پاسخ سرور OAuth 2.0

نحوه دریافت پاسخ مجوز توسط برنامه شما به طرح URI ریدایرکتی که استفاده می‌کند بستگی دارد. صرف نظر از این طرح، پاسخ یا حاوی یک کد مجوز ( code ) یا یک خطا ( error ) خواهد بود. به عنوان مثال، error=access_denied نشان می‌دهد که کاربر درخواست را رد کرده است.

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

مرحله ۵: کد مجوز را با توکن‌های به‌روزرسانی و دسترسی مبادله کنید

برای تبادل کد مجوز با یک توکن دسترسی، با نقطه پایانی https://oauth2.googleapis.com/token تماس بگیرید و پارامترهای زیر را تنظیم کنید:

فیلدها
client_id شناسه کلاینت به دست آمده از Cloud ConsoleClients page.
client_secret اختیاری

راز مشتری که از ... به دست آمده است Cloud ConsoleClients page.

code کد مجوزی که از درخواست اولیه برگردانده شده است.
code_verifier تأییدکننده کدی که در مرحله ۱ ایجاد کردید.
grant_type همانطور که در مشخصات OAuth 2.0 تعریف شده است ، مقدار این فیلد باید روی authorization_code تنظیم شود.
redirect_uri یکی از آدرس‌های اینترنتی تغییر مسیر ذکر شده برای پروژه شما در Cloud ConsoleClients page برای client_id داده شده.

قطعه کد زیر یک نمونه درخواست را نشان می‌دهد:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

گوگل با برگرداندن یک شیء JSON که شامل یک توکن دسترسی کوتاه‌مدت و یک توکن به‌روزرسانی است، به این درخواست پاسخ می‌دهد.

پاسخ شامل فیلدهای زیر است:

فیلدها
access_token توکنی که برنامه شما برای تأیید درخواست API گوگل ارسال می‌کند.
expires_in طول عمر باقی مانده از توکن دسترسی بر حسب ثانیه.
id_token توجه: این ویژگی فقط در صورتی برگردانده می‌شود که درخواست شما شامل یک محدوده هویت، مانند openid ، profile یا email باشد. مقدار آن یک JSON Web Token (JWT) است که حاوی اطلاعات هویتی امضا شده دیجیتالی در مورد کاربر است.
refresh_token توکنی که می‌توانید از آن برای دریافت یک توکن دسترسی جدید استفاده کنید. توکن‌های به‌روزرسانی تا زمانی که کاربر دسترسی را لغو کند یا توکن به‌روزرسانی منقضی شود، معتبر هستند. توجه داشته باشید که توکن‌های به‌روزرسانی همیشه برای برنامه‌های نصب شده بازگردانده می‌شوند.
refresh_token_expires_in طول عمر باقیمانده‌ی توکن به‌روزرسانی بر حسب ثانیه. این مقدار فقط زمانی تنظیم می‌شود که کاربر دسترسی مبتنی بر زمان را اعطا کند.
scope دامنه‌های دسترسی اعطا شده توسط access_token به صورت فهرستی از رشته‌های جدا شده با فاصله و حساس به حروف بزرگ و کوچک بیان می‌شوند.
token_type نوع توکن برگشتی. در حال حاضر، مقدار این فیلد همیشه روی Bearer تنظیم می‌شود.

قطعه کد زیر یک نمونه پاسخ را نشان می‌دهد:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

مرحله ۶: بررسی کنید که کاربران کدام حوزه‌ها را اعطا کرده‌اند

هنگام درخواست چندین مجوز (اسکوپ)، کاربران ممکن است به برنامه شما اجازه دسترسی به همه آنها را ندهند. برنامه شما باید تأیید کند که کدام اسکوپ‌ها واقعاً اعطا شده‌اند و به طور مناسب موقعیت‌هایی را که برخی از مجوزها رد می‌شوند، مدیریت کند، معمولاً با غیرفعال کردن ویژگی‌هایی که به آن اسکوپ‌های رد شده متکی هستند.

با این حال، استثنائاتی نیز وجود دارد. برنامه‌های Google Workspace Enterprise با تفویض اختیار در سطح دامنه یا برنامه‌هایی که به عنوان Trusted علامت‌گذاری شده‌اند، صفحه رضایت مجوزهای جزئی را دور می‌زنند. برای این برنامه‌ها، کاربران صفحه رضایت مجوزهای جزئی را نمی‌بینند. در عوض، برنامه شما یا همه محدوده‌های درخواستی را دریافت می‌کند یا هیچ کدام را دریافت نمی‌کند.

برای اطلاعات بیشتر، به نحوه مدیریت مجوزهای جزئی مراجعه کنید.

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

برای مثال، نمونه پاسخ توکن دسترسی زیر نشان می‌دهد که کاربر به برنامه شما دسترسی به مجوزهای فعالیت Drive فقط خواندنی و رویدادهای Calendar را اعطا کرده است:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

فراخوانی API های گوگل

پس از اینکه برنامه شما یک توکن دسترسی دریافت کرد، می‌توانید از این توکن برای برقراری تماس با یک API گوگل از طرف یک حساب کاربری مشخص استفاده کنید، البته اگر محدوده(های) دسترسی مورد نیاز API اعطا شده باشد. برای انجام این کار، توکن دسترسی را با وارد کردن پارامتر پرس‌وجوی access_token یا مقدار Bearer هدر HTTP Authorization ، در درخواست به API قرار دهید. در صورت امکان، هدر HTTP ترجیح داده می‌شود، زیرا رشته‌های پرس‌وجو معمولاً در گزارش‌های سرور قابل مشاهده هستند. در بیشتر موارد، می‌توانید از یک کتابخانه کلاینت برای تنظیم تماس‌های خود با APIهای گوگل استفاده کنید (برای مثال، هنگام فراخوانی API فایل‌های درایو ).

شما می‌توانید تمام APIهای گوگل را امتحان کنید و حوزه‌های کاربرد آنها را در OAuth 2.0 Playground مشاهده کنید.

مثال‌های HTTP GET

فراخوانی نقطه پایانی drive.files (رابط برنامه‌نویسی کاربردی Drive Files) با استفاده از هدر HTTP مربوط به Authorization: Bearer ممکن است چیزی شبیه به شکل زیر باشد. توجه داشته باشید که باید توکن دسترسی خودتان را مشخص کنید: 

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

در اینجا فراخوانی همان API برای کاربر احراز هویت شده با استفاده از پارامتر رشته پرس و جوی access_token مشاهده می‌کنید: 

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

مثال‌های curl

می‌توانید این دستورات را با برنامه خط فرمان curl آزمایش کنید. در اینجا مثالی آورده شده است که از گزینه هدر HTTP (ترجیحاً) استفاده می‌کند: 

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

یا، به طور جایگزین، گزینه پارامتر رشته پرس و جو: 

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

به‌روزرسانی یک توکن دسترسی

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

برای به‌روزرسانی یک توکن دسترسی، برنامه شما یک درخواست HTTPS POST به سرور احراز هویت گوگل ( https://oauth2.googleapis.com/token ) ارسال می‌کند که شامل پارامترهای زیر است:

فیلدها
client_id شناسه کلاینت به دست آمده از API Console.
client_secret اختیاری

راز مشتری که از ... به دست آمده است API Console( client_secret برای درخواست‌های کلاینت‌هایی که به عنوان برنامه‌های اندروید، iOS یا کروم ثبت شده‌اند، قابل اجرا نیست.)

grant_type همانطور که در مشخصات OAuth 2.0 تعریف شده است ، مقدار این فیلد باید برابر با refresh_token تنظیم شود.
refresh_token توکن به‌روزرسانی که از تبادل کد مجوز بازگردانده شده است.

قطعه کد زیر یک نمونه درخواست را نشان می‌دهد: 

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
refresh_token=refresh_token&
grant_type=refresh_token

تا زمانی که کاربر دسترسی اعطا شده به برنامه را لغو نکرده باشد، سرور توکن یک شیء JSON را که حاوی یک توکن دسترسی جدید است، برمی‌گرداند. قطعه کد زیر یک نمونه پاسخ را نشان می‌دهد: 

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

توجه داشته باشید که محدودیت‌هایی در تعداد توکن‌های به‌روزرسانی که صادر می‌شوند وجود دارد؛ یک محدودیت برای هر ترکیب کلاینت/کاربر، و محدودیت دیگر برای هر کاربر در تمام کلاینت‌ها. شما باید توکن‌های به‌روزرسانی را در حافظه بلندمدت ذخیره کنید و تا زمانی که معتبر هستند، به استفاده از آنها ادامه دهید. اگر برنامه شما توکن‌های به‌روزرسانی زیادی درخواست کند، ممکن است با این محدودیت‌ها مواجه شود، که در این صورت توکن‌های به‌روزرسانی قدیمی‌تر از کار می‌افتند.

ابطال توکن

در برخی موارد، کاربر ممکن است بخواهد دسترسی داده شده به یک برنامه را لغو کند. کاربر می‌تواند با مراجعه به تنظیمات حساب ، دسترسی را لغو کند. برای اطلاعات بیشتر، به بخش «حذف دسترسی سایت یا برنامه» در سند پشتیبانی سایت‌ها و برنامه‌های شخص ثالث با دسترسی به حساب شما مراجعه کنید.

همچنین ممکن است یک برنامه به صورت برنامه‌نویسی‌شده دسترسی‌های داده‌شده به خود را لغو کند. لغو برنامه‌ریزی‌شده در مواردی که کاربر اشتراک خود را لغو می‌کند، برنامه را حذف می‌کند یا منابع API مورد نیاز یک برنامه به‌طور قابل‌توجهی تغییر کرده است، مهم است. به عبارت دیگر، بخشی از فرآیند حذف می‌تواند شامل یک درخواست API باشد تا اطمینان حاصل شود که مجوزهایی که قبلاً به برنامه اعطا شده است، حذف می‌شوند.

برای لغو یک توکن از طریق برنامه‌نویسی، برنامه شما درخواستی به https://oauth2.googleapis.com/revoke ارسال می‌کند و توکن را به عنوان پارامتر وارد می‌کند: 

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

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

اگر ابطال با موفقیت پردازش شود، کد وضعیت HTTP پاسخ 200 است. برای شرایط خطا، کد وضعیت HTTP 400 به همراه یک کد خطا بازگردانده می‌شود.

روش‌های تغییر مسیر برنامه

طرح URI سفارشی

طرح‌های URI سفارشی نوعی از دیپ‌لینک هستند که از یک طرح تعریف‌شده‌ی سفارشی برای باز کردن برنامه‌ی شما استفاده می‌کنند.

جایگزینی برای استفاده از طرح‌های URI سفارشی در برنامه‌های Chrome

از API هویت کروم استفاده کنید که پاسخ OAuth 2.0 را مستقیماً به برنامه شما ارائه می‌دهد و نیاز به یک URL تغییر مسیر را از بین می‌برد.

آدرس IP حلقه‌ای (macOS، لینوکس، ویندوز دسکتاپ)

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

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

میزان مصرف توصیه شده برنامه‌های دسکتاپ macOS، لینوکس و ویندوز (اما نه پلتفرم جهانی ویندوز)
مقادیر فرم نوع برنامه را روی برنامه دسکتاپ تنظیم کنید.

کپی/پیست دستی (منسوخ شده)

از برنامه‌های خود محافظت کنید

تأیید مالکیت برنامه برای Chrome

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

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

  • شما باید یک آیتم ثبت‌شده در داشبورد توسعه‌دهندگان فروشگاه وب کروم با شناسه‌ی آیتم مشابه با کلاینت OAuth افزونه‌ی کرومی که در حال تکمیل تأیید اعتبار برای آن هستید، داشته باشید.
  • شما باید ناشر آیتم فروشگاه وب کروم باشید. برای کسب اطلاعات بیشتر در مورد مدیریت دسترسی، به داشبورد توسعه‌دهندگان فروشگاه وب کروم مراجعه کنید.

در بخش «تأیید مالکیت برنامه» در کلاینت افزونه کروم، روی دکمه «تأیید مالکیت» کلیک کنید تا فرآیند تأیید تکمیل شود.

توجه: پس از اعطای دسترسی به حساب کاربری خود، قبل از تکمیل فرآیند تأیید، چند دقیقه صبر کنید.

اگر تأیید موفقیت‌آمیز باشد، اعلانی برای تأیید موفقیت‌آمیز بودن فرآیند تأیید نمایش داده می‌شود. در غیر این صورت، یک پیام خطا نمایش داده می‌شود.

برای رفع خطای تأیید ناموفق، موارد زیر را امتحان کنید:

  • مطمئن شوید که یک مورد ثبت‌شده در داشبورد توسعه‌دهندگان فروشگاه وب کروم با شناسه‌ی همان مورد با شناسه‌ی کلاینت OAuth افزونه‌ی کرومی که در حال تکمیل تأیید اعتبار برای آن هستید، وجود دارد.
  • مطمئن شوید که شما ناشر برنامه هستید، یعنی یا باید ناشر شخصی برنامه باشید یا عضوی از ناشر گروهی برنامه. برای کسب اطلاعات بیشتر در مورد مدیریت دسترسی، به داشبورد توسعه‌دهندگان فروشگاه وب کروم مراجعه کنید.
  • اگر به تازگی فهرست ناشران گروه خود را به‌روزرسانی کرده‌اید، تأیید کنید که فهرست عضویت ناشران گروه در داشبورد توسعه‌دهندگان فروشگاه وب Chrome همگام‌سازی شده است. درباره همگام‌سازی فهرست عضویت ناشران خود بیشتر بدانید .

بررسی برنامه (فقط iOS)

ویژگی App Check با استفاده از سرویس App Attest اپل، تأیید می‌کند که درخواست‌های ارسالی به نقاط انتهایی Google OAuth 2.0 از برنامه‌های معتبر شما سرچشمه می‌گیرند و به این ترتیب از برنامه‌های iOS شما در برابر استفاده غیرمجاز محافظت می‌کند. این امر به کاهش خطر جعل هویت برنامه کمک می‌کند.

فعال کردن بررسی برنامه برای کلاینت iOS شما

برای فعال‌سازی موفقیت‌آمیز App Check برای کلاینت iOS شما، باید شرایط زیر رعایت شود:
  • شما باید یک شناسه تیم برای کلاینت iOS خود مشخص کنید.
  • شما نباید از کاراکترهای عمومی (wildcard) در شناسه بسته خود استفاده کنید زیرا می‌تواند به بیش از یک برنامه اشاره کند. این بدان معناست که شناسه بسته نباید شامل نماد ستاره (*) باشد.
برای فعال کردن App Check، دکمه‌ی «محافظت از کلاینت OAuth خود در برابر سوءاستفاده با Firebase App Check» را در نمای ویرایش کلاینت iOS خود فعال کنید.

پس از فعال کردن App Check، معیارهای مربوط به درخواست‌های OAuth از کلاینت خود را در نمای ویرایش کلاینت OAuth مشاهده خواهید کرد. درخواست‌های ارسالی از منابع تأیید نشده تا زمانی که App Check را اجرا نکنید، مسدود نخواهند شد. اطلاعات موجود در صفحه نظارت بر معیارها می‌تواند به شما در تعیین زمان شروع اجرا کمک کند.

ممکن است هنگام فعال کردن App Check برای برنامه iOS خود، خطاهایی مربوط به ویژگی App Check مشاهده کنید. برای رفع این خطاها، موارد زیر را امتحان کنید:

  • تأیید کنید که شناسه بسته و شناسه تیم که مشخص کرده‌اید معتبر هستند.
  • تأیید کنید که از wildcard برای شناسه بسته استفاده نمی‌کنید.

بررسی برنامه را برای کلاینت iOS خود اعمال کنید

فعال کردن App Check برای برنامه شما، درخواست‌های ناشناس را به طور خودکار مسدود نمی‌کند. برای اعمال این محافظت، به نمای ویرایش کلاینت iOS خود بروید. در آنجا، معیارهای App Check را در سمت راست صفحه، زیر بخش Google Identity for iOS مشاهده خواهید کرد. این معیارها شامل اطلاعات زیر هستند:
  • تعداد درخواست‌های تأیید شده - درخواست‌هایی که توکن App Check معتبری دارند. پس از فعال کردن اجرای App Check، فقط درخواست‌های این دسته موفق خواهند شد.
  • تعداد درخواست‌های تأیید نشده: احتمالاً درخواست‌های کلاینت قدیمی - درخواست‌هایی که فاقد توکن App Check هستند؛ این درخواست‌ها ممکن است از نسخه قدیمی‌تر برنامه شما باشند که شامل پیاده‌سازی App Check نمی‌شود.
  • تعداد درخواست‌های تأیید نشده: درخواست‌های با منشأ ناشناخته - درخواست‌هایی که توکن بررسی برنامه ندارند و به نظر نمی‌رسد از برنامه شما باشند.
  • تعداد درخواست‌های تأیید نشده: درخواست‌های نامعتبر - درخواست‌هایی با توکن بررسی برنامه نامعتبر، که ممکن است از یک کلاینت غیرمجاز که سعی در جعل هویت برنامه شما دارد یا از محیط‌های شبیه‌سازی شده باشد.
این معیارها را بررسی کنید تا بفهمید که چگونه اجرای App Check بر کاربران شما تأثیر می‌گذارد.

برای اجرای App Check، روی دکمه‌ی ENFORCE کلیک کنید و انتخاب خود را تأیید کنید. پس از فعال شدن ENFORCE، تمام درخواست‌های تأیید نشده از طرف کلاینت شما رد خواهند شد.

توجه : پس از فعال کردن اجرای تنظیمات، اعمال تغییرات می‌تواند تا ۱۵ دقیقه طول بکشد.

بررسی برنامه Unenforce برای کلاینت iOS شما

بررسی عدم اجرای برنامه (Unenforcement App Check) برای برنامه شما، اجرای برنامه را متوقف کرده و به همه درخواست‌های کلاینت شما به نقاط انتهایی Google OAuth 2.0، از جمله درخواست‌های تأیید نشده، اجازه عبور می‌دهد.

برای لغو بررسی برنامه برای کلاینت iOS خود، به نمای ویرایش کلاینت iOS بروید و روی دکمه UNENFORCE کلیک کنید و انتخاب خود را تأیید کنید.

توجه : پس از غیرفعال کردن بررسی برنامه، اعمال تغییرات می‌تواند تا ۱۵ دقیقه طول بکشد.

بررسی برنامه را برای کلاینت iOS خود غیرفعال کنید

غیرفعال کردن App Check برای برنامه شما، تمام نظارت و اجرای App Check را متوقف می‌کند. در عوض، غیرفعال کردن App Check را در نظر بگیرید تا بتوانید به نظارت بر معیارها برای مشتری خود ادامه دهید.

برای غیرفعال کردن App Check برای کلاینت iOS خود، به نمای ویرایش کلاینت iOS بروید و دکمه‌ی « محافظت از کلاینت OAuth شما در برابر سوءاستفاده با Firebase App Check» را غیرفعال کنید.

توجه : پس از غیرفعال کردن بررسی برنامه، اعمال تغییرات می‌تواند تا ۱۵ دقیقه طول بکشد.

دسترسی مبتنی بر زمان

دسترسی مبتنی بر زمان به کاربر اجازه می‌دهد تا برای تکمیل یک اقدام، به برنامه شما دسترسی به داده‌های خود را برای مدت محدودی اعطا کند. دسترسی مبتنی بر زمان در محصولات منتخب گوگل در طول جریان رضایت در دسترس است و به کاربران این امکان را می‌دهد که برای مدت زمان محدودی به داده‌ها دسترسی بدهند. به عنوان مثال، رابط برنامه‌نویسی کاربردی (API) قابلیت انتقال داده‌ها (Data Portability API) امکان انتقال یک‌باره داده‌ها را فراهم می‌کند.

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

مطالعه بیشتر

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

پیاده‌سازی حفاظت از حساب‌های کاربری متقابل

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

برخی از نمونه‌های انواع رویدادهایی که توسط سرویس حفاظت از حساب‌های کاربری متقابل گوگل به برنامه شما ارسال می‌شوند عبارتند از:

  • https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
  • https://schemas.openid.net/secevent/oauth/event-type/token-revoked
  • https://schemas.openid.net/secevent/risc/event-type/account-disabled

برای اطلاعات بیشتر در مورد نحوه پیاده‌سازی محافظت از حساب‌های کاربری بین‌حسابی و فهرست کامل رویدادهای موجود، به صفحه «محافظت از حساب‌های کاربری با محافظت از حساب‌های کاربری بین‌حسابی» مراجعه کنید.