паспорт laravel 5.3 и угловое хранение токенов доступа

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

Это один из способов сделать это (если вы хотите хранить токены доступа и обновления):

https://stackoverflow.com/a/18392908/5549377

Однако есть и другой способ сделать это. Таким образом, клиент получит только токен доступа, а токен обновления будет полностью скрыт от пользователя. Но для этого токен доступа, а также токен обновления должны храниться на стороне сервера. Лучшее место в базе данных. Отсюда возникает очевидный вопрос: безопасность? Что ж, ответ на этот вопрос заключается в том, что вы всегда можете зашифровать данные, хранящиеся в базе данных, и максимально защитить свою базу данных.

1. Создайте таблицу (таблицу user_token), в которой можно хранить user_id, токен доступа, refresh_token и даже session_id.
2. При каждом входе в систему проверяйте, существует ли запись под user_id в таблице user_token. Если он не существует, запросите oauth/token и сохраните доступ и токен обновления в таблице user_token.
3. После успешного входа в систему вы можете написать функцию .run в своем angular, чтобы запросить токен доступа для пользователя. (помните, что в таблице user_token у нас был столбец «user_id». Следовательно, вы можете запросить фильтрацию текущего вошедшего в систему пользователя из функции Auth::id() в laravel.
4. Как только токен доступа найден, сервер должен вернуть токен доступа и токен доступа только клиенту.
5. После того, как клиент получил токен доступа, вы можете выполнить квитирование маршрута, защищенного 'middleware' => 'auth:api', добавив полученный токен доступа в заголовок следующим образом: $http.defaults.headers.common.Authorization = 'Bearer ' + data.access_token;. Также после этого убедитесь, что вы добавили тот же токен в переменную rootscope, например: $rootScope.accesstoken = data.access_token;
6. Если вызов рукопожатия прошел успешно, вы можете добавить действительный токен доступа из корневой области в угловой файл cookie следующим образом: $cookies.put('access_token', $rootScope.accesstoken);
7. Если вызов рукопожатия не удался, вы можете запросить новый токен. Чтобы запросить новый токен, используйте новый маршрут, который будет перенаправлять на отдельную функцию. Эта функция извлечет токен обновления под user_id текущего пользователя и запросит новый токен доступа из конечной точки oAuth (см. документы Passport API). Как только вы это сделаете, обновите запись под пользователем в таблице user_tokens и верните новый токен доступа веб-клиенту. На стороне веб-клиента сохраните полученный токен в файле cookie angular следующим образом: $cookies.put('access_token', $rootScope.accesstoken); и добавьте тот же токен в заголовки http, например: $http.defaults.headers.common.Authorization = 'Bearer ' + data.access_token;

Кстати, почему я упомянул, что должен хранить токен в угловом файле cookie. Хорошо, если вы сохраните его только на rootscope, если страница обновится, приложению придется снова запросить токен, потому что все данные в угловой корневой области теряются после обновления. Но в угловом файле cookie это не так. поэтому я предложил добавить в угловой файл cookie.

Очень важный:

Для каждого запроса ajax, который вы делаете, если запрос завершается ошибкой с кодом 401 (несанкционированный доступ), вы должны вызывать функцию запроса нового токена из angular в функцию запроса нового токена Laravel. И как только это будет успешно, вставьте этот новый токен в заголовок http и угловой файл cookie, как я уже упоминал.

Примечание.

Токен обновления предназначен для проверки того, что вы являетесь аутентифицированным пользователем для старого токена доступа (назовем токен xxx).

Вы можете использовать токен доступа до тех пор, пока срок его действия не истек. Как только это произойдет, вам нужно сообщить серверу, что вы не можете использовать этот access_token xxx и срок его действия истек, поэтому дайте мне новый токен. Когда вы делаете этот запрос (чтобы предоставить вам новый токен), сервер должен знать, что вы являетесь законным пользователем предыдущего токена доступа, поэтому сервер попросит вас подтвердить, что вы законны. В это время вы можете предъявить токен обновления и доказать серверу, что вы законны. Это использование токена обновления.

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

Я предлагаю вам прочитать и узнать больше об OAuth 2.0.

Недавно я рассмотрел некоторые варианты хранения токенов на стороне клиента, поэтому я отсылаю вас к ответу , приведенному в: Где сохранить JWT в браузерное приложение.

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

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

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