برای برنامههای وب و موبایل سنتی، جریان کد مجوز OAuth 2.0 استاندارد طلایی احراز هویت امن است. با این حال، این پارادایم استاندارد هنگام اعمال بر روی دستگاههای «بدون صفحهکلید» یا «ورودی محدود» با مانع قابل توجهی روبرو میشود. تصور کنید در حال تلاش برای وارد کردن یک کد الفبایی 64 کاراکتری روی کنترل تلویزیون هوشمند یا یک سنسور IoT بدون رابط کاربری هستید. اصطکاک ایجاد شده نه تنها آزاردهنده است، بلکه از نظر فنی غیرممکن است.
اینجا است که مجوز احراز هویت دستگاه OAuth 2.0 (RFC 8628) درخشش خود را نشان میدهد. همچنین شناخته شده به عنوان «جریان دستگاه»، این پروتکل به طور خاص برای پر کردن شکاف بین دستگاههای ناامن و ارائهدهندگان هویت مبتنی بر مرورگر طراحی شده است. در این پست، ما بررسی خواهیم کرد که چگونه این جریان را برای دستگاههای IoT و تلویزیونهای متصل پیادهسازی کنیم، تا اطمینان حاصل شود که برنامههای شما هم امن و هم کاربرپسند باقی میمانند.
مشکل اصلی: پارادوکس ورودی صفر
چالش اساسی برای برنامههای IoT و تلویزیون، محدودیت ورودی است. این دستگاهها اغلب فاقد یک صفحهکلید کامل QWERTY هستند که ورود دستی رشتههای طولانی را مستعد خطا میکند. علاوه بر این، مجبور کردن کاربر به برداشتن گوشی، باز کردن مرورگر و تایپ یک کد، اصطکاک قابل توجهی ایجاد میکند که منجر به رها کردن کاربر میشود.
جریان دستگاه OAuth 2.0 با جدا کردن کاربر از دستگاه این مشکل را حل میکند. این فرآیند از دستگاه اصلی کاربر (یک گوشی هوشمند یا لپتاپ با صفحهکلید و مرورگر) به عنوان رابط برای احراز هویت استفاده میکند، در حالی که دستگاه محدود (تلویزیون یا سنسور) به عنوان مشتری منتظر دریافت سیگنال عمل میکند. این یک تجربه احراز هویت «دستگاه خود را بیاورید» (BYOD) ایجاد میکند.
پیادهسازی گام به گام جریان دستگاه
پیادهسازی مجوز احراز هویت دستگاه شامل سری از تعاملات API خاص است. در زیر شکافی از مراحل حیاتی، شامل درخواستهای HTTP ضروری آورده شده است.
گام 1: درخواست کدهای دستگاه و کاربر
اولین مرحله شامل تماس دستگاه محدود (مشتری) با نقطه پایانی احراز هویت دستگاه سرور مجوز است. این نقطه پایانی دو کد حیاتی را صادر میکند:
- device_code: یک کد مخفی که توسط دستگاه برای پرسوجو برای بهروزرسانیهای توکن استفاده میشود.
- user_code: کدی که به کاربر روی صفحه دستگاه نمایش داده میشود.
// کد شبه برای درخواست اولیه
POST /oauth/v2/device_authorization HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
client_id=your_client_id
scope=openid%20profile%20emailسرور با یک شیء JSON پاسخ میدهد که حاوی device_code، user_code، verification_uri و expires_in (مدت زمان اعتبار کدها، معمولاً 5 تا 10 دقیقه) است.
گام 2: نمایش کد کاربر
دستگاه محدود باید اکنون user_code و verification_uri را به کاربر نمایش دهد. برای یک تلویزیون هوشمند، این یک پیام ساده دو خطی روی صفحه است. از کاربر خواسته میشود تا به URI در دستگاه شخصی خود مراجعه کند و کد را وارد کند.
نمایش نمونه:
---------------------
برای ورود، با استفاده از مرورگر وب خود به آدرس زیر مراجعه کنید:
https://auth.example.com/activate
و کد زیر را وارد کنید:
ABCD-1234
---------------------گام 3: پرسوجو برای دریافت توکن دسترسی
در حالی که کاربر در مرورگر خود احراز هویت میکند، دستگاه محدود باید نقطه پایانی توکن را پرسوجو کند. این کار با استفاده از device_code که در گام 1 دریافت شده است انجام میشود. فاصله زمانی پرسوجو باید بر اساس پارامتر interval که در گام 1 بازگردانده شده است محاسبه شود (اگر ارائه نشده باشد، به طور پیشفرض 5 ثانیه در نظر گرفته میشود).
// حلقه پرسوجو
while (true) {
response = POST /oauth/v2/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:device_code
&device_code=DEVICE_CODE_FROM_STEP_1
&client_id=your_client_id
if response.status == 200:
break // توکن دسترسی دریافت شد
else if response.status == 400 and response.error == "authorization_pending":
wait(interval seconds)
continue
else if response.status == 400 and response.error == "slow_down":
wait(interval * 1.5 seconds) // کاهش نمایی
continue
}گام 4: مدیریت مجوز کاربر
پس از اینکه کاربر کد را وارد کرد و درخواست را در مرورگر خود تأیید کرد، پرسوجوی بعدی از دستگاه یک پاسخ 200 OK حاوی access_token، refresh_token و id_token بازگردانده میشود. دستگاه میتواند سپس برای دسترسی به منابع محافظت شده اقدام کند یا جلسه را ذخیره نماید.
بهترین شیوهها برای امنیت و تجربه کاربری
اگرچه این جریان استاندارد است، اما جزئیات پیادهسازی برای امنیت و قابلیت استفاده اهمیت قابل توجهی دارد.
1. اعمال زمانهای پایان: هم device_code و هم user_code باید مدت زمان اعتبار کوتاهی داشته باشند (مثلاً 5 دقیقه). اگر کاربر نتواند این جریان را در این پنجره زمانی تکمیل کند، کدها باید نامعتبر شوند و دستگاه باید مجموعه جدیدی را درخواست کند. این خطر دستکاری کدهای منسوخ شده را کاهش میدهد.
2. مدیریت خطاهای «کاهش سرعت»: اگر سرور مجوز یک خطای slow_down بازگرداند، نشاندهنده این است که نرخ پرسوجو بیش از حد بالا است. دستگاه باید کاهش نمایی را پیادهسازی کند تا از محدود شدن نرخ یا سیاهلیست شدن جلوگیری شود.
3. پاک کردن کدهای کاربر روی صفحه: اگر پرسوجو به دلیل خطا یا زمان پایان ناموفق باشد، اطمینان حاصل کنید که دستگاه یک پیام خطا نمایش دهد و کد قبلی را پاک کند و کاربر را ملزم به شروع یک جریان جدید کند. هرگز از کدهای منسوخ شده استفاده مجدد نکنید.
4. شناسایی مشتری: اطمینان حاصل کنید که client_id به طور امن روی دستگاه ذخیره شده و به راحتی از باینریهای کامپایل شده قابل استخراج نیست، به ویژه برای دستگاههای IoT متنباز. اگر ارائهدهنده شما از آن پشتیبانی میکند، در نظر بگیرید که از احراز هویت مشتری مبتنی بر گواهی استفاده کنید.
نتیجهگیری
مجوز احراز هویت دستگاه OAuth 2.0 یک ابزار ضروری برای توسعهدهندگان مدرنی است که تجربیات متصل را میسازند. با انتزاع پیچیدگی محدودیتهای ورودی، این امکان را به سازندگان IoT و توسعهدهندگان برنامههای تلویزیون میدهد تا امنیت در سطح سازمانی را بدون به خطر انداختن تجربه کاربری ارائه دهند. با گسترش مستمر اینترنت اشیاء، تسلط بر این جریان برای ایجاد برنامههای امن، بدون اصطکاک و مقیاسپذیر حیاتی خواهد بود.
چه در حال ساخت یک ترموستات هوشمند، یک کنسول بازی یا یک سیستم رسانه خانگی هستید، پذیرش جریان دستگاه تضمین میکند که معماری امنیتی شما همگام با قابلیتهای سختافزاری شما پیش میرود.