Як обробляти автентифікацію в архітектурі RESTful Client-Server - це питання дискусії.
Зазвичай це може бути досягнуто у світі SOA через HTTP за допомогою:
- HTTP базовий auth через HTTPS;
- Файли cookie та управління сеансами;
- Позначення в заголовках HTTP (наприклад, OAuth 2.0 + JWT);
- Перевірка автентичності з додатковими параметрами підпису.
Вам доведеться адаптувати або навіть краще змішати ці методи, щоб найкраще відповідати вашій архітектурі програмного забезпечення.
Кожна схема аутентифікації має свої PRO та CON, залежно від мети вашої політики безпеки та архітектури програмного забезпечення.
Базовий протокол HTTP через HTTPS
Це перше рішення, засноване на стандартному протоколі HTTPS, використовується більшості веб-сервісів.
GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Це легко здійснити, доступний за замовчуванням у всіх браузерах, але має деякі відомі недоліки, наприклад, жахливе вікно автентифікації, відображене в браузері, яке зберігатиметься (тут немає функції, схожої на LogOut), деяке додаткове споживання процесора на стороні сервера, і той факт, що ім’я користувача та пароль передаються (через HTTPS) на Сервер (слід бути більш захищеним, щоб пароль залишався лише на стороні клієнта під час введення на клавіатурі та зберігався як захищений хеш на сервері) .
Ми можемо використовувати дайджест аутентифікації , але він також вимагає HTTPS, оскільки він уразливий для атак MiM або Replay і специфічний для HTTP.
Сесія через куки
Якщо чесно, сеанс, керований на сервері, не справді без громадянства.
Однією з можливостей може бути збереження всіх даних у вмісті файлів cookie. І, за задумом, файл cookie обробляється на стороні Сервера (Клієнт насправді навіть не намагається інтерпретувати дані файлів cookie: він просто повертає його назад на сервер при кожному наступному запиті). Але ці файли cookie є даними про стан додатків, тому клієнт повинен керувати ними, а не сервером у чистому світі без громадянства.
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
Сама техніка файлів cookie пов'язана з HTTP, тому вона не є справді RESTful, яка повинна бути незалежною від протоколу, IMHO. Він уразливий для атак MiM або Replay .
Надано через Token (OAuth2)
Альтернативно - помістити маркер у заголовки HTTP, щоб запит був аутентифікований. Так, наприклад, робить OAuth 2.0. Дивіться RFC 6749 :
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
Коротше кажучи, це дуже схоже на файл cookie і страждає від одних і тих самих питань: не без громадянства, покладаючись на деталі передачі HTTP, і з урахуванням багатьох недоліків у безпеці - включаючи MiM та Replay - тому слід використовувати лише через HTTPS. Зазвичай JWT використовується як маркер.
Перевірка автентичності
Автентифікація запитів полягає у підписанні кожного запиту RESTful через деякі додаткові параметри URI. Дивіться цю посилальну статтю .
У цій статті було визначено як таке:
Усі REST-запити повинні бути аутентифіковані, підписуючи параметри запиту, відсортовані в нижньому регістрі, в алфавітному порядку, використовуючи приватний обліковий запис як маркер підписання. Підписання має відбуватися перед URL-кодуванням рядка запиту.
Ця методика, можливо, є більш сумісною з архітектурою без стану, і також може бути реалізована за допомогою легкого управління сеансами (використовуючи сеанси в пам'яті замість стійкості БД).
Наприклад, ось загальний зразок URI за посиланням вище:
GET /object?apiKey=Qwerty2010
має передаватися як таке:
GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789
Рядок, що підписується, є, /object?apikey=Qwerty2010×tamp=1261496500а підпис - це хеш SHA256 цієї рядки з використанням приватного компонента ключа API.
Кешування даних на стороні сервера завжди може бути доступним. Наприклад, в нашій рамках ми кешуємо відповіді на рівні SQL, а не на рівні URI. Тому додавання цього додаткового параметра не порушує механізм кешування.
Дивіться цю статтю для отримання детальної інформації про RESTful аутентифікацію в нашій системі ORM / SOA / MVC клієнт-сервер, заснованої на JSON та REST. Оскільки ми дозволяємо спілкуватися не тільки через HTTP / 1.1, але також іменованими каналами або GDI-повідомленнями (локально), ми намагалися реалізувати справді схему аутентифікації RESTful, а не покладатися на специфіку HTTP (наприклад, заголовка чи куки).
Пізніша примітка : додавання підпису в URI можна сприймати як погану практику (оскільки, наприклад, вона з’явиться в журналах http-сервера), тому її необхідно пом'якшити, наприклад, належним TTL, щоб уникнути повторів. Але якщо ваші http-журнали будуть порушені, у вас, безумовно, виникнуть більші проблеми із безпекою.
На практиці майбутня аутентифікація токенів MAC для OAuth 2.0 може стати величезним покращенням стосовно поточної схеми "Надано токеном". Але ця робота все ще триває і пов'язана з передачею HTTP.
Висновок
Варто зробити висновок, що REST не лише на основі HTTP, навіть якщо на практиці він також здебільшого реалізований через HTTP. REST може використовувати інші шари зв'язку. Отже, RESTful аутентифікація - це не просто синонім автентифікації HTTP, незалежно від того, на що відповість Google. Він навіть не повинен використовувати механізм HTTP взагалі, але повинен бути абстрагований від рівня зв'язку. І якщо ви використовуєте HTTP-зв’язок, завдяки ініціативі Let Encrypt немає причин не використовувати належну HTTPS, яка потрібна на додаток до будь-якої схеми аутентифікації.