این سند توضیح میدهد که چگونه برنامههای نصب شده روی دستگاههایی مانند تلفنها، تبلتها و رایانهها از نقاط پایانی 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 فعال کند.
برای فعال کردن API برای پروژه خود:
- کتابخانه API را در کنسول API گوگل باز کنید .
- در صورت درخواست، یک پروژه را انتخاب کنید یا یک پروژه جدید ایجاد کنید.
- کتابخانه API تمام APIهای موجود را که بر اساس خانواده محصول و محبوبیت گروهبندی شدهاند، فهرست میکند. اگر API مورد نظر برای فعالسازی در لیست قابل مشاهده نیست، از جستجو برای یافتن آن استفاده کنید یا روی مشاهده همه در خانواده محصولی که به آن تعلق دارد کلیک کنید.
- API مورد نظر خود را انتخاب کنید و سپس روی دکمهی فعالسازی کلیک کنید.
- در صورت درخواست، صورتحساب را فعال کنید.
- در صورت درخواست، شرایط خدمات API را بخوانید و بپذیرید.
ایجاد اعتبارنامههای مجوز
هر برنامهای که از OAuth 2.0 برای دسترسی به APIهای گوگل استفاده میکند، باید دارای اعتبارنامههای احراز هویت باشد که برنامه را به سرور OAuth 2.0 گوگل معرفی کند. مراحل زیر نحوه ایجاد اعتبارنامه برای پروژه شما را توضیح میدهد. سپس برنامههای شما میتوانند از این اعتبارنامهها برای دسترسی به APIهایی که برای آن پروژه فعال کردهاید، استفاده کنند.
- به صفحه مشتریان بروید.
- روی ایجاد کلاینت کلیک کنید.
- بخشهای زیر انواع کلاینتهایی را که سرور تأیید گوگل پشتیبانی میکند، شرح میدهند. نوع کلاینتی را که برای برنامه شما توصیه میشود انتخاب کنید، کلاینت OAuth خود را نامگذاری کنید و سایر فیلدهای فرم را به صورت مناسب تنظیم کنید.
آیاواس
- نوع اپلیکیشن iOS را انتخاب کنید.
- یک نام برای کلاینت OAuth وارد کنید. این نام در صفحه کلاینتهای پروژه شما نمایش داده میشود تا کلاینت را شناسایی کند.
- شناسه بسته نرمافزاری برنامه خود را وارد کنید. شناسه بسته نرمافزاری، مقدار کلید CFBundleIdentifier در فایل منبع لیست ویژگی اطلاعات برنامه شما ( info.plist ) است. این مقدار معمولاً در قسمت General یا قسمت Signing & Capabilities ویرایشگر پروژه Xcode نمایش داده میشود. شناسه بسته نرمافزاری همچنین در بخش General Information صفحه App Information برنامه در سایت App Store Connect اپل نمایش داده میشود.
تأیید کنید که از شناسه بسته صحیح برای برنامه خود استفاده میکنید، زیرا اگر از ویژگی بررسی برنامه استفاده میکنید، نمیتوانید آن را تغییر دهید.
- (اختیاری)
اگر برنامه در فروشگاه برنامه اپل منتشر شده است، شناسه فروشگاه برنامه خود را وارد کنید. شناسه فروشگاه یک رشته عددی است که در هر URL فروشگاه برنامه اپل وجود دارد.
- برنامه Apple App Store را در دستگاه iOS یا iPadOS خود باز کنید.
- برنامه خود را جستجو کنید.
- دکمه اشتراکگذاری (علامت مربع و فلش رو به بالا) را انتخاب کنید.
- کپی کردن پیوند را انتخاب کنید.
- لینک را در یک ویرایشگر متن جایگذاری کنید. شناسه اپ استور بخش پایانی URL است.
مثال:
https://apps.apple.com/app/google/id 284815942
- (اختیاری)
شناسه تیم خود را وارد کنید. برای اطلاعات بیشتر به بخش «شناسه تیم خود را در مستندات حساب توسعهدهنده اپل پیدا کنید» مراجعه کنید.
توجه: اگر App Check را برای کلاینت خود فعال میکنید، فیلد Team ID الزامی است. - (اختیاری)
بررسی برنامه (App Check) را برای برنامه iOS خود فعال کنید. وقتی بررسی برنامه (App Check) را فعال میکنید، از سرویس App Attest اپل برای تأیید صحت درخواستهای OAuth 2.0 که از کلاینت OAuth شما ارسال میشوند و از برنامه شما میآیند، استفاده میشود. این به کاهش خطر جعل هویت برنامه کمک میکند. درباره فعال کردن بررسی برنامه (App Check) برای برنامه iOS خود بیشتر بدانید .
- روی ایجاد کلیک کنید.
یو دبلیو پی
- نوع برنامه Universal Windows Platform را انتخاب کنید.
- یک نام برای کلاینت OAuth وارد کنید. این نام در پوشه پروژه شما نمایش داده میشود. برای شناسایی مشتری.
- شناسه فروشگاه مایکروسافت ۱۲ کاراکتری برنامه خود را وارد کنید. میتوانید این مقدار را در مرکز شرکای مایکروسافت در صفحه شناسه برنامه در بخش مدیریت برنامه پیدا کنید.
- روی ایجاد کلیک کنید.
برای برنامههای 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) از تأییدکننده کد است.
|
| ساده | چالش کد همان مقداری است که تأییدکننده کد تولید شده در بالا دارد.
|
مرحله ۲: ارسال درخواست به سرور OAuth 2.0 گوگل
برای دریافت مجوز کاربر، درخواستی را به سرور مجوز گوگل به آدرس https://accounts.google.com/o/oauth2/v2/auth ارسال کنید. این نقطه پایانی، جستجوی فعال نشست را مدیریت میکند، کاربر را احراز هویت میکند و رضایت کاربر را دریافت میکند. این نقطه پایانی فقط از طریق SSL قابل دسترسی است و اتصالات HTTP (غیر SSL) را رد میکند.
سرور احراز هویت از پارامترهای رشته پرس و جوی زیر برای برنامههای نصب شده پشتیبانی میکند:
| پارامترها | |||||||
|---|---|---|---|---|---|---|---|
client_id | مورد نیاز شناسه کلاینت برای برنامه شما. میتوانید این مقدار را در صفحه کلاینتهای کنسول ابری پیدا کنید. | ||||||
redirect_uri | مورد نیاز نحوه ارسال پاسخ از سرور احراز هویت گوگل به برنامه شما را تعیین میکند. چندین گزینه تغییر مسیر برای برنامههای نصب شده وجود دارد و شما اعتبارنامههای احراز هویت خود را با در نظر گرفتن یک روش تغییر مسیر خاص تنظیم خواهید کرد. این مقدار باید دقیقاً با یکی از آدرسهای URL مجاز برای کلاینت OAuth 2.0 که در صفحه Cloud Console Clients کلاینت خود پیکربندی کردهاید، مطابقت داشته باشد. اگر این مقدار با یک آدرس URL مجاز مطابقت نداشته باشد، خطای جدول مقدار پارامتر
| ||||||
response_type | مورد نیاز تعیین میکند که آیا نقطه پایانی Google OAuth 2.0 کد مجوز را برمیگرداند یا خیر. مقدار پارامتر را برای برنامههای نصب شده روی | ||||||
scope | مورد نیاز فهرستی از محدودهها که با فاصله از هم جدا شدهاند و منابعی را که برنامه شما میتواند از طرف کاربر به آنها دسترسی داشته باشد، مشخص میکنند. این مقادیر، صفحه رضایتنامهای را که گوگل به کاربر نمایش میدهد، مشخص میکنند. محدودهها به برنامه شما این امکان را میدهند که فقط به منابعی که نیاز دارد درخواست دسترسی کند و در عین حال کاربران را قادر میسازد میزان دسترسی که به برنامه شما میدهند را کنترل کنند. بنابراین، بین تعداد محدودههای درخواستی و احتمال کسب رضایت کاربر، رابطه معکوس وجود دارد. | ||||||
code_challenge | توصیه شده یک | ||||||
code_challenge_method | توصیه شده مشخص میکند که از چه روشی برای رمزگذاری یک | ||||||
state | توصیه شده هر مقدار رشتهای را که برنامه شما برای حفظ وضعیت بین درخواست مجوز شما و پاسخ سرور مجوز استفاده میکند، مشخص میکند. سرور پس از اینکه کاربر درخواست دسترسی برنامه شما را تأیید یا رد کرد، مقدار دقیقی را که شما به عنوان یک جفت شما میتوانید از این پارامتر برای چندین هدف استفاده کنید، مانند هدایت کاربر به منبع صحیح در برنامهتان، ارسال nonceها و کاهش جعل درخواست بین سایتی. از آنجایی که | ||||||
login_hint | اختیاری اگر برنامه شما بداند کدام کاربر در حال تلاش برای احراز هویت است، میتواند از این پارامتر برای ارائه یک راهنما به سرور احراز هویت گوگل استفاده کند. سرور از این راهنما برای سادهسازی جریان ورود به سیستم، یا با پر کردن فیلد ایمیل در فرم ورود به سیستم یا با انتخاب جلسه ورود چندگانه مناسب، استفاده میکند. مقدار پارامتر را روی یک آدرس ایمیل یا شناسه | ||||||
نمونه 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 Console Clients بررسی کنید.
ممکن است 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 | شناسه کلاینت که از صفحه کلاینتهای کنسول ابری به دست آمده است. |
client_secret | اختیاری رمز کلاینت که از صفحه کلاینتهای کنسول ابری به دست آمده است. |
code | کد مجوزی که از درخواست اولیه برگردانده شده است. |
code_verifier | تأییدکننده کدی که در مرحله ۱ ایجاد کردید. |
grant_type | همانطور که در مشخصات OAuth 2.0 تعریف شده است ، مقدار این فیلد باید روی authorization_code تنظیم شود. |
redirect_uri | یکی از آدرسهای هدایتشدهی ذکر شده برای پروژهی شما در صفحهی کلاینتهای کنسول ابری برای client_id داده شده. |
اگرچه استفاده از DPoP اختیاری است، اما برای افزایش امنیت توصیه میشود. امنیت DPoP به محدود بودن کلید خصوصی به یک دستگاه واحد متکی است؛ توصیه میکنیم آن را به گونهای ذخیره کنید که نتوان آن را خارج از دستگاه کپی کرد، به عنوان مثال با استفاده از TPMها، Secure Enclaveها یا سایر keystoreهای پشتیبانیشده توسط سختافزار. برای استفاده از DPoP، برنامه شما باید برای هر درخواست به نقطه پایانی توکن، یک JWT جدید و منحصر به فرد مقاوم در برابر DPoP تولید کند و آن را به عنوان هدر درخواست HTTP اضافه کند.
| سربرگ | مورد نیاز | توضیحات |
|---|---|---|
DPoP | اختیاری | اثبات DPoP یک JWT است که داشتن یک کلید خصوصی را اثبات میکند. این یک هدر است، نه یک پارامتر. در صورت ارائه، توکنهای برگشتی به این کلید متصل میشوند. برای هر درخواست باید یک اثبات جدید و منحصر به فرد ایجاد شود و باید شامل ادعاهای htm (روش HTTP) و htu (URI HTTP) باشد که با درخواست مطابقت دارند. |
قطعه کد زیر یک نمونه درخواست را نشان میدهد:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6Ik\ VDIiwieCI6Imw4dEZyaHgtMzR0VjNoUklDUkRZOXpDa0RscEJoRjQyVVFVZldWQVdCR\ nMiLCJ5IjoiOVZFNGpmX09rX282NHpiVFRsY3VOSmFqSG10NnY5VERWclUwQ2R2R1JE\ QSIsImNydiI6IlAtMjU2In19.eyJqdGkiOiItQndDM0VTYzZhY2MybFRjIiwiaHRtIj\ oiUE9TVCIsImh0dSI6Imh0dHBzOi8vc2VydmVyLmV4YW1wbGUuY29tL3Rva2VuIiwia\ WF0IjoxNTYyMjYyNjE2fQ.2-GxA6T8lP4vfrg8v-FdWP0A0zdrj8igiMLvqRMUvwnQg\ 4PtFLbdLXiOSsX0x7NVY-FNyJK70nfbV37xRZT3Lg code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7& client_id=your_client_id& redirect_uri=http://127.0.0.1:9004& grant_type=authorization_code
ساخت یک اثبات DPoP
مراحل زیر نحوه ساخت یک اثبات DPoP با استفاده از OpenSSL از خط فرمان را نشان میدهد:
- یک جفت کلید EC P-256 ایجاد کنید:
openssl ecparam -name prime256v1 -genkey -noout -out dpop_private.pem openssl ec -in dpop_private.pem -pubout -out dpop_public.pem
- هدر DPoP را ایجاد کنید:
هدر باید شامل ادعاهای
typ،algوjwk(کلید عمومی) باشد. مقادیرxوyمختصات رمزگذاری شده Base64Url از کلید عمومی EC شما هستند. Base64Url این JSON را رمزگذاری میکند:{ "typ":"dpop+jwt", "alg":"ES256", "jwk": { "kty":"EC", "x":"YOUR_PUBLIC_KEY_X", "y":"YOUR_PUBLIC_KEY_Y", "crv":"P-256" } } - ایجاد پیلود DPoP:
این payload باید شامل
jti(یک شناسه منحصر به فرد برای درخواست)،htm(روش HTTP، مثلاًPOST)،htu(URI HTTP، مثلاًhttps://oauth2.googleapis.com/token) وiat(صادر شده در زمان) باشد. اگر در پاسخ به درخواست قبلی، یک nonce از سرور در هدرDPoP-Nonceدریافت کردهاید، باید آن مقدار nonce را در یکnonceclaim وارد کنید. nonce claim برای تبادل کد مجوز اختیاری است و فقط زمانی استفاده میشود که هدر DPoP-Nonce قبلاً دریافت شده باشد. Base64Url این JSON را کدگذاری میکند:{ "jti":"JTI_VALUE", "htm":"POST", "htu":"https://oauth2.googleapis.com/token", "iat":YOUR_JWT_ISSUED_TIME, "nonce":"SERVER_PROVIDED_NONCE" }مقدار
jtiبه نوع مبادله بستگی دارد:- برای تبادل کد مجوز ،
jtiباید هش SHA256 کدگذاری شده با Base64Url از کد مجوز باشد:"jti":" BASE64URL(SHA256(AUTHORIZATION_CODE)) ". - برای تبادل توکنهای رفرش ،
jtiباید یک شناسه منحصر به فرد برای هر درخواست باشد:"jti":" YOUR_UNIQUE_PER_REQUEST_IDENTIFIER ".
- برای تبادل کد مجوز ،
- مدرک را امضا کنید:
هدر و محتوای رمزگذاری شده را با یک نقطه (
.) به هم متصل کنید، سپس نتیجه را با کلید خصوصی خود با استفاده از ES256 امضا کنید. توجه داشته باشید که JWS نیاز دارد که امضا در قالب خامR | Sبه هم پیوسته باشد (۶۴ بایت برای P-256). اگر مستقیماً از OpenSSL استفاده میکنید، باید امضای پیشفرض رمزگذاری شده ASN.1 DER را به این قالب خام تبدیل کنید.
یک تبادل موفق با یک پاسخ 200 OK حاوی توکنها نشان داده میشود. اگر در طول تبادل از یک اثبات DPoP معتبر استفاده شود، توکن تازهسازی که گوگل برمیگرداند به کلید شما متصل به DPoP خواهد بود، اما توکنهای دسترسی به DPoP متصل نخواهند بود. توکنهای دسترسی به جای DPoP ، token_type Bearer را حفظ میکنند. علاوه بر این، گوگل یک هدر HTTP از DPoP-Nonce را در پاسخ برمیگرداند. کلاینت شما باید این nonce را ذخیره کرده و آن را در درخواست nonce اثبات DPoP در درخواستهای بعدی (مانند هنگام تبادل یک توکن تازهسازی با یک توکن دسترسی جدید یا هنگام فراخوانی APIهای محافظتشده با DPoP) لحاظ کند. با استفاده از این nonce صادر شده زودهنگام، میتوانید از یک خطای رفت و برگشت اضافی ( use_dpop_nonce ) در درخواست بعدی خود جلوگیری کنید.
برای درخواستهای تبادل توکن که با توکنهای تازهسازیشدهی مرتبط با DPoP انجام میشوند، باید اثباتهای DPoP نیز گنجانده شوند.
اگر هدر DPoP در زمان مورد انتظار وجود نداشته باشد، نامعتبر باشد، یا اگر اثبات از کلید متفاوتی نسبت به کلید متصل به توکن استفاده کند، یک تبادل ناموفق رخ میدهد. در این موارد، سرور خطای 400 Bad Request را برمیگرداند. اگر اثبات DPoP ادعاهای htm یا htu نامتناسب، یک iat منقضی شده، یک jti استفاده مجدد شده یا یک امضای نامعتبر داشته باشد، گوگل کد خطای invalid_dpop_proof را برمیگرداند. اگر یک nonce DPoP مورد نیاز باشد، مانند هنگام تبادل توکن refresh، و اثبات DPoP فاقد یک ادعای nonce باشد، یا مقدار nonce برای سرور غیرقابل قبول باشد (مثلاً منقضی شده باشد، قبلاً استفاده شده باشد یا نادرست باشد)، گوگل یک کد خطای use_dpop_nonce را به همراه یک هدر HTTP DPoP-Nonce حاوی یک nonce جدید که میتوانید در درخواست بعدی از آن استفاده کنید، برمیگرداند. سایر خرابیها ممکن است invalid_grant برگردانند.
گوگل با برگرداندن یک شیء JSON که شامل یک توکن دسترسی کوتاهمدت و یک توکن بهروزرسانی است، به این درخواست پاسخ میدهد.
پاسخ شامل فیلدهای زیر است:
| فیلدها | |
|---|---|
access_token | توکنی که برنامه شما برای تأیید درخواست API گوگل ارسال میکند. |
expires_in | طول عمر باقی مانده از توکن دسترسی بر حسب ثانیه. |
id_token | توجه: این ویژگی فقط در صورتی برگردانده میشود که درخواست شما شامل یک محدوده هویت، مانند openid ، profile یا email باشد. مقدار آن یک JSON Web Token (JWT) است که حاوی اطلاعات هویتی امضا شده دیجیتالی در مورد کاربر است. |
refresh_token | توکنی که میتوانید از آن برای دریافت یک توکن دسترسی جدید استفاده کنید. توکنهای تازهسازی تا زمانی که کاربر دسترسی را لغو کند یا توکن تازهسازی منقضی شود، معتبر هستند. اگر از DPoP استفاده شده باشد، توکن تازهسازی به کلید خصوصی مورد استفاده برای امضای اثبات DPoP متصل میشود. توجه داشته باشید که توکنهای تازهسازی همیشه برای برنامههای نصب شده بازگردانده میشوند. |
refresh_token_expires_in | طول عمر باقیماندهی توکن بهروزرسانی بر حسب ثانیه. این مقدار فقط زمانی تنظیم میشود که کاربر دسترسی مبتنی بر زمان را اعطا کند. |
scope | دامنههای دسترسی اعطا شده توسط access_token به صورت فهرستی از رشتههای جدا شده با فاصله و حساس به حروف بزرگ و کوچک بیان میشوند. |
token_type | نوع توکن برگشتی. این مقدار همیشه Bearer است، حتی زمانی که از DPoP استفاده شود. |
قطعه کد زیر نمونهای از هدرها و بدنه پاسخ موفق را هنگام استفاده از DPoP نشان میدهد:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI
{
"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 به دست آمده است. ( |
grant_type | همانطور که در مشخصات OAuth 2.0 تعریف شده است ، مقدار این فیلد باید برابر با refresh_token تنظیم شود. |
refresh_token | توکن بهروزرسانی که از تبادل کد مجوز بازگردانده شده است. |
اگرچه استفاده از DPoP اختیاری است، اما برای افزایش امنیت توصیه میشود. برای استفاده از DPoP با یک توکن تازهسازی، برنامه شما باید برای هر درخواست به نقطه پایانی توکن، یک JWT جدید و منحصر به فرد برای اثبات DPoP ایجاد کند. این اثبات باید با همان کلید خصوصی که در طول تبادل کد مجوز اولیه استفاده شده بود، امضا شود. برنامه شما این اثبات را به عنوان یک هدر درخواست HTTP اضافه میکند.
| سربرگ | مورد نیاز | توضیحات |
|---|---|---|
DPoP | اختیاری | اثبات DPoP یک JWT است که داشتن یک کلید خصوصی را اثبات میکند. این یک هدر است، نه یک پارامتر. در صورت ارائه، توکنهای برگشتی به این کلید متصل میشوند. برای هر درخواست باید یک اثبات جدید و منحصر به فرد ایجاد شود و باید شامل ادعاهای htm (روش HTTP) و htu (URI HTTP) باشد که با درخواست مطابقت دارند. |
قطعه کد زیر یک نمونه درخواست را نشان میدهد:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded DPoP: DPOP_PROOF_JWT client_id=your_client_id& refresh_token=refresh_token& grant_type=refresh_token
برای استفاده از DPoP با یک توکن تازهسازی، باید یک JWT جدید و منحصر به فردِ مقاوم در برابر DPoP برای درخواست ایجاد کنید. برای دستورالعملهای گام به گام در مورد تولید جفت کلید و ساخت JWT، به بخش «ساخت یک اثبات DPoP» مراجعه کنید.
یک تبادل موفق با یک پاسخ 200 OK حاوی یک توکن دسترسی جدید نشان داده میشود. هنگامی که از DPoP استفاده میشود، token_type Bearer است. یک پاسخ موفق، تایید میکند که اثبات DPoP برای توکن بهروزرسانی پذیرفته شده است. گوگل همچنین ممکن است یک هدر HTTP جدید DPoP-Nonce را در پاسخ برگرداند؛ در صورت برگرداندن، کلاینت شما باید این nonce را ذخیره کرده و آن را در درخواستهای بعدی nonce اثبات DPoP لحاظ کند.
اگر هدر DPoP وجود نداشته باشد، نامعتبر باشد یا از کلید نادرستی استفاده کند، تبادل ناموفق رخ میدهد. برای جزئیات بیشتر در مورد کدهای خطای خاص DPoP و نحوه مدیریت nonceها، به بخش تبادل ناموفق مراجعه کنید.
قطعه کد زیر نمونهای از هدرها و بدنه پاسخ موفق را هنگام استفاده از DPoP نشان میدهد:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
DPoP-Nonce: AN3XwJjZsjnb0ZuWkRlek8QU7wY-Zhf-5IP6tO0tORz0KgtDT1Bo8FX-w4nz3r5lnepI
{
"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 به همراه یک کد خطا بازگردانده میشود.
App redirect methods
Custom URI scheme
Custom URI schemes are a form of deeplinking that use a custom-defined scheme to open your app.
Alternative to using custom URI schemes on Chrome apps
Use the Chrome Identity API which delivers the OAuth 2.0 response directly to your app, eliminating the need for a redirect URI.
Loopback IP address (macOS, Linux, Windows desktop)
To receive the authorization code using this URL, your application must be listening on the local web server. That is possible on many, but not all, platforms. However, if your platform supports it, this is the recommended mechanism for obtaining the authorization code.
When your app receives the authorization response, for best usability it should respond by displaying an HTML page that instructs the user to close the browser and return to your app.
| Recommended usage | macOS, Linux, and Windows desktop (but not Universal Windows Platform) apps |
| Form values | Set the application type to Desktop app . |
Manual copy/paste (Deprecated)
Protect your apps
Verify app ownership for Chrome
You can verify ownership of your application to reduce the risk of app impersonation.
To complete the verification process, you would use your Chrome Web Store Developer account. The following requirements must be met for a successful verification:
- You must have a registered item in the Chrome Web Store Developer Dashboard with the same item ID as the Chrome Extension OAuth client you are completing the verification for.
- You must be a publisher for the Chrome Web Store item. Learn more about access management in the Chrome Web Store Developer Dashboard.
In the Verify App Ownership section of the Chrome Extension client, click the Verify Ownership button to complete the verification process.
Note: Wait a few minutes before completing the verification process after granting access to your account.
If the verification is successful, a notification will be displayed to confirm the success of the verification process. Otherwise, an error prompt will be shown.
To fix a failed verification, try the following:
- Make sure there is a registered item in the Chrome Web Store Developer Dashboard with the same item ID as the Chrome Extension OAuth client you are completing the verification for.
- Make sure you are a publisher for the app, that is, you must either be the individual publisher of the app or a member of the group publisher of the app. Learn more about access management in the Chrome Web Store Developer Dashboard.
- If you just updated your group publisher list, verify that the group publisher membership list is synced in the Chrome Web Store Developer Dashboard. Learn more about syncing your publisher membership list.
App Check (iOS only)
The App Check feature helps safeguard your iOS applications from unauthorized usage by using Apple's App Attest service to verify that requests made to Google OAuth 2.0 endpoints originate from your authentic applications. This helps to reduce the risk of app impersonation.
Enable App Check for your iOS Client
The following requirements must be met to successfully enable App Check for your iOS client:- You must specify a team ID for your iOS client.
- You must not use a wildcard in your bundle ID since it can resolve to more than one app. This means that the bundle ID must not include the asterisk (*) symbol.
After enabling App Check, you will start seeing metrics related to OAuth requests from your client in the edit view of the OAuth client. Requests from unverified sources won't be blocked until you enforce App Check . The information in the metrics monitoring page can help you determine when to start enforcement.
You might see errors related to the App Check feature when enabling App Check for your iOS app. To fix these errors, try the following:
- Verify that the bundle ID and team ID you specified are valid.
- Verify that you are not using a wildcard for the bundle ID.
Enforce App Check for your iOS Client
Enabling App Check for your app does not automatically block unrecognized requests. To enforce this protection, go to the edit view of your iOS client. There, you will see App Check metrics to the right of the page under the Google Identity for iOS section. The metrics include the following information:- Number of verified requests - requests that have a valid App Check token. After you enable App Check enforcement, only requests in this category will succeed.
- Number of unverified requests: likely outdated client requests - requests missing an App Check token; these request may be from an older version of your app that doesn't include an App Check implementation.
- Number of unverified requests: unknown origin requests - requests missing an App Check token that don't look like they are coming from your app.
- Number of unverified requests: invalid requests - requests with an invalid App Check token, which may be from an inauthentic client attempting to impersonate your app, or from emulated environments.
To enforce App Check, click the ENFORCE button and confirm your choice. Once enforcement is active, all unverified requests from your client will be rejected.
Note : after you enable enforcement, it can take up to 15 minutes for the changes to take effect.
Unenforce App Check for your iOS Client
Unenforcing App Check for your app will stop enforcement and will allow all requests from your client to Google OAuth 2.0 endpoints, including unverified requests.
To unenforce App Check for your iOS client, navigate to the edit view of the iOS client and click the UNENFORCE button and confirm your choice.
Note : after unenforcing App Check, it can take up to 15 minutes for the changes to take effect.
Disable App Check for your iOS Client
Disabling App Check for your app will stop all App Check monitoring and enforcement . Consider unenforcing App Check instead so you can continue monitoring metrics for your client.
To disable App Check for your iOS client, navigate to the edit view of the iOS client and turn off the Protect your OAuth client from abuse with Firebase App Check toggle button.
Note : after disabling App Check, it can take up to 15 minutes for the changes to take effect.
Time-based access
Time-based access allows a user to grant your app access to their data for a limited duration to complete an action. Time-based access is available in select Google products during the consent flow, giving users the option to grant access for a limited period of time. An example is the Data Portability API which enables a one-time transfer of data.
When a user grants your application time-based access, the refresh token will expire after the specified duration. Note that refresh tokens may be invalidated earlier under specific circumstances; see these cases for details. The refresh_token_expires_in field returned in the authorization code exchange response represents the time remaining until the refresh token expires in such cases.
مطالعه بیشتر
The IETF Best Current Practice OAuth 2.0 for Native Apps establishes many of the best practices documented here.
Implement Cross-Account Protection
An additional step you should take to protect your users' accounts is implementing Cross-Account Protection by utilizing Google's Cross-Account Protection Service. This service lets you subscribe to security event notifications which provide information to your application about major changes to the user account. You can then use the information to take action depending on how you decide to respond to events.
Some examples of the event types sent to your app by Google's Cross-Account Protection Service are:
-
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
See the Protect user accounts with Cross-Account Protection page for more information on how to implement Cross Account Protection and for the full list of available events.