همان‌طور که قبلا اشاره شد، پروتکل OAuth دارای دو نسخه است که در این بخش به صورت مختصر در مورد آن‌ها صحبت می‌کنیم.

پروتکل OAuth 1.0 در سال 2007 عرضه شد و بر اساس امضاهای دیجیتال بود. از ویژگی‌هایی که به این پروتکل نسبت می‌دادند، امنیت و قوی بودن آن بود. شرکت‌های بزرگی مثل گوگل و توییتر شروع به استفاده از آن کردند تا این که در سال 2008، گوگل پشتیبانی از آن را شروع کرد. توییتر هم تا سال 2010، همه برنامه‌های شخص ثالث (third-party) خودش را مجبور کرد تا از پروتکل OAuth 1.0 استفاده کنند. اما، OAuth 1.0 به پیاده سازی رمزنگاری و همچنین قابلیت همکاری متقابل با رمزنگاری نیاز داشت و همین موضوع باعث شد برای توسعه‌دهندگان از لحاظ امنیتی یک چالشی ایجاد کند.

نسخه جدید آن با نام OAuth 2.0 در سال 2012 ارائه شد و باز هم خیلی از شرکت‌های بزرگ به استفاده از این پروتکل روی آوردند. این نسخه برای پیاده سازی با زیر ساخت‌های رمزنگاری بسیار ساده‌تر از OAuth 1.0 عمل می‌کرد، اما از لحاظ امنیتی یک سری سازش‌ها را انجام داده بود. با این حال، دلایلی از جمله پشتیبانی از پیاده سازی‌های غیر مرورگر، جدا شدن از تحویل منابع و Authorization باعث شد تا این استاندارد جدید برای شرکت‌های بزرگ و خیلی از شرکت‌های دیگر قابل استفاده باشد. در حال حاضر، بسیاری از شرکت‌های بزرگ از جمله جمله Yahoo، Facebook، Salesforce، Microsoft، Twitter، Deutsche Telekom ، Intuit ، Mozilla و Google از پروتکل OAuth 2.0 استفاده می‌کنند.

عملکرد نسخه‌های OAuth

ممکن است برای شما این سؤال پیش آید که "کدام نسخه OAuth مناسب است؟" شاید فکر کنید که جدید ترین نسخه، مناسب ترین نسخه می‌باشد. اما لزوما این طور نیست. تغییراتی که بین OAuth 1.0 و OAuth 2.0 رخ داد، در واقع ماهیت OAuth را به میزان قابل‌توجهی تغییر داد تا جایی که دو نسخه نیاز‌های متفاوتی را بر اساس آنچه که شما می‌خواهید محقق کنید، برآورده می‌کنند.

در بسیاری از موارد، استفاده از OAuth 1.0 به عنوان یک مجری client-side امکان‌پذیر نیست. یعنی امکان استفاده در برنامه‌های SPA برای آن وجود ندارد. به همین علت گوگل در سال 2012 دیگر از آن استفاده نکرد. اما ناگفته نماند که توییتر هنوز هم از OAuth 1.0 پشتیبانی می‌کند. همچنین اکثر پیاده سازی‌های جدید Authorization Server از OAuth 1.0 استفاده نمی‌کنند. اما در نظر داشته باشید که اگر ارائه دهنده منابع شما هنوز از آن پشتیبانی می‌کند (و متعهد به ادامه پشتیبانی از آن شده است)، هنوز هم می‌توانید از OAuth 1.0 استفاده کنید.

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

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

شکل زیر نمایی از نحوه کار OAuth 1.0 را نشان می‌دهد:

نمایی از نحوه کار OAuth 1.0

بر اساس شکل خواهیم داشت:

ابتدا برنامه کاربردی یا کلاینت (Consumer) یک درخواست به ارائه دهنده (Service Provider) می فرستد و درخواست یک request token می‌کند.
ارائه‌دهنده request token را به آدرس callback کلاینت می‌فرستد.
در مرحله بعد کلاینت، کاربر را به سایت ارائه‌دهنده redirect می‌کند.
ارائه‌دهنده کاربر را لاگین می‌کند و به او پیغام می‌دهد که یک کلاینت می‌خواهد از طرف او فعالیتی انجام دهد. کاربر تصمیم می‌گیرد که این اجازه را بدهد یا نه.
سپس کلاینت یک درخواست برای یک توکن دیگر به نام access token می‌فرستد. ارائه‌دهنده یک توکن دائمی به کلاینت اختصاص می‌دهد و آن را برای او می‌فرستد. وقتی کلاینت این مقادیر را از ارائه‌دهنده دریافت می‌کند، می‌تواند به جای کاربر از امکانات ارائه‌دهنده استفاده کند.

توجه: اگر هرکدام از درخواست‌های OAuth ناقص باشد، یا داده‌ها از دست رفته باشد یا نادرست امضا شده باشد، درخواست رد می‌شود.

شکل زیر نمایی از نحوه کار OAuth 2.0 را نشان می‌دهد:

نمایی از نحوه کار OAuth 2.0

بر اساس شکل OAuth 2.0 خواهیم داشت:

برنامه کاربردی یا کلاینت (Consumer) درخواست دسترسی به اطلاعات کاربر را به ارائه دهنده (Service Provider) ارسال می‌کند. در حقیقت کاربر را به سرور اصلی هدایت می‌کند تا لاگین کند.
اگر کاربر چنین درخواستی را تایید کرده باشد، authorization تایید می‌شود و یک Authorization Code را به کلاینت ارسال می‌کند.
کلاینت از این Authorization Code استفاده کرده و آن را برای گرفتن access token به ارائه دهنده ارسال می‌کند.
ارائه دهنده بر اساس Authorization Code، کلاینت را تایید و access token را به آن می‌دهد.

توجه: اگر هر یک از درخواست OAuth ناقص باشد، داده‌های موجود را از دست دهد، یا حاوی secret اشتباه باشد، درخواست رد می‌شود.

تفاوت‌ های دو نسخه OAuth

برخی از تفاوت‌های ساختاری این 2 نسخه عبارت‌اند از:

در پروتکل OAuth 2.0 چهار نقش Client, Authorization Server, Resource Server و Resource Owner تعریف شده است اما پروتکل OAuth 1.0 از مجموعه ای متفاوت از اصطلاحات و نقش‌ها استفاده می‌کند.
در OAuth 2.0، Client به عنوان مصرف کننده یا consumer، Resource Owner به عنوان کاربر یا user و Resource Server به عنوان ارائه دهنده خدمات یا Service provider شناخته می‌شود. ولی پروتکل OAuth 1.0 نقش‌های Resource Server و Authorization Server را جدا نمی‌کند.
در پروتکل OAuth 1.0، اصطلاحاتی مانند “two-legged” و “three-legged” وجود دارد اما در OAuth 2.0، این موارد با انواع Grant‌ها، مانند Client Credentials grant type و Authorization Code grant type جایگزین شده است.
تفاوت‌هایی در احراز هویت و امضاها (Authentication and Signatures)، تجربه کاربری و موارد مربوط به صدور token جایگزین، عملکرد، توکن‌های حامل (Bearer Tokens) و token‌های کوتاه مدت با مجوزهای ماندگار نیز وجود دارد.
نسخه ی اول Transport-independent می‌باشد یعنی امنیت به HTTPS / TLS محول نمی‌شود و وابسته به این لایه ی شبکه نمی‌شود ولی نسخه ی دوم Transport-dependent می‌باشد یعنی بیشترین دفاع امنیتی به HTTPS / TLS واگذار می‌شود و پیکربندی نامناسبTLS ، عدم اعتبار صحیح صدور گواهینامه یا آسیب پذیری در یک کتابخانه زیرین می‌تواند منجر به حمله man-in-the-middle (MitM) شود و کلیه ارتباطات OAuth را به خطر بیاندازد.
OAuth 1.0 فقط workflow‌های وب را اداره می‌کند، اما OAuth 2.0 مشتری‌های غیر وب را نیز در نظر می‌گیرد.
در نسخه ی اول از امضاهای دیجیتالی برای اثبات صحت یک پیام استفاده می‌شود. امضاهای دیجیتالی می‌توانند از ارسال پیام خاصی از یک منبع خاص اطمینان حاصل کنند و پیام و امضاها به هیچ وجه دستکاری نشده‌اند. یک پیام امضا شده با اصل آن گره خورده است. اما پیاده سازی‌های client-side می‌توانند به صورت ویژه پیچیده باشند. اما در نسخه ی دوم تمرکز بر روی Token است این‌ مورد در عمل آسان تر است اما از نظر امنیتی عالی نیست. امکان کپی یا سرقت آن‌ها وجود دارد اما اجرای آن‌ها ساده‌تر است.

مقایسه ی OAuth1.0 و OAuth2.0