Блог

Главная - Вопросы по программированию - Использует ли Passport guardians не для аутентификации пользователей, а для проверки токенов доступа на маршрутах, где эти токены требуются?

Использует ли Passport guardians не для аутентификации пользователей, а для проверки токенов доступа на маршрутах, где эти токены требуются?

#laravel #oauth-2.0 #laravel-7 #laravel-passport #laravel-authentication

#ларавель #oauth-2.0 #laravel-7 #laravel-паспорт #laravel-аутентификация

Вопрос:

Меня немного смущает документация. Сказано:

Паспорт включает в себя защиту аутентификации, которая будет проверять токены доступа
при входящих запросах. После того как вы настроили api guard на использование драйвера passport, вам нужно только указать промежуточное программное обеспечение auth: api на любых маршрутах, для которых требуется действительный токен доступа.


Таким образом, это означает, что Passport использует guardians не для аутентификации пользователей, а для проверки токенов доступа на маршрутах, где эти токены требуются. Правильно ли я это понял?

Ответ №1:

В этом случае проверка токена доступа является аутентификацией пользователя. Чтобы понять, почему это так, давайте рассмотрим упрощенный процесс аутентификации с использованием JWTs (давайте немного проигнорируем OAuth2).

  1. Пользователь входит в систему на веб-сайте. Это запускает POST /login запрос с username и password в теле запроса.
  2. Серверная часть проверяет учетные данные пользователей. Если учетные данные действительны, он выдаст JWT, который будет действовать как токен доступа. Полезная нагрузка JWT будет содержать некоторые данные, которые позволяют серверной части идентифицировать пользователя, например, идентификатор пользователя. Затем JWT подписывается секретом, который знает только серверная часть.
  3. Серверная часть вернет токен доступа клиенту, который должен включить токен доступа в любые последующие запросы к серверу. Обычно клиент предоставляет токен в Authorization заголовке.
  4. При обработке следующего запроса от клиента серверная часть извлекает токен доступа из Authorization заголовка и проверяет его подпись. Если подпись действительна, серверная часть может быть уверена, что данные токена не были изменены, например, путем изменения идентификатора пользователя в токене доступа. С действительной подписью серверная часть может извлечь идентификатор пользователя из полезной нагрузки токенов и установить User модель для этого конкретного идентификатора как аутентифицированную. С недопустимой подписью серверная часть, вероятно, вернет что-то вроде 401 Unauthorized .