laravel 5.3 паспорт и угловое хранение токенов доступа
Я проверяю подлинность пользователей для использования моего собственного API (таким образом, надежный источник). Я пытаюсь определить, где находится лучшее место для хранения возвращаемого access_token на стороне клиента? Я создаю cookie или сохраняю данные в локальном хранилище?
Также я должен только хранить access_token, я должен записать refresh_token? Для чего используется токен обновления?
Решение
Безопаснее, если вы сохраняете токен доступа только на стороне клиента, даже если срок действия вашего токена обновления истекает через определенный промежуток времени, хотя это уменьшает окно возможных атак.
Это один из способов сделать это (если вы хотите сохранить доступ & обновить токены):
https://stackoverflow.com/a/18392908/5549377
Однако есть и другой способ сделать это.
Таким образом, клиент получит только токен доступа, а токен обновления полностью скрыт от пользователя. Но для этого токен доступа, а также токен обновления должны храниться на стороне сервера. Лучшее место в базе данных. Это поднимает очевидный вопрос: безопасность? Ответ: вы всегда можете зашифровать данные, которые хранятся в базе данных, и максимально обезопасить свою базу данных.
- Создайте таблицу (таблица user_token), в которой можно хранить user_id, токен доступа, refresh_token и даже session_id.
- При каждом входе в систему проверяйте, существует ли запись под user_id в таблице user_token. Если он не существует, запросите OAuth / маркер и сохраните токен доступа и обновления в таблице user_token.
- После успешного входа в систему вы можете написать функцию .run в своем угловом углу, чтобы запросить токен доступа для пользователя. (помните, в таблице user_token у нас был столбец «user_id». Следовательно, вы можете запросить фильтр текущего зарегистрированного пользователя из
Auth::id()функция в Laravel. - Как только токен доступа найден, сервер должен вернуть токен доступа и токен доступа только клиенту.
- После того как клиент получил токен доступа, вы можете выполнить рукопожатие на маршруте, который защищен
'middleware' => 'auth:api'добавив полученный access_token в заголовок следующим образом:$http.defaults.headers.common.Authorization = 'Bearer ' + data.access_token;, Также после этого убедитесь, что вы добавляете тот же токен в переменную корневого каталога, как показано ниже:$rootScope.accesstoken = data.access_token; - Если вызов рукопожатия успешен, то вы можете добавить действительный токен доступа из корневого каталога в угловой файл cookie следующим образом:
$cookies.put('access_token', $rootScope.accesstoken); - Если рукопожатие не удалось, вы можете запросить новый токен. Чтобы запросить новый токен, используйте новый маршрут, который перенаправит на отдельную функцию. Эта функция будет извлекать токен обновления под user_id текущего пользователя и запрашивать новый токен доступа из конечной точки oAuth (см. Документацию Passport API). Как только вы сделаете это, обновите запись под пользователем в таблице ‘user_tokens’ и верните новый токен доступа веб-клиенту. Со стороны веб-клиента сохраните полученный токен в угловом файле cookie следующим образом:
$cookies.put('access_token', $rootScope.accesstoken);и добавьте этот же токен в заголовки http:$http.defaults.headers.common.Authorization = 'Bearer ' + data.access_token;
Кстати, почему я упомянул, что я должен хранить токен в угловом cookie? Хорошо, если вы храните его только на rootscopeЕсли страница обновляется, приложению придется снова запросить токен, потому что все данные в угловом корне утеряны после обновления. Но в угловатых печеньках это не так. следовательно, именно поэтому я предложил добавить к угловому cookie.
Очень важно:
Для каждого запроса ajax, который вы делаете, если запрос завершается с ошибкой с кодом 401 (несанкционированный доступ), вы должны вызывать функцию запроса нового токена от углового до запроса новой функции токена Laravel. И как только он будет успешным, вставьте этот новый токен в заголовок http и в угловой файл cookie, как я уже упоминал.
Замечания:
Смысл токена обновления состоит в том, чтобы убедиться, что вы являетесь аутентифицированным пользователем для старого токена доступа (давайте назовем токен ххх).
Вы можете использовать токен доступа, пока он истекает. После этого вам нужно сообщить серверу, что вы не можете использовать этот access_token ххх и срок его действия истек, так что дайте мне новый токен. Когда вы делаете этот запрос (чтобы дать вам новый токен), сервер должен знать, что вы являетесь законным пользователем предыдущего токена доступа, поэтому сервер попросит вас доказать, что вы законны. В это время вы можете предъявить токен обновления и доказать серверу, что вы законны. Это использование токена обновления.
Так как же сервер проверит вашу законность по токену обновления?
Первоначально, когда вы запрашивали токен доступа, вы получаете токен обновления, так что в этом случае сервер узнает.
Я предлагаю вам прочитать и узнать больше об OAuth 2.0.
Другие решения
Недавно я рассмотрел некоторые варианты хранения токенов на стороне клиента, поэтому я отсылаю вас к ответ представлен в: Где сохранить JWT в браузерном приложении.
Короче говоря, файлы cookie и веб-хранилище являются подходящими вариантами хранения токенов доступа, и правильный выбор зависит от вашего конкретного сценария.
По отношению к тому, что вы должны хранить, обычно это просто токен доступа, потому что обновить токены как правило, не выдаются приложениям на основе браузера, поскольку они являются долгоживущими учетными данными, а это означает, что время, которое кто-то пытается их украсть, значительно увеличено, и у всех вариантов хранения в браузере есть свои недостатки.
Токен обновления также представляет особый интерес, когда клиентское приложение хочет иметь доступ к защищенным ресурсам, принадлежащим конечному пользователю, даже когда пользователь не взаимодействует с приложением; обычно называется автономным доступом. Большинство сценариев для приложений на основе браузера по-прежнему подразумевают, что пользователь находится в сети, поэтому отсутствие маркеров обновления не так уж важно.