oauth2 получить токен доступа через базу данных по предоставленному идентификатору клиента / секретному ключу для доверенного стороннего клиента
В настоящее время я использую «lucadegasperi / oauth2-server-laravel».
Я делаю конечную точку API для стороннего доверенного клиента и использую грант client_credentials.
Теперь дело в том, что токены доступа имеют тенденцию к истечению, поэтому вместо предоставления стороннему пользователю токена доступа я бы просто предоставил им идентификатор клиента / секретный ключ.
на моей стороне, я бы сделал следующее, когда они сделают запрос curl …
SELECT a.id,
expire_time
FROM oauth_clients as c
left join oauth_sessions as s on s.client_id = c.id
left join oauth_access_tokens as a on a.session_id = s.id
where c.id = 'asfasasf'
and c.secret = 'asfasfasfasf'
order by s.id desc
limit 1;
… Вышеприведенное в значительной степени проверяет наличие маркера доступа и время истечения, связанное с идентификатором клиента / секретом. Я бы просто сгенерировал новый, если бы он не существовал или если бы он истек. Затем пару строк вниз, сделайте скручивание на моей стороне до конечной точки, за которой они следовали, с данным access_token на моей стороне, не беспокоясь об этом.
Я проверил это, и оно работает, но это что-то вроде хитроумного / плохого?
tldr;
- Сторонний клиент — идет в / api / конечную точку с идентификатором клиента / секретным
- моя сторона сервера (проверяет токен доступа в БД, относящийся к идентификатору клиента / секрету)
- генерирует, если не существует или истек срок использования …
- API конечной точки стороннего клиента продолжает использовать выбранный дБ токен доступа
- работает
Это плохой поток?
Решение
Все, что вы сделали, это сделали шаг для их удобства.
Многие люди просто использовали бы библиотеку OAuth2, которую они или кто-то другой написал, и, конечно, это не сработало бы, потому что у вас больше нет стандартной системы OAuth2.
Вы фактически повторно использовали один токен для всех, кто использует клиентское приложение, и я не уверен, что это хорошо. Срок действия токенов истекает из-за проблем безопасности, если кто-то украл токен, вы можете сделать его недействительным и прекратить его доступ, или срок его действия истек, и все. Конечно, у вас нет этой проблемы, поскольку вы на самом деле не передаете токены.
Это также означает, что вы теперь нарушаете другие потоки OAuth2, у многих систем есть токен обновления, который также исчез. Я предполагаю, что это немного упрощает жизнь клиента, но вы не можете сказать, что у вас больше есть система OAuth2, потому что вы этого не делаете.
Клиенты — это те, кому нужно иметь дело с токенами, и их задача — решить, как их хранить и что делать, когда срок действия истекает. Обычно вам не нужно беспокоиться об этом, но теперь вы делаете это, поскольку на самом деле храните клиентские токены на своей стороне.
Еще одна вещь, которую следует учитывать, это то, что вы переместили проблемы безопасности на свою сторону. Теперь вы несете ответственность за безопасность клиентов. Если кто-то получит доступ к вашей базе данных, он может эффективно выдать себя за всех ваших клиентов навсегда, даже если вы или клиент об этом не знаете. С моей точки зрения, наличие токенов в базе данных является плохой идеей и недостатком безопасности, особенно когда клиент не контролирует его.
Другие решения
Так что я решил пойти со следующим:
- конечному потребителю будет предоставлен идентификатор клиента и секрет.
- Так как конечный пользователь основан на доверенном клиентском компьютере, он будет использовать грант клиентских учетных данных и будет получать только маркер доступа.
- конечный потребитель может просто свернуть и получить токен доступа, а затем сделать еще один скручивание ниже предыдущего скручивания с созданным токеном доступа.
- последний завиток, использующий токен доступа, сможет получить доступ к защищенному ресурсу.
detector