Шаблон входу в API REST API

Я створюю REST api, уважно дотримуюся пропозицій apigee, використовуючи іменники не дієслова, версію api, запечену в URL, два шляхи api на колекцію, GET POST PUT DELETE використання тощо.

Я працюю над системою входу, але не впевнений у правильному способі REST для входу в систему користувачів. На даний момент я не працюю над безпекою, просто входом або потоком входу. (Пізніше ми будемо додавати два кроки oAuth, з HMAC тощо)

Можливі варіанти

• POST на щось подібне https://api...com/v1/login.json
• ПУТ на щось подібне https://api...com/v1/users.json
• Щось мені не хотілося ...

Який належний стиль REST для входу в систему користувачів?

Принциповий дизайн сучасної веб-архітектури Роя Т. Філдінга та Річарда Н. Тейлора , тобто послідовність робіт із усієї термінології REST, містить визначення взаємодії клієнт-сервер:

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

Це обмеження виконує чотири функції, перша і третя важливі в даному конкретному випадку:

• По-перше : це усуває будь-яку потребу в роз'ємах, щоб зберегти стан програми між запитами , таким чином зменшивши споживання фізичних ресурсів та покращивши масштабованість;
• 3-те : це дозволяє посереднику переглядати та розуміти запит поодиноко , що може знадобитися, коли служби динамічно переставляються;

А тепер повернемося до вашої справи безпеки. Кожен окремий запит повинен містити всю необхідну інформацію, і авторизація / автентифікація не є винятком. Як цього досягти? Буквально надсилайте всю необхідну інформацію по дротах із кожним запитом.

Одним із прикладів того, як це зробити архівним способом, є код аутентифікації на основі хешу або HMAC . На практиці це означає додати хеш-код поточного повідомлення до кожного запиту. Хеш-код, розрахований за допомогою криптографічного хеш-функції в поєднанні з секретним криптографічним ключем . Криптографічна хеш-функція є або заздалегідь визначеною, або частиною концепції REST за запитом коду (наприклад, JavaScript). Секретний криптографічний ключ повинен надаватися сервером клієнтові як ресурс, і клієнт використовує його для обчислення хеш-коду для кожного запиту.

Прикладів реалізації HMAC дуже багато , але я хотів би, щоб ви звернули увагу на наступні три:

• Автентифікація запитів на REST для служби простого зберігання Amazon (Amazon S3)
• Відповідь Mauriceless на запитання: "Як реалізувати аутентифікацію HMAC в API RESTful WCF"
• crypto-js: реалізація JavaScript стандартних та захищених криптографічних алгоритмів

Як це працює на практиці

Якщо клієнт знає секретний ключ, то він готовий працювати з ресурсами. В іншому випадку він буде тимчасово перенаправлений (код статусу 307 Тимчасовий перенаправлення) для авторизації та отримання секретного ключа, а потім буде перенаправлений назад до вихідного ресурсу. У цьому випадку не потрібно заздалегідь знати (тобто десь жорсткий код), що таке URL-адреса для авторизації клієнта , і можна вчасно коригувати цю схему.

Сподіваюся, що це допоможе вам знайти правильне рішення!

TL; DR Вхід для кожного запиту не є обов'язковим компонентом для реалізації безпеки API, автентифікація є.

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

REST не диктує жодних правил безпеки, але найпоширенішою реалізацією на практиці є OAuth з тристоронній аутентифікацією (як ви вже згадували у своєму запитанні). Сам по собі немає входу, принаймні, не з кожним запитом API. З тристороннім аутентифікацією ви просто використовуєте маркери.

1. Користувач схвалює клієнт API і надає дозвіл на запити у вигляді довгожилого маркерів
2. Клієнт Api отримує короткочасний маркер, використовуючи довгожитель.
3. Клієнт Api надсилає нетривалий маркер із кожним запитом.

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

Я просто не думаю, що ви повинні ставити свою проблему (і питання) з точки зору входу, а краще думати про забезпечення API взагалі.

Для отримання додаткової інформації про автентифікацію API REST в цілому, ви можете переглянути такі ресурси:

• http://www.infoq.com/news/2010/01/rest-api-authentication-schemes
• Аутентифікація API REST
• Аутентифікація API RESTful

Значна частина філософії REST полягає у використанні якомога більше стандартних функцій протоколу HTTP при розробці вашого API. Застосовуючи цю філософію до аутентифікації, клієнт та сервер використовували б стандартні функції аутентифікації HTTP в API.

Екрани для входу відмінно підходять для випадків використання людьми: відвідайте екран входу, вкажіть користувача / пароль, встановіть cookie, клієнт надає цей cookie у всіх майбутніх запитах. Не можна очікувати, що люди, які використовують веб-браузери, нададуть ідентифікатор користувача та пароль для кожного окремого HTTP-запиту.

Але для API REST, екран входу та файли cookie сеансу не є суворо необхідними, оскільки кожен запит може включати облікові дані, не впливаючи на людину; і якщо клієнт не співпрацює в будь-який час, 401може бути надіслана "несанкціонована" відповідь. RFC 2617 описує підтримку аутентифікації в HTTP.

TLS (HTTPS) також був би варіантом і дозволяв би аутентифікувати клієнта до сервера (і навпаки) у кожному запиті, перевіряючи відкритий ключ іншої сторони. Крім того, це забезпечує канал для отримання бонусу. Звичайно, для цього необхідний обмін клавіатурою до спілкування. (Зверніть увагу, мова йде саме про ідентифікацію / автентифікацію користувача за допомогою TLS. Захист каналу за допомогою TLS / Diffie-Hellman - це завжди хороша ідея, навіть якщо ви не ідентифікуєте користувача за його відкритим ключем.)

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