Як я повинен архітектувати RESTful веб-сервіс для використання третьої сторони (тобто Google, Facebook, Twitter) для аутентифікації?

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

Цього року ми хочемо розширити наші параметри входу, щоб користувачі на веб-сайті могли увійти через Google, Twitter та Facebook (можливо, інші). Однак у мене виникають багато проблем, щоб розібратися, як це створити, щоб веб-сервіс міг використовувати сторонніх постачальників аутентифікації, щоб переконатися, що користувачі є такими, якими вони кажуть. Чи є найкращі практики, як це зробити?

В даний час ми думаємо про те, щоб веб-сайт обробляв автентифікацію самих користувачів, а потім використовував новий виклик setSessionId, який реєструє їх поточний сеанс із зворотним кінцем веб-сервісу. Кожен додатковий запит до веб-сервісу передасть цей сеансId і підтвердить його. Це здається нормальним, але у мене є таке відчуття в задній частині голови, що я не замислююсь над цим, і весь мій перегляд форуму та читання специфік oauth та openid просто мене більше бентежить. Будь-які поради, як вирішити це?

Здається, є дві цілі:

1. Кінцевим користувачам легко пройти автентифікацію за допомогою наявних соціальних акаунтів
2. Легко для розробників, що використовують вашу веб-службу

Дозвіл людей використовувати ресурси на вашому сайті робить OAuth2 кращим механізмом через популярність та доступність клієнтських бібліотек.

1. Легко для кінцевих користувачів пройти автентифікацію за допомогою наявних соціальних акаунтів

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

Коли користувач перенаправляється назад на ваш сайт з Facebook, ви зберігаєте інформацію цього користувача в записі користувача у вашій базі даних, а потім генеруєте новий сеанс для цього користувача. Ви негайно перенаправляєте кінцевого користувача на їх початковий нижній веб-сайт за допомогою oauth access_token, завершуючи оригінальний потік oauth.

2. Легко для розробників, які використовують вашу веб-службу

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

Для розробника, який використовує ваш приємний API відпочинку, вони не будуть в курсі взаємодії у Facebook, якщо ви не вирішите дати їм підказку через публікацію сеансу захоплення (наприклад).

TL; DR

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

Зображення, тому що малюнок == слова * 1000:

Чи можемо ми назвати це oauth2-piggy-back?

Покроковий потік

1. Кінцевий користувач відвідує сайт, який використовує ваш API
2. Кінцевий користувач надсилається на ваш сайт для авторизації або реєстрації (oauth2)
3. Кінцевий користувач вибирає соціальну службу, натискає кнопку входу у facebook
4. На вашому веб-сайті встановлюється файл cookie або встановлюється stateу фейсбуці, щоб знати, звідки прийшов користувач
5. Кінцевий користувач перенаправляється на Facebook і приймає з'єднання на сайті facebook
6. Кінцевий користувач перенаправляється на ваш сайт, щоб завершити процес авторизації facebook
7. Ви шукаєте або створюєте користувача у своїй базі даних
8. Ви створюєте новий сеанс на своєму сервері
9. Ви перенаправляєте користувача назад на його початковий сайт за допомогою маркера сеансу

Як зробити його розширюваним

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

На жаль, вам потрібно два з них, тому що ще не перескочив щебет OAuth2.

OAuth потребує вас, щоб створити інтерфейс для аутентифікаційної сторони. Токени будуть обмінятися сервером на сервер. Створіть одну точку входу, яка може обробляти все спілкування.

Маркер повинен зберігатися в окремій таблиці від вашого облікового запису, це тому, що їх може бути кілька маркерів і кілька пов'язаних профілів. Деякі сервіси надають вам два жетони, один з них - маркер оновлення.

Тепер ви розробляєте інтерфейс, який інкапсулює інші необхідні вам функції. Я особисто створив для цього окремий REST-сервіс. Таким чином ви можете легко поширити аутентифікацію на інші місця.
Деякі сервіси використовують JSON для спілкування, інші - для XML тощо. Для переднього користувача потрібно їх усіх уніфікувати. Це досить болісний процес, але тут можна отримати деякі загальні підстави.

Ще одна проблема тут полягає в тому, що не всі сервіси забезпечують однаковий функціонал. Це може означати, що ваші служби не можуть надати повний API, як ви вказали. Тут ви повинні мати стратегію, яка дозволяє програмі вишукано знижуватись.

Це все дозволить вам легко додати нових сторонніх постачальників.

Проблеми з токеном

Токени обмежені в часі, тому вам потрібно пара крон-завдань, яка може перевірити, чи маркер все-таки корисний, інакше вам доведеться його видалити. Ви також можете оновити маркер за допомогою цього механізму.

Іноді трапляється, що користувач відкликає маркер. Будьте готові до цього.

Зберігання даних

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

Для додаткової перевірки ви можете зберігати профілі в окремій, але пов’язаній з вами таблиці, для користувачів. Це дасть вам набагато більше інформації про когось.

Також перевірте свої місцеві закони, для деяких даних вам потрібні додаткові заходи безпеки.

Останнє Не робіть провини, коли ви не створюєте обліковий запис на власних послугах. Якщо користувачеві забороняють користуватися facebook, він фактично не зможе увійти у вашу послугу. Це ситуація, яку ви не хочете створювати. Це часто не помічається.

Я, безумовно, підходитиме до рішення, яке звучить так, як ви вже з'ясували: впровадити аутентифікацію третьої сторони на своєму клієнтському веб-сайті, а потім пов’язати ці сторонні аутентифікати сторонніх користувачів з обліковими записами вашого веб-сайту, а потім остаточно запустити ваш виклик setSessionID вхід.

Залежно від архітектури вашого веб-сайту, ви можете використовувати бібліотеку типу EveryAuth або Passport дуже корисно.

Мої два центи: я ніколи раніше подібного не робив, і не знаю, як працюють механізми входу в FB, Twitter чи Google, але кілька питань вискакували в моїй голові, як тільки я прочитав ваше запитання:

• Кілька входів: що трапиться, якщо я ввійду через свій акаунт у Facebook один день, а наступний - мій обліковий запис Google? Або одночасно? Чи ставитесь ви до цих двох облікових записів як до унікальних, окремих облікових записів або вам слід мати якийсь спосіб пов’язати їх і дозволити мені отримати доступ до своїх квитків будь-яким способом?
• Покладаючись на зовнішні ідентифікатори: Що станеться, коли Facebook чи Twitter вирішать змінити вигляд своїх ідентифікаторів облікових записів? Для ілюстрації, якщо BazLogin представляє унікальний обліковий запис з використанням коду {4382-af56}, але вирішує, що відтепер у рахунках буде 12 цифр, оскільки 8 було недостатньо, то як вам сказати {1234-4382-af56} від {0000-4382 -af56}?

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

Я не впевнений, що я вирішив питання, які ви мали на увазі, але ви не згадали конкретних проблем. Я сподіваюся, що моя відповідь була корисною в будь-якому випадку.