Передумови: я написав стеки клієнтів і серверів для OAuth 1.0a та 2.0.
Як OAuth 1.0a, так і 2.0 підтримують двосторонній аутентифікацію , де сервер впевнений в ідентичності користувача, і триногу автентифікацію , коли сервер забезпечується постачальником контенту про особу користувача. Тристороння аутентифікація - це те, коли починають грати запити на авторизацію та маркери доступу, і важливо зазначити, що OAuth 1 теж має.
Складний: триногий аутентифікацію
Основним моментом специфікацій OAuth є надання контент-провайдеру (наприклад, Facebook, Twitter тощо), щоб запевнити сервер (наприклад, веб-додаток, який хоче поговорити з постачальником контенту від імені клієнта), що клієнт має певну особу . Те, що пропонує тристороння аутентифікація, - це можливість зробити це без того, щоб клієнту чи серверу ніколи не потрібно було знати деталі цієї особи (наприклад, ім’я користувача та пароль).
Не надто глибоко заглиблюючись у деталі OAuth:
- Клієнт подає сервер запит на авторизацію, який підтверджує, що клієнт є законним клієнтом своєї послуги.
- Сервер перенаправляє клієнта до постачальника вмісту, щоб запитувати доступ до його ресурсів.
- Постачальник вмісту підтверджує особу користувача та часто просить їх дозволу на доступ до ресурсів.
- Постачальник контенту перенаправляє клієнта назад на сервер, повідомляючи його про успіх чи збій. Цей запит включає код авторизації щодо успіху.
- Сервер робить позапрофільний запит до постачальника вмісту та обмінюється кодом авторизації на маркер доступу.
Тепер сервер може робити запити до постачальника вмісту від імені користувача, передаючи маркер доступу.
Кожен обмін (клієнт-> сервер, сервер-> постачальник вмісту) включає перевірку загальної таємниці, але оскільки OAuth 1 може працювати через незашифроване з'єднання, кожна перевірка не може передавати секрет через провід.
Це зроблено, як ви вже зазначали, з HMAC. Клієнт використовує секрет, яким він ділиться з сервером, для підписання аргументів для запиту на авторизацію. Сервер бере аргументи, підписує їх самим ключем клієнта і може переконатися, чи це законний клієнт (на кроці 1 вище).
Цей підпис вимагає, щоб і клієнт, і сервер домовились про порядок аргументів (тому вони підписують точно однаковий рядок), і одна з головних скарг на OAuth 1 полягає в тому, що він вимагає як сервера, так і клієнтів сортувати і підписувати однаково. Це химерний код, і це правильно, або ви отримуєте 401 Unauthorizedз невеликою допомогою. Це збільшує бар’єр для написання клієнтом.
Вимагаючи запиту авторизації для запуску SSL, OAuth 2.0 усуває потребу в сортуванні аргументів та підписанні взагалі. Клієнт передає свою таємницю серверу, який перевіряє його безпосередньо.
Такі самі вимоги є і в підключенні сервера до постачальника вмісту, і оскільки це SSL, що усуває один бар'єр для написання сервера, який отримує доступ до послуг OAuth.
Це значно спрощує дії на кроках 1, 2 та 5 вище.
Тож на даний момент наш сервер має постійний маркер доступу, який є еквівалентом імені користувача / пароля для користувача. Він може робити запити до постачальника вмісту від імені користувача, передаючи маркер доступу як частину запиту (як аргумент запиту, заголовок HTTP або дані форми POST).
Якщо доступ до служби вмісту доступний лише через SSL, ми закінчили. Якщо це доступно через звичайний HTTP, ми хотіли б якось захистити цей постійний маркер доступу. Усі, хто нюхає з'єднання, зможуть отримати доступ до вмісту користувача назавжди.
Спосіб, який вирішується в OAuth 2, - це ознака оновлення . Маркер оновлення стає постійним еквівалентом пароля, і він передається тільки через SSL . Коли сервер потребує доступу до служби вмісту, він обміняє маркер оновлення на короткочасний маркер доступу. Таким чином, всі нюхаючі доходи HTTP робляться з маркером, який закінчується. Google використовує 5-хвилинний термін дії своїх API-дисків OAuth 2.
Таким чином, окрім жетонів оновлення, OAuth 2 спрощує всі комунікації між клієнтом, сервером та постачальником вмісту. А маркери оновлення існують лише для забезпечення безпеки, коли доступ до вмісту не шифрується.
Дві ноги аутентифікації
Однак іноді серверу просто потрібно контролювати доступ до власного вмісту. Двостороння аутентифікація дозволяє клієнту аутентифікувати користувача безпосередньо з сервером.
OAuth 2 стандартизує деякі розширення до OAuth 1, які широко використовувались. Той, кого я найкраще знаю, був представлений у Twitter як xAuth . Ви можете бачити його в OAuth 2 як ідентифікатори пароля власника ресурсу .
По суті, якщо ви можете довірити клієнтові облікові дані користувача (ім’я користувача та пароль), вони можуть обмінятися ними безпосередньо з постачальником контенту на маркер доступу. Це робить OAuth набагато кориснішим для мобільних додатків - при тристоронній аутентифікації вам потрібно вбудувати HTTP-перегляд, щоб обробляти процес авторизації на сервері вмісту.
Що стосується OAuth 1, це не було частиною офіційного стандарту, і воно вимагало тієї ж процедури підписання, що і всі інші запити.
Я щойно реалізував серверну частину OAuth 2 з використанням облікових даних власників ресурсів, і з точки зору клієнта отримання маркера доступу стало простим: запросити маркер доступу з сервера, передавши ідентифікатор / секрет клієнта як заголовок авторизації HTTP та логін / пароль користувача як дані форми.
Перевага: простота
Отже, з точки зору впроваджувача, основні переваги, які я бачу в OAuth 2, полягають у зниженій складності. Він не вимагає процедури підписання запиту, що не зовсім складно, але, безумовно, химерно. Це значно скорочує роботу, необхідну для того, щоб діяти як клієнт послуги, і саме там (у сучасному мобільному світі) найбільше хочеться мінімізувати біль. Знижена складність на кінці сервера-> постачальника вмісту робить його більш масштабованим у центрі обробки даних.
І це кодифікує в стандарт деякі розширення до OAuth 1.0a (як xAuth), які зараз широко використовуються.