RESTful API Auth flow

Question

Я был на переполнении стека в течение последнего часа, исследуя эту тему, поэтому я подумал, что просто задаю все свои конкретные вопросы. Я создаю веб-приложение, в настоящее время использующее Laravel (PHP) для API и Angular для фронта. Я посмотрел на oAuth, но это немного сложный atm, поэтому я надеялся реализовать более простое решение, а затем перестроить его, когда это необходимо.

Поток, который я сейчас реализую, выглядит следующим образом. Угловые сообщения учетных данных пользователя (выше https) для моего бэкэнд-покоя, и это просто возвращает сгенерированную строку (это, вероятно, будет случайным или критографическим). Затем эта строка сохраняется как файл cookie или любое другое состояние браузера, которое я нахожу подходящим, а затем прикрепляется к каждому запросу API вместе с идентификатором пользователя, который угловой делает в качестве дополнительного параметра или заголовка запроса или чего-то еще. API использует это, чтобы проверить, имеет ли пользователь доступ к запрашиваемому ресурсу и соответственно отвечает. Вероятно, я также добавлю время истечения срока действия строки, которая будет сбрасываться после каждого запроса.

Вопрос в том, действительно ли это приемлемый поток? Что касается безопасности, с какими проблемами я, скорее всего, столкнусь с этим? CSRF? Фиксация сеанса?

Я знаю, что это вопрос, который задавали пару раз раньше, но я просто надеялся на новую дискуссию и указал на соответствующую информацию.

Answer 1

Спасибо за то, что вы ввели все. В конечном итоге я решил снова взглянуть на OAuth 2, как было предложено. То, что я пытался создать, было в значительной степени потоком OAuth в любом случае ... Вместо того, чтобы пытаться воссоздать колесо, я посмотрел на реализации другими людьми OAuth в PHP (и Laravel), и эта практическая реализация действительно помогла мне получить эту идею.

Я использовал этот пакет в конце

https://github.com/thephpleague/oauth2-server

обернутым для Laravel

https://github.com/lucadegasperi/oauth2-server-laravel

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

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

Кто-нибудь еще, что попадается это с подобным вопросом должны взглянуть на следующие ссылки:

http://alexbilbie.com/2013/02/a-guide-to-oauth-2-grants/

http://tools.ietf.org/html/rfc6749

Они действительно помогли мне понять OAuth 2.

Answer 2

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

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

Answer 3

Что вы описываете, это своего рода базовая реализация сеанса. Так как у REST есть ограничения без учета состояния, которые отрицают такие вещи, я не думаю, что это приемлемое решение. Afaik вы должны отправить имя пользователя и пароль с каждым запросом от доверенных клиентов. Если у вас есть сторонние клиенты, вы должны генерировать ключи api и использовать токены для них (OAuth может решить эту часть). Если вы хотите узнать больше о ограничениях REST, прочитайте Fielding dissertation.