مقدمه ای برای OAUTH 2

OAUTH 2 یک چارچوب مجوز است که برنامه های کاربردی - مانند Facebook ، GitHub و DigitalOcean را قادر می سازد تا دسترسی محدود به حساب های کاربری را در یک سرویس HTTP بدست آورند. این کار با واگذاری احراز هویت کاربر به خدماتی که میزبان یک حساب کاربری و مجاز به برنامه های شخص ثالث برای دسترسی به آن حساب کاربری است ، کار می کند. OAUTH 2 جریان مجوز برای برنامه های وب و دسک تاپ و همچنین دستگاه های تلفن همراه را فراهم می کند.

این راهنمای اطلاع رسانی به سمت توسعه دهندگان برنامه ها در نظر گرفته شده است و مروری بر نقش OAUTH 2 ، انواع اعطای مجوز ، موارد استفاده و جریان ارائه می دهد.

نقش های OAUTH

OAuth چهار نقش را تعریف می کند:

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

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

جریان پروتکل انتزاعی

اکنون که شما ایده ای در مورد نقش های OAUTH دارید ، بگذارید به نمودار چگونگی تعامل آنها با یکدیگر نگاه کنیم:

در اینجا توضیح مفصلی درباره مراحل موجود در نمودار ارائه شده است:

1. برنامه درخواست اجازه دسترسی به منابع خدمات از کاربر را دارد
2. اگر کاربر درخواست را مجاز کند ، برنامه کمک هزینه مجوز دریافت می کند
3. برنامه با ارائه احراز هویت هویت خود و کمک هزینه مجوز ، یک نشانه دسترسی از سرور مجوز (API) درخواست می کند
4. اگر هویت برنامه تأیید شود و کمک هزینه مجوز معتبر باشد ، سرور مجوز (API) نشانه دسترسی به برنامه را صادر می کند. مجوز کامل است.
5. برنامه از منبع از سرور منبع (API) درخواست می کند و نشانه دسترسی را برای تأیید اعتبار ارائه می دهد
6. اگر نشانه دسترسی معتبر باشد ، سرور منبع (API) منبع را به برنامه ارائه می دهد

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

ثبت درخواست

قبل از استفاده از OAUTH با برنامه خود ، باید درخواست خود را در سرویس ثبت کنید. این کار از طریق فرم ثبت نام در بخش توسعه دهنده یا API وب سایت سرویس انجام می شود ، جایی که اطلاعات زیر را ارائه می دهید (و احتمالاً جزئیات مربوط به برنامه خود):

• نام نرم افزار
• وب سایت برنامه
• URI یا URL پاسخ به تماس را هدایت کنید

تغییر مسیر URI در جایی است که سرویس پس از مجاز بودن (یا انکار) درخواست شما ، کاربر را هدایت می کند ، و بنابراین بخشی از برنامه شما که کدهای مجوز را اداره می کند یا به نشانه های دسترسی می پردازد.

شناسه مشتری و راز مشتری

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

اعطای مجوز

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

• کد مجوز: با برنامه های سمت سرور استفاده می شود
• اعتبار مشتری: با برنامه هایی که دسترسی API دارند استفاده می شود
• کد دستگاه: برای دستگاه هایی که فاقد مرورگرها هستند یا محدودیت ورودی دارند استفاده می شود

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

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

نوع کمک هزینه: کد مجوز

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

اکنون ما جریان کد مجوز را شرح خواهیم داد:

مرحله 1 - پیوند کد مجوز

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

در اینجا توضیحی در مورد مؤلفه های پیوند این مثال آورده شده است:

• ** https: //cloud. digitalocean.com/v1/oauth/authorize**: نقطه پایان مجوز API
• client_id = client_id: شناسه مشتری برنامه (نحوه شناسایی API برنامه)
• redirect_uri = callback_url: جایی که سرویس پس از اعطای کد مجوز ، عامل کاربر را هدایت می کند
• پاسخ_تایپ = کد: مشخص می کند که درخواست شما درخواست کمک هزینه کد مجوز می کند
• دامنه = بخوانید: سطح دسترسی را که درخواست درخواست می کند مشخص می کند

مرحله 2 - کاربر مجاز به برنامه است

هنگامی که کاربر روی پیوند کلیک می کند ، ابتدا باید برای تأیید هویت خود وارد سرویس شوند (مگر اینکه از قبل وارد سیستم شوند). سپس از این سرویس خواسته می شود که دسترسی به حساب خود را مجوز یا انکار کنند. در اینجا یک مثال مجاز به درخواست سریع است:

این تصویر خاص از صفحه مجوز DigitalOcean است و نشان می دهد که برنامه Thedropletbook درخواست مجوز برای دسترسی به حساب [email protected] را دارد.

مرحله 3 - برنامه دریافت کد مجوز

اگر کاربر بر روی برنامه مجاز باشد ، این سرویس عامل کاربر را به سمت URI تغییر مسیر برنامه ، که در طول ثبت نام مشتری مشخص شده است ، به همراه یک کد مجوز هدایت می کند. تغییر مسیر چیزی شبیه به این است (با فرض اینکه برنامه Dropletbook.com است):

مرحله 4 - درخواست برنامه دسترسی به نشانه دسترسی

برنامه با عبور از کد مجوز به همراه جزئیات تأیید اعتبار ، از جمله راز مشتری ، به نقطه پایانی API ، یک نشانه دسترسی از API درخواست می کند. در اینجا یک مثال درخواست پست به نقطه پایانی توکن دیجیتالوسیان آورده شده است:

مرحله 5 - برنامه نشانه دسترسی را دریافت می کند

اگر مجوز معتبر باشد ، API پاسخی را شامل می شود که حاوی نشانه دسترسی (و به صورت اختیاری ، یک توکن تازه) به برنامه است. کل پاسخ چیزی شبیه به این خواهد بود:

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

توجه در مورد کلید اثبات مبادله کد

اگر یک مشتری عمومی از نوع کمک هزینه کد مجوز استفاده می کند ، این احتمال وجود دارد که کد مجوز قابل رهگیری باشد. کلید اثبات مبادله کد (یا PKCE ، مانند "Pixie" تلفظ می شود) یک برنامه افزودنی برای جریان کد مجوز است که به کاهش این نوع حمله کمک می کند.

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

نقطه انتهایی مجوز چالش کد و روش تحول را ثبت می کند و با کد مجوز همانطور که قبلاً بیان شد پاسخ می دهد. مشتری سپس درخواست Token Access را ارسال می کند که شامل تأیید کننده کد در ابتدا تولید شده است.

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

توصیه می شود که هر مشتری از پسوند PKCE برای بهبود امنیت استفاده کند.

نوع کمک هزینه: اعتبار مشتری

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

اعتبار مشتری جریان دارد

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

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

توجه: DigitalOcean در حال حاضر از نوع اعطای اعتبار مشتری پشتیبانی نمی کند ، بنابراین پیوند به یک سرور مجوز خیالی در oauth. example.com اشاره می کند.

نوع کمک هزینه: کد دستگاه

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

جریان کد دستگاه

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

یک مثال درخواست کد دستگاه ممکن است مانند موارد زیر به نظر برسد:

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

در اینجا پاسخ مثالی از نقطه پایانی مجوز دستگاه ممکن است به نظر برسد:

توجه داشته باشید که کد دستگاه همچنین می تواند یک کد QR باشد که خواننده می تواند در دستگاه تلفن همراه اسکن کند.

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

در حالی که کاربر از URL تأیید بازدید می کند و وارد کد خود می شود ، دستگاه تا زمانی که خطایی یا نشانه احراز هویت را برگرداند ، نقطه پایانی دسترسی را نظر می دهد. اگر کاربر هنوز درخواست را تأیید نکرده یا رد نکرده است (خطای مجوز_پیلند) ، اگر کاربر درخواست را رد کرده یا درخواست را رد کرده است (خطای Access_denied) ، اگر کاربر هنوز درخواست را تأیید نکرده یا رد نکرده است ، خطاها را برمی گرداند. یا اگر توکن منقضی شده است (خطای منقضی شده).

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

توجه: باز هم ، DigitalOcean در حال حاضر از نوع کمک هزینه کد دستگاه پشتیبانی نمی کند ، بنابراین پیوند در این مثال به یک سرور مجوز خیالی در oauth. example.com اشاره دارد.

مثال استفاده از نشانه دسترسی

هنگامی که برنامه یک نشانه دسترسی داشته باشد ، ممکن است از Token برای دسترسی به حساب کاربر از طریق API ، محدود به دامنه دسترسی ، تا زمانی که توکن منقضی شود یا ابطال شود ، استفاده کند.

در اینجا نمونه ای از درخواست API ، با استفاده از Curl آورده شده است. توجه داشته باشید که شامل نشانه دسترسی است:

با فرض اینکه نشانه دسترسی معتبر باشد ، API درخواست را مطابق با مشخصات API خود پردازش می کند. اگر نشانه دسترسی منقضی شود یا در غیر این صورت نامعتبر باشد ، API خطای نامعتبر_ request را برمی گرداند.

جریان توکن را تازه کنید

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

در اینجا یک درخواست پست به عنوان مثال ، با استفاده از یک نشانه تازه برای به دست آوردن یک نشانه دسترسی جدید وجود دارد:

نتیجه

با پیروی از این راهنما ، شما درک می کنید که چگونه OAUTH 2 کار می کند ، و چه زمانی باید از یک جریان مجوز خاص استفاده شود.

اگر می خواهید در مورد OAUTH 2 اطلاعات بیشتری کسب کنید ، این منابع ارزشمند را بررسی کنید:

آیا می خواهید درخواست خود را به سرعت مستقر کنید؟Cloudways ، ارائه دهنده میزبانی شماره 1 را برای مشاغل کوچک به متوسط ، آژانس ها و توسعه دهندگان-به صورت رایگان امتحان کنید. DigitalOcean و Cloudways در کنار هم تجربه میزبانی قابل اعتماد ، مقیاس پذیر و بدون دردسر را با پشتیبانی از هر زمان به شما ارائه می دهند که همه نگرانی های میزبانی شما را به چیزی از گذشته تبدیل می کند. با اعتبار رایگان 100 دلار شروع کنید!