Забезпечення мого API REST за допомогою OAuth, а ще дозволяти аутентифікацію через сторонніх постачальників OAuth (за допомогою DotNetOpenAuth)

У мене є продукт із простою API REST, щоб користувачі продукту могли безпосередньо інтегруватися з функціями продукту без використання мого веб-інтерфейсу користувача.

Нещодавно у мене з’являвся інтерес від різних третіх сторін щодо інтеграції своїх настільних клієнтів з API, щоб дозволити користувачам мого продукту отримувати доступ до своїх даних за допомогою цього стороннього додатку.

Я бачив, що програми, які хочуть використовувати Twitter, підтверджують автентифікацію за допомогою сторінки входу, розміщеної в Twitter, яка надає певний дозвіл додатку на доступ до даних цього користувача. Ви натискаєте кнопку "Дозволити" або "Заборонити" і процес автентифікації завершено. Facebook використовує той самий механізм, що і найкращий.

Після подальших досліджень, здається, це OAuth в дії, і, вважаючи, що мій API заснований на .Net, я думаю, що я повинен використовувати DotNetOpenAuth і надати подібний механізм. На жаль, зразки є малодокументованими (якщо вони взагалі є), і єдині підручники, які я можу знайти в Інтернеті, здаються зосередженими на тому, щоб допомогти вам забезпечити механізм входу для користувачів, щоб вони могли увійти на ваш веб-сайт за допомогою стороннього постачальника.

Мені б дуже хотілося зробити, щоб мій REST API обробляв усі основні функції автентифікації та бізнес-логіки для мого веб-додатку, і під кришкою мій веб-додаток, по суті, є ще одним додатком, який просто використовує API через OAuth. Користувачі повинні автентифікуватись на веб-сайті або безпосередньо, використовуючи своє ім’я користувача та пароль, або через сторонніх постачальників, таких як MyOpenID або Facebook, і тоді веб-сайт якось використовує повернутий маркер для автентифікації проти API REST.

В основному виглядає так, що мені потрібен мій API, щоб якось розмістити послугу OAuth, але також користувачі використовують послугу OAuth третьої сторони. Я не можу допомогти, але думаю, що мені не достатньо зрозуміти OAuth, щоб вирішити, чи я занадто ускладнюю речі, чи якщо я намагаюся зробити, це хороший чи поганий спосіб робити.

Чи може хтось дати мені, принаймні, широкий огляд кроків, які мені потрібно зробити, або що я повинен переглянути, щоб це відбулося? Або вкажіть мене на якісь підручники? Або підірвіть мою пропозицію і скажіть, що я з цим (архітектурно) все неправильно?

Спершу я хочу підкреслити різницю між автентифікацією та авторизацією:

А користувач перевіряє справжність на вашому веб - сайті з постачання деяких облікових даних , таких як ім'я користувача + пароль. OpenID дозволяє змістити це шляхом надання автентифікації користувача іншій службі, яка потім підтверджує особу користувача на вашому веб-сайті від імені користувача. Ваш сайт довіряє сторонній службі (постачальнику OpenID) і тому вважає користувача, який увійшов у систему.

Служба або додаток НЕ проходить перевірку автентичності на ваш веб - сайт - принаймні , як правило , ні. Користувач уповноважує службу чи програму для доступу до даних користувача. Зазвичай це робиться за допомогою програми, яка запитує авторизацію постачальника послуг, потім надсилає користувача до постачальника послуг, де користувач спочатку підтверджує автентифікацію (тому постачальник послуг знає, з ким спілкується), а потім користувач каже сайту "так, нормально [додаток] отримати доступ до моїх даних [деяким обмеженим способом] ". З цього моменту програма використовує маркер авторизаціїдля доступу до даних користувачів на сайті постачальника послуг. Зауважте, що програма не автентифікує себе так, як ніби це користувач, але використовує інший код, щоб переконати службу, що вона авторизована для доступу до даних певного користувача.

Тож із цим розрізненням з’ясовується, ви можете приймати рішення на своєму сайті про автентифікацію та авторизацію повністю самостійно. Наприклад, якщо ви хочете, щоб ваші користувачі могли увійти в систему з усіма: ім'ям користувача + паролем, OpenID та Facebook, ви можете це зробити. Цілком ортогональне рішення полягає в тому, як ви авторизуєте програми (є багато протоколів, які ви можете використовувати для цього, звичайно, OAuth є досить популярним).

OpenID орієнтований на автентифікацію користувача . OAuth орієнтований на авторизацію додатків . Однак деякі сервіси, такі як Facebook та Twitter, вибрали використовувати OAuth для автентифікації та авторизації замість OpenID для аутентифікації та OAuth для авторизації.

Тепер для вашого власного проекту настійно рекомендую ознайомитись із шаблоном проекту ASP.NET MVC 2 OpenID (C #), доступним у галереї VS. У комплекті з аутентифікацією OpenID та підтримкою постачальника послуг OAuth. Це означає, що ваші користувачі можуть увійти за допомогою OpenID, а сторонні програми та служби можуть використовувати OAuth для здійснення дзвінків API на ваш веб-сайт та доступу до даних користувачів.

Це здається, що ви хочете додати до цього шаблону проекту, як тільки ви розпочнете, це можливість ваших користувачів входити в систему за допомогою імені користувача + пароля, а також OpenID. Крім того, якщо ви хочете, щоб Facebook і Twitter були варіантами для ваших користувачів, ви також повинні їх реалізувати, оскільки вони не використовують стандарт OpenID. Але завантаження DotNetOpenAuth включає зразки для входу в систему з Twitter та Facebook, щоб у вас були певні вказівки.

Я підозрюю, у вас не буде нічого, якщо щось зробити на передній частині дозволу. Поставляється з OAuth, як я вже говорив, і цього вам, мабуть, вистачить.

Поперше. Вам потрібно подумки відокремити, що є вашим API - від методів аутентифікації.

Ваш API - це в основному ресурси та методи маніпулювання цими ресурсами. І ви можете мати кілька методів аутентифікації доступу до API.

OAuth є одним із таких механізмів аутентифікації. Бути постачальником OAuth - це чудово, навіть якщо специфікацію трохи важко зрозуміти, особливо частини, що стосуються підписів. Після того, як у вас є OAuth, клієнтські програми, як правило, легко проходять автентифікацію, оскільки існує стільки "відкритих джерел, що вже зроблено, просто реалізуйте" бібліотеки, доступні на більшості мов.

Про плюси і мінуси OAuth дискутували деякий час. Але для формування власної думки я пропоную прочитати цей остаточний посібник, написаний Ераном Хаммером-Лахавом , одним із людей, відповідальних за специфікацію OAuth.

Наскільки я бачу, єдині реальні альтернативи OAuth - це OAuth 2.0 і просто проста базова аутентифікація.

Окрім цього, ви говорите про автентифікацію за допомогою Open-ID або фейсбук ідентичності тощо. Це ще одне питання, яке вам потрібно задати собі. Але це дійсно виходить за межі API та OAuth. Для мене це більше стосується створення користувачів у вашій службі. Я можу помилятися.