Безпечне зберігання секретних даних у веб-додатку на стороні клієнта

У мене є цей веб-додаток, який буде використовувати всі технології клієнтів (HTML, CSS, JavaScript / AngularJS тощо). Цей веб-додаток буде взаємодіяти з REST API для доступу та зміни даних. Зараз не визначено, який тип системи аутентифікації REST API буде використовувати.

Наскільки я розумію, будь-який тип системи аутентифікації API (API ключі, OAuth 1/2 тощо) має певні дані, які потрібно зберігати в таємниці, інакше доступ може бути порушений. Для ключів API вони повинні бути секретними, для OAuth 2 клієнтська таємниця / маркери доступу / маркер оновлення потрібно зберігати в секреті, я впевнений, що кілька із 4-х клавіш, що беруть участь в OAuth 1, потрібно зберігати в таємниці (не занадто великий досвід роботи з OAuth 1). Я намагався подумати, чи є спосіб зберігати цей секретний матеріал у чистому веб-додатку на стороні клієнта без середнього шару на стороні сервера.

Я намагався подумати над цим, і не можу придумати жодного місця для цього. Я маю на увазі, що я не можу зберігати його в JavaScript, тому що кожен може просто переглянути джерело або відкрити консоль і отримати дані. Я не на 100% впевнений, наскільки безпечний локальний сховище та чи користувачі можуть отримати доступ / змінити ці дані. Навіть якщо локальне зберігання було безпечним, я не можу думати, як отримати дані до нього. Один із способів - просто зберігати дані у вихідному коді JavaScript, що є найнебезпечнішим, про що я можу придумати. Тепер, якщо я використовував щось на кшталт OAuth 2, в якому решта api сама дала би мені лексеми, це все одно не буде настільки безпечним (краще, ніж перший варіант), тому що ці лексеми будуть повернені як звичайний текст, що кожен, хто може побачити запити, які робить комп'ютер, можуть бачити.

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

Ні, це ніколи не може бути повністю безпечним. Користувач контролює обладнання, а ви намагаєтесь щось утримати з їх рук. Зрештою, вони МОЖУТЬ отримати це через ті чи інші засоби. Оскільки ви працюєте з javascript, ваше становище набагато гірше, ніж звичайний комп’ютерний додаток, оскільки не тільки користувач керує обладнанням, вони керують пісочницею, в якій ви працюєте.

Ви можете приховати речі і важко дістатись до речей, але врешті-решт вони МОЖУТЬ це вийняти, якщо вони постараються досить наполегливо.

Розробляючи системи безпеки, завжди потрібно думати про модель загрози. " Зробити це безпечним " - це нерозумна вимога, не підлягає дійсності та перевірки. " Забороняє користувачеві витягувати маркери доступу з програми " набагато краще, і визначає межі рішення. " Не допускати інших користувачів до знаків доступу користувачів " також є кращим і визначає абсолютно інший простір рішення. Рішення для одного необов’язково вирішуватимуть інше ( наприклад , для останнього абсолютно потрібен SSL, якщо задіяний WiFi, але це взагалі не вплине на перший).

один із варіантів полягає в тому, щоб API REST надавав доступ чи не базувався на вході в систему; він може повернути маркер на основі сеансу (наведення, штриховий рядок, що завгодно), який може бути переданий іншим викликам REST API для автентифікації доступу

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

не те, що знайоме з OAuth та ін., але я не бачу переконливої ​​причини вище, щоб взагалі постійно зберігати інформацію автентифікації ...