Хранение токенов API в базе данных.

Question

У меня есть несколько компаний, использующих мою конечную точку GET, каждая компания должна иметь свой собственный ключ API, который они предоставят в качестве параметра url.

Мне нужно продолжать генерировать эти токены всякий раз, когда присоединяется новая компания (есть таблица, отражающая это).

Безопасно ли просто: - создать company_token сводную таблицу - сгенерировать токен как str_random(32) (поскольку у запроса GET может быть максимальная длина URL)

? Или есть более безопасный и лучший метод?

Answer 1

База данных

Самый простой и безопасный способ хранения токена API уровня компании - это то, что вы уже делаете - использование безопасного PRNG для получения HTTP-безопасного токена, что и является str_random() и наличие уникального ограничения на таблицу токенов API, чтобы быть уверенным, что вы не получите дубликаты.

UX

Вы также можете предоставить способ изменения токена API компанией, после подходящего входа в систему, чтобы позволить им избавиться от устаревших или утекших токенов. Поскольку вы обновляете строку API и не сохраняете старые значения, отслеживание устаревших токенов не будет проблемой.

Безопасность (насколько это возможно)

Чтобы не отправлять токен явно в URL, вы также можете получить их из пользовательского заголовка HTTP, как подсказывает @AbdurRahman.

Наконец, вы можете использовать токен только один раз для сеанса и для каждого клиента: токен API может будет использоваться только /nonce API, который ответит более длинным токеном в форме "IP: DATE: HA SH" (например, "192.168.168.192:2020.02.16.15.35:ee2998d477ee4a1b50e886590d228239"), что быть около 64 байтов. Ха sh будет производиться MD5 («IP: DATE: SECRET»), что гарантирует, что информация не была подделана. Все последующие API просто подтверждают, что этот токен не изменен, IP-адрес совпадает, и дата не слишком далека в прошлом (или будущем).

Преимущество заключается в том, что отправляемый токен теперь отличается для каждого клиент и меняется каждый раз, поэтому, даже если он будет перехвачен, будет нанесен небольшой ущерб. «Настоящий» токен, который будет вреден, если перехвачен, отправляется только один раз за сеанс; Есть более безопасные схемы, чем это, но это уже будет улучшение.

Answer 2

Лучшее решение, я думаю, было бы использовать JWT. Вы можете генерировать токен для каждой компании и распространять их.

Вместо отправки токена в URL-адресе в качестве параметра запроса используйте заголовок авторизации HTTP-запроса и отправьте токен в качестве токена-носителя.