Как сделать так, чтобы мой токен аутентификации работал безопасно?

Question

Я создаю систему аутентификации с React-Native / PHP / MySQL, где у вас есть следующие шаги:

1. Логин пользователя: пользователь вводит свое имя пользователя и пароль , токен генерируется в БД и его срок действия 5 минут

2. Действия: если пользователь хочет выполнить какое-либо действие, кроме ВЫХОДА, в API отправляется запрос POST с действием и токен

3. Проверить токен: проверяет, действителен ли токен (существует в БД), и если он истек, если это так, он обновляет время истечения и выполняет действие

У меня есть вопросы:

1. Дублируется ли токен? Это 64-символьный токен, но он всегда должен иметь возможность дублироваться
2. Если кто-то по какой-либо причине получает этот токен, этот человек может делать несколько вещей в учетной записи пользователя. Итак, я думал о продлении токена, генерируя еще один просроченный случай, это лучший способ?

Это лучший способ для системы аутентификации токена?

Answer 1

Если вы хотите быстро с этим справиться, и это не то, чем вы хотите заниматься для развлечения, а что-то, что вам нужно интегрировать в свой проект, то я бы go с OAuth или аналогичный пакет, который уже существует.

В противном случае:

1. Рекомендуется убедиться, что ваш токен уникален. Вы можете установить поле для таблицы как уникальное, поэтому, когда вы попытаетесь сохранить его, но оно существует, вы получите сообщение об ошибке и можете сгенерировать другое. (1) ИЛИ вы можете создать алгоритм, который будет гарантировать что токен не существует в базе данных. Для этого вы можете использовать временную метку и, возможно, идентификатор пользователя для токена ha sh алгоритм.

Например:

$token = md5(uniqid(mt_rand(), true));

Почему хорошо не разрешать токены для дублирования?

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

Допустим, администратор получил токен (123), а позже - другой. user - возможно, клиент получит такой же токен (123). В этом случае, если вы проверяете разрешения на конечной точке API для запроса, вы должны сохранить идентификатор пользователя вместе с токеном, а во время проверки разрешений вам также необходимо добавить дополнительное условие для проверки идентификатора пользователя, в противном случае клиент может получить токен администратора и с его помощью получить доступ к конечным точкам / функциям администратора.

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

Так что это не обязательно, но проще.

Для истечения срока действия токена у вас есть 3 варианта. Это следующие:

• Кратковременные токены доступа и долгоживущие refre sh маркеры
• Кратковременные маркеры доступа и без refre sh токены
• Нет токены доступа с истекающим сроком действия

подробнее о них можно прочитать здесь