oauth2 получить токен доступа через db по предоставленному идентификатору/секретарю клиента для доверенного стороннего клиента

Question

В настоящее время я использую «lucadegasperi/oauth2-server-laravel».

Я создаю конечную точку api для стороннего доверенного клиента и используя грант client_credentials.

Теперь дело в том, что токены доступа, как правило, истекли, поэтому вместо того, чтобы предоставить стороннему пользователю токен доступа, я просто поставлю им идентификатор/секрет клиента.

на моей стороне я бы сделать следующее, когда они делают локон запрос ...

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;

1. третий клиент сторона - переходит в/API/конечной точки с идентификатором клиента/секретный
2. моей стороне сервера (проверяет маркер доступа в БД, связанной с идентификатором клиента/секретный)
3. генерирует, если не существует или истек срок использования ...
4. третья сторона клиента конечная точка апи продолжает использовать дб выбранный маркер доступа
5. работы

это плохой поток?

Answer 1

Все, что вы сделали, это сделать шаг для их удобства.

Многие люди просто используют библиотеку OAuth2, которую они или кто-то еще написал, и, конечно же, это не сработает, потому что у вас больше нет стандартной системы OAuth2.

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

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

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

Еще одна вещь, которую следует учитывать, заключается в том, что вы переместили проблемы безопасности на свою сторону. Теперь вы отвечаете за безопасность клиентов. Если кто-то получает доступ к вашей базе данных, то они могут эффективно олицетворять всех ваших клиентов навсегда более чем вероятно, даже если вы или клиент не узнаете об этом.С моей точки зрения наличие токенов в базе данных - плохая идея и недостаток безопасности, особенно когда клиент не контролирует ее.

Answer 2

Так что я решил, я бы следующим:

1. конечный потребитель будет обеспечен с идентификатором клиента и секрет.
2. Поскольку конечный пользователь является надежным клиентским компьютером, он будет использовать грант клиентских полномочий и получать только токен доступа.
3. Конечный потребитель может просто завивать и извлекать токен доступа, а затем делать другой завиток под предыдущим завитком с помощью генерируемого токена доступа.
4. последний завиток, используя токен доступа, сможет получить доступ к защищенному ресурсу.