Від класичних сесій при роботі через API відмовився.
Сервер отримує запит, бачить що прийшов token, розбиває його через двокрапку на input_id і input_val. Вибирає з бази токен з прийшли input_id, отримує з бази значення token_val і secret. Порівнює input_val і token_val. Якщо в базі знайшовся токен з потрібним id і значення val рівні, прийшов час перевірити достовірність запиту.
Клієнт крім токена передав sign (підпис), яку сформував так (наприклад) secret + api_path + query_param. На стороні сервера вам відомо api_path і api_param, а secret вибрали з бази. Хешировать підпис прийнято через hmac ().
Крім токена і підписи можна передавати time і так само класти його в sign, і на стороні сервера відсікати запити запити яким більше 60 сек.
Якщо хто слухає ваш канал, він не зможе підробляти запити (а значить компрометувати), і через перевірки часу життя запиту не зможе вічно отримувати дані по одного разу перехопленого запиту.
А в базі токени можете зберігати поки клієнт сам не запросить їх знищення і зберегти час последного звернення через токен, і видаляти маркери які не використовувалися понад 60 дн.
D 'Normalization. Такий механізм захищає від підробки запиту, а ваш - немає.
Перехопивши token (до речі, для чого id і val?) І secret, можемо ліпити будь-які запити.
Перехопивши sign = RSA (sha256 (pass + параметри)) ми не розшифруємо рядок, не маючи закритого ключа. Не знаючи пароля не зможемо скласти інший запит.
А пароль можна вкрасти і в вашому, і в моєму випадку, від цього дійсно нічого не врятує, тільки ось провайдер API в цьому випадку не буде винен.
Артем. використовувати один майстер ключ для всіх користувачів - пряма дорога ------> туди.
Не варто морочитися там, де це не потрібно. Якщо у вас дійсно такі чутливі до перехоплення дані, то варто дивитися на більш стійкі рішення (подивіться реалізацію протоколу telegram).
Якщо не хочеться сильно заморочуватися, і так подобається RSA, то варто генерувати для кожного користувача окремі public / private ключі, і щоб свій public ключ він скачував через інше джерело вручну, тоді ніхто нічого не перехопить, і не зможе нашкодити.
Артем. "До речі, для чого id і val?", Тільки щоб з БД вибирати по INT і по ньому ж індекс зробити. Адже кожен запит до API, це перевірка токена. Індекс по числовому полю легше, ніж індекс по varchar.