Laravel 5.6 - Passport JWT httponly cookie-аутентификация SPA для самопотребляющего API? - PullRequest
0 голосов
/ 08 декабря 2018

ПРИМЕЧАНИЕ. У меня было 4 щедрости на этот вопрос, но ни один из приведенных ниже ответов не является ответом, необходимым для этого вопроса.Все, что нужно, находится в обновлении 3 ниже, просто ищите код Laravel для реализации.


ОБНОВЛЕНИЕ 3: Эта блок-схема точно поток, который я пытаюсьдля достижения цели, все ниже - оригинальный вопрос с некоторыми более старыми обновлениями.Эта блок-схема суммирует все необходимое.

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

enter image description here


Я сделал многоисследования, но информация всегда была короткой и неполной, когда дело доходит до использования Laravel с cookie-файлом JWT httponly для самопотребляющего API (большинство онлайн-уроков показывают только то, что JWT хранится в локальном хранилище, которое не очень безопасно).Похоже, что файл cookie httponly, содержащий JWT by Passport, должен использоваться для идентификации пользователя на стороне Javascript при отправке каждого запроса на сервер для проверки того, что пользователь является тем, кем, по его словам, он является.

Есть такженекоторые дополнительные вещи, которые необходимы, чтобы иметь полное представление о том, как заставить эту установку работать, с которой я не сталкивался ни в одном учебнике, который покрывает это:

  1. Laravel Passport (не Tymon Auth) длясгенерируйте зашифрованный JWT и отправьте его как файл cookie httponly в качестве ответа после входа в систему со стороны JS.Какое промежуточное программное обеспечение использовать?Если токены обновления повышают безопасность, как реализовать?
  2. JavaScript (например, axios) псевдокод API, который выполняет вызов конечной точки аутентификации, как cookie httponly передается в бэкэнд и как действительный токен проверки бэкэнда действителен.
  3. Если одна учетная запись вошла с нескольких устройств, то устройство украдено, как отозвать доступ со всех авторизованных пользовательских устройств (если пользователь меняет пароль с зарегистрированного устройства, которым он управляет)?
  4. Что бы выглядело как методы входа / регистрации, выхода из системы, смены пароля, забытого пароля для создания / проверки / отзыва токенов?
  5. Интеграция токенов CSRF.

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

ОБНОВЛЕНИЕ1:

  1. Обратите внимание, что я пробовал CreateFreshApiToken раньше, но это не сработало, когдаречь идет об отзыве токенов пользователя (для пунктов 3 и 4 выше).Это основано на этом комментарии основного разработчика laravel, когда речь идет о CreateFreshApiToken промежуточном программном обеспечении:

токены JWT, созданные этим промежуточным ПО, нигде не хранятся,Они не могут быть отозваны или «не существуют».Они просто предоставляют способ авторизации ваших вызовов API через cookie-файл laravel_token.Это не связано с токенами доступа.Кроме того: обычно вы не используете токены, выпущенные клиентами в том же приложении, которое их выпускает.Вы бы использовали их в первом или стороннем приложении.Либо используйте промежуточное программное обеспечение, либо клиент выдал токены, но не оба одновременно.

Так что, кажется, можно удовлетворить пункты 3 и 4, чтобы отозвать токены, это невозможно сделать, еслис использованием промежуточного программного обеспечения CreateFreshApiToken.

На стороне клиента кажется, что Authorization: Bearer <token> - это не тот путь, когда имеешь дело с безопасным файлом cookie httpOnly.Я думаю, что запрос / ответ должен включать в себя защищенный файл cookie httpOnly в качестве заголовка запроса / ответа, например, на основе документов laravel:

При использовании этого метода аутентификации по умолчаниюСтроительные леса JavaScript Laravel инструктируют Axios всегда отправлять заголовки X-CSRF-TOKEN и X-Requested-With.

headerswindow.axios.defaults.headers.common = {
    'X-Requested-With': 'XMLHttpRequest',
    'X-CSRF-TOKEN': (csrf_token goes here)
};

Это также причина, по которой я ищу решение, которое охватывает все пункты выше.Извините, я использую Laravel 5.6, а не 5.5.

ОБНОВЛЕНИЕ 2:

Кажется, комбинация Предоставление пароля / Обновление токена - это способидти.Ищите простое руководство по внедрению, используя Предоставление пароля / Обновление маркера * Комбо .

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

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

Я ищу простой в реализации, простой, целостныйответьте с помощью комбо Password Grant / Refresh Token Grant , которое охватывает все части вышеуказанных оригинальных 5 пунктов с помощью httpOnly secure cookie, созданием / отзывом / обновлением токенов, созданием cookie для входа в систему, отзывом cookie для выхода из системы, методами контроллера,CSRF и т. Д.

Ответы [ 4 ]

0 голосов
/ 02 января 2019

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

Какой тип гранта OAuth 2.0 мне следует использовать?

Это первое, что нужно решить.Когда дело касается SPA, возможны два варианта:

  1. Предоставление кода авторизации (рекомендуется при условии, что секретный ключ клиента хранится на стороне сервера)
  2. Предоставление учетных данных пароля владельца ресурса

Причины, по которым я не упоминаю тип неявного предоставления в качестве опции:

  1. Отсутствует шаг аутентификации клиента с предоставлением секретного кода клиента и кода авторизации.Таким образом, снижается уровень безопасности
  2. Токен доступа отправляется обратно в виде фрагмента URL (чтобы токен не отправлялся на сервер), который будет оставаться в истории браузера
  3. Если XSS-атака произойдетзлонамеренный сценарий может очень хорошо отправить токен на удаленный сервер, контролирующий злоумышленника

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

В случае типа предоставления кода авторизации сервер авторизации обычно является сервером, отличным от сервера ресурсов.Лучше хранить сервер авторизации отдельно и использовать его как общий сервер авторизации для всех SPA в организации.Это всегда рекомендуемое решение.

Здесь (в типе предоставления кода авторизации) поток выглядит следующим образом:

  1. пользователь нажимает кнопку входа на целевой странице SPA
  2. пользовательперенаправляется на страницу авторизации сервера авторизации.Идентификатор клиента указывается в параметре запроса URL
  3. . Пользователь вводит свои учетные данные и нажимает кнопку входа в систему.Имя пользователя и пароль будут отправлены на сервер авторизации с использованием HTTP POST.Учетные данные следует отправлять в теле или заголовке запроса, а НЕ в URL (так как URL-адреса регистрируются в истории браузера и на сервере приложений).Кроме того, должны быть установлены надлежащие кэширующие заголовки HTTP, чтобы учетные данные не кэшировались: Cache-Control: no-cache, no-store, Pragma: no-cache, Expires: 0
  4. Сервер авторизации аутентифицирует пользователя по пользовательской базе данных (скажем, LDAPсервер), где имя пользователя и хэш пароля пользователя (алгоритмы хеширования, такие как Argon2, PBKDF2, Bcrypt или Scrypt) хранятся со случайной солью
  5. При успешной аутентификации сервер авторизации извлекает из своей базы данных перенаправлениеURL против предоставленного идентификатора клиента в параметре запроса URL.URL-адрес перенаправления - это URL-адрес сервера ресурсов
  6. Затем пользователь будет перенаправлен на конечную точку сервера ресурсов с кодом авторизации в параметре запроса URL-адреса
  7. Затем сервер ресурсов выполнит запрос HTTP POSTк серверу авторизации для токена доступа.Код авторизации, идентификатор клиента, секрет клиента должны быть указаны в теле запроса.(Следует использовать соответствующие заголовки кэширования, как указано выше)
  8. Сервер авторизации возвращает токен доступа и токен обновления в теле или заголовке ответа (с соответствующим заголовком кэширования, как упомянуто выше)
  9. сервер ресурсов теперь перенаправляет пользователя (код ответа HTTP 302) на URL-адрес SPA, устанавливая соответствующие файлы cookie (что будет подробно объяснено ниже)

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

Также см. Мой ответ по этому здесь для получения дополнительной информации о типе гранта Владельца ресурса.

Здесь может быть важно отметить, что в SPA все защищенные маршруты должны быть включены только после вызова соответствующей службы, чтобы убедиться, что в запросе присутствуют действительные токены.Точно так же защищенные API должны также иметь соответствующие фильтры для проверки токенов доступа.

Почему я не должен хранить токены в локальном хранилище или хранилище сессии?

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

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

  2. localstorage и sessionstorage не являются общими для поддоменов.Таким образом, если у нас есть два SPA, работающих на разных поддоменах, мы не получим функцию единого входа, поскольку токен, сохраненный одним приложением, не будет доступен для другого приложения в организации

Однако, если токены все еще хранятся в любом из этих хранилищ браузера, необходимо включить надлежащий отпечаток пальца.Отпечаток пальца - это криптографически сильная случайная строка байтов.Строка Base64 необработанной строки будет затем сохранена в файле cookie HttpOnly, Secure, SameSite с префиксом имени __Secure-.Правильные значения атрибутов Domain и Path.Хэш строки SHA256 также будет передан в заявке JWT.Таким образом, даже если атака XSS отправляет токен доступа JWT удаленному серверу, управляемому злоумышленником, он не может отправить исходную строку в файле cookie, и в результате сервер может отклонить запрос на основании отсутствия файла cookie.Кроме того, XSS и внедрение сценариев могут быть дополнительно смягчены путем использования соответствующего content-security-policy заголовка ответа.

Примечание:

  1. SameSite=strict гарантирует, что данный файл cookie не будетсопровождать запросы, исходящие с другого сайта (AJAX или по следующей гиперссылке).Проще говоря - любой запрос, исходящий от сайта с тем же «регистрируемым доменом», что и целевой сайт, будет разрешен.Например, если «http://www.example.com" является именем сайта, регистрируемым доменом является« example.com ». Дополнительные сведения см. В ссылке № 3 в последнем разделе ниже. Таким образом, он обеспечивает некоторую защиту от CSRF.Однако это также означает, что если указан URL-адрес форума, то аутентифицированный пользователь не может перейти по ссылке. Если это серьезное ограничение для приложения, можно использовать SameSite=lax, что разрешит межсайтовые запросы, покаМетоды HTTP безопасны: GET, HEAD, OPTIONS и TRACE. Поскольку CSRF основан на небезопасных методах, таких как POST, PUT, DELETE, lax все еще обеспечивает защиту от CSRF

  2. , чтобы разрешитьcookie, который будет передаваться во всех запросах на любой поддомен «example.com», атрибут домена cookie должен быть установлен как «example.com»

Почему я долженхранить токен доступа и / или обновить токен в файлах cookie?

  1. При хранении токенов в файлах cookie мы можем установить cookie как secure и httpOnly. Таким образом, если XSS происходит, вредоносныйСценарий не может прочитать и отправить их на удаленный сервер.XSS может по-прежнему выдавать себя за пользователя из браузера пользователя, но если браузер закрыт, скрипт не сможет нанести дальнейший ущерб.Флаг secure гарантирует, что токены не могут быть отправлены через незащищенные соединения - SSL / TLS является обязательным
  2. Установка корневого домена в файле cookie, например, domain=example.com, гарантирует, что файл cookie будет доступен для всех суб-области.Таким образом, разные приложения и серверы в организации могут использовать одни и те же токены.Вход в систему требуется только один раз

Как проверить токен?

Токены обычно являются токенами JWT.Обычно содержимое токена не является секретным.Следовательно они обычно не зашифрованы.Если требуется шифрование (возможно, из-за того, что некоторая конфиденциальная информация также передается внутри токена), существует отдельная спецификация JWE.Даже если шифрование не требуется, нам необходимо обеспечить целостность токенов.Никто (пользователь или злоумышленник) не должен иметь возможности изменять токены.Если они это сделают, сервер должен быть в состоянии обнаружить это и отклонить все запросы с поддельными токенами.Чтобы обеспечить эту целостность, токены JWT имеют цифровую подпись с использованием такого алгоритма, как HmacSHA256.Для генерации этой подписи необходим секретный ключ.Сервер авторизации будет владеть и защищать секрет.Всякий раз, когда api сервера авторизации вызывается для проверки токена, сервер авторизации пересчитывает HMAC на переданном токене.Если он не совпадает с входным HMAC, он возвращает отрицательный ответ.Токен JWT возвращается или сохраняется в кодированном формате Base64.

Однако для каждого вызова API на сервере ресурсов сервер авторизации не участвует в проверке токена.Сервер ресурсов может кэшировать токены, выданные сервером авторизации.Сервер ресурсов может использовать сетку данных в памяти (то есть Redis) или, если все не может быть сохранено в ОЗУ, базу данных на базе LSM (то есть Riak с уровнем DB) для хранения токенов.

Для каждого вызова API сервер ресурсов проверяет свой кэш.

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

  2. Если токен доступа действителен, но срок его действия истек (обратите внимание, что токены JWT обычно содержат имя пользователя и дату окончания срока действия, помимо прочего), API должны возвращать соответствующийответное сообщение и код ответа 401, так что SPA может вызывать соответствующий API сервера ресурсов для обновления токена доступа с помощью маркера обновления (с соответствующими заголовками кэша).Затем сервер вызывает сервер авторизации с токеном доступа, токеном обновления и секретом клиента, а сервер авторизации может возвращать новые токены доступа и обновления, которые в конечном итоге передаются в SPA (с соответствующими заголовками кэша).Затем клиент должен повторить исходный запрос.Все это будет обрабатываться системой без вмешательства пользователя.Можно создать отдельный файл cookie для хранения токена обновления, аналогичного токену доступа, но с соответствующим значением для атрибута Path, чтобы токен обновления не сопровождал каждый запрос, но был доступен только в запросах на обновление

  3. Если токен обновления недействителен или срок его действия истек, API должны возвращать соответствующее ответное сообщение и код ответа 401, чтобы SPA мог перенаправить пользователя на соответствующую страницу, где пользователю будет предложено повторно войти в систему

Зачем нам нужны два токена - токен доступа и токен обновления?

  1. Токен доступа обычно имеет короткий срок действия, например, 30 минут.Обновление токена обычно длится более 6 месяцев.Если токен доступа каким-либо образом скомпрометирован, злоумышленник может выдать себя за пользователя-жертву только до тех пор, пока токен доступа действителен.Поскольку у злоумышленника не будет секрета клиента, он не сможет запросить у сервера авторизации новый токен доступа.Однако злоумышленник может запросить сервер ресурсов на обновление токена (как в приведенной выше настройке, запрос на обновление проходит через сервер ресурсов, чтобы избежать сохранения секретного ключа клиента в браузере), но с учетом других принятых шагов это маловероятно и, более того, сервер можетпринять дополнительные меры защиты на основе IP-адреса.

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

А как насчет CSRF?

  1. Чтобы защитить пользователя от CSRF, мы можем следовать подходу, применяемому в таких средах, как Angular (как описано в Angular HttpClient Документация , где сервер должен отправлять не-HttpOnly cookie (в другихслова «читаемый файл cookie», содержащие уникальное непредсказуемое значение для этого конкретного сеанса. Это должно быть криптографически сильное случайное значение. Затем клиент всегда будет читать файл cookie и отправлять значение в настраиваемом заголовке HTTP (кроме запросов GET & HEAD, которые не являютсядолжна иметь какую-либо логику изменения состояния. Примечание CSRF не может читать что-либо из целевого веб-приложения из-за одной и той же политики происхождения), чтобы сервер мог проверить значение из заголовка и файла cookie. Так как междоменные формы не могут прочитать файл cookie или установитьпользовательский заголовок, в случае запросов CSRF, тПользовательское значение заголовка будет отсутствовать, и сервер сможет обнаружить атаку

  2. Чтобы защитить приложение от CSRF входа, всегда проверяйте заголовок referer и принимайте запросы только тогда, когда referer является доверенным доменом.Если заголовок referer отсутствует или домен не внесен в белый список, просто отклоните запрос.При использовании SSL / TLS referrer обычно присутствует.Целевые страницы (которые в основном являются информационными и не содержат форму входа или какой-либо защищенный контент) могут быть немного ослаблены и разрешать запросы с отсутствующим referer заголовком

  3. TRACE HTTP-метод должен быть заблокированна сервере, так как это может быть использовано для чтения httpOnly cookie

  4. Кроме того, установите заголовок Strict-Transport-Security: max-age=<expire-time>; includeSubDomains, чтобы разрешить только защищенные соединения, чтобы предотвратить любое вмешательство пользователясредняя перезапись файлов cookie CSRF из субдомена

  5. Кроме того, следует использовать настройку SameSite, как указано выше

Наконец, SSL/ TLS является обязательным для всех соединений - так как на сегодняшний день версии TLS ниже 1.1 неприемлемы для соответствия PCI / DSS. Для обеспечения прямой секретности и аутентифицированного шифрования должны использоваться надлежащие комплекты шифров. Кроме того, маркеры доступа и обновления должны быть внесены в черный список каккак только пользователь явно щелкнет «Выход», чтобы предотвратить любую возможность неправильного использования токена.

Ссылки

  1. RFC 6749 - OAuth2.0
  2. Шпаргал OWASP JWT
  3. SameSite Cookie IETF Draft
  4. Префиксы cookie
  5. RFC 6265 - Cookie
0 голосов
/ 27 декабря 2018

Я также внедрил паспорт Laravel в свой проект, и я думаю, что я рассмотрел большинство вопросов, которые вы упомянули в своем вопросе.

  1. Я использовал предоставление пароля для генерации токена доступаи обновить токен.Вы можете выполнить эти шаги, чтобы настроить паспорт и реализовать его.В вашем методе входа необходимо проверить учетные данные пользователя, сгенерировать токены и прикрепить cookie ( Присоединение cookie к ответу ) к ответу.Если вам нужно, я могу привести несколько примеров.
  2. Я добавил два промежуточного программного обеспечения для CORS (Обработка заголовков входящего запроса) и для проверки, является ли входящий токен доступа действительным или нет, если он недействителен, сгенерируйте токен доступа изсохраненный токен обновления ( обновляющий токен ).Я могу показать вам пример.
  3. После входа в систему весь запрос со стороны клиента должен содержать заголовок авторизации (Authorization: Bearer <token>).

Дайте мне знать, если вы не увереныс вышеуказанными точками.

0 голосов
/ 31 декабря 2018

Laravel Passport JWT

  1. Чтобы использовать эту функцию, вам необходимо отключить сериализацию файлов cookie.В Laravel 5.5 есть проблема с сериализацией / десериализацией значений cookie.Вы можете прочитать больше об этом здесь (https://laravel.com/docs/5.5/upgrade)

  2. Убедитесь, что

    • у вас есть <meta name="csrf-token" content="{{ csrf_token() }}"> в вашей головке шаблона лезвия

    • axios настроен на использование csrf_token при каждом запросе.

У вас должно быть что-то подобное в resources/assets/js/bootstrap.js

window.axios.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';
let token = document.head.querySelector('meta[name="csrf-token"]');

if (token) {
  window.axios.defaults.headers.common['X-CSRF-TOKEN'] = token.content;
} else {
  console.error('CSRF token not found: https://laravel.com/docs/csrf#csrf-x-csrf-token');
}
Настройка маршрутов авторизации, описанная здесь (https://laravel.com/docs/5.5/authentication) Паспорт установки, объяснение здесь (https://laravel.com/docs/5.5/passport).

Важными частями являются:

  • добавитьLaravel\Passport\HasApiTokens Признак вашей User модели
  • Установите опцию driver для api защиты аутентификации на passport в вашем config/auth.php
  • добавьте промежуточное ПО \Laravel\Passport\Http\Middleware\CreateFreshApiToken::class,в вашу web группу промежуточного программного обеспечения в app/Http/Kernel.php

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

Сделайте POST-запрос к /login, передав ваши учетные данные.Вы можете сделать запрос AJAX или отправить обычную форму.

Если запросом на вход является AJAX (с использованием axios), ответными данными будет HTML, но вас интересует код состояния.

axios.get(
  '/login, 
  {
    email: 'user@email.com',
    password: 'secret',
  },
  {
    headers: {
      'Accept': 'application/json', // set this header to get json validation errors.
    },
  },
).then(response => {
  if (response.status === 200) {
      // the cookie was set in browser
      // the response.data will be HTML string but I don't think you are interested in that
    }
    // do something in this case
}).catch(error => {
  if (error.response.status === 422) {
    // error.response.data is an object containing validation errors
  }
  // do something in this case
});

При входе в систему сервер находит пользователя по предоставленным учетным данным, генерирует токен на основе информации о пользователе (идентификатор, адрес электронной почты ...) (этот токен нигде не сохраняется), затем сервер возвращает ответ сзашифрованный файл cookie, содержащий сгенерированный токен.

Выполните вызов API для защищенного маршрута.

Предполагая, что у вас есть защищенный маршрут

Route::get('protected', 'SomeController@protected')->middleware('auth:api');

Вы можете сделать вызов ajax, используякак обычно.Файлы cookie устанавливаются автоматически.

axios.get('/api/protected')
  .then(response => {
    // do something with the response
  }).catch(error => {
    // do something with this case of error
  });

Когда сервер получает вызов, расшифровывает запрос laravel_cookie и получает информацию о пользователе (например, id, email ...). Затем с этой информацией пользователя выполняется поиск в базе данных.проверить, существует ли пользователь.Если пользователь найден, он получает доступ к запрошенному ресурсу.В противном случае возвращается 401.

Аннулирование токена JWT.Поскольку вы упоминаете комментарий, вам не нужно беспокоиться об этом, поскольку этот токен нигде не сохраняется на сервере.

Обновление

Относительно пункта 3 В Laravel 5.6 Auth появился новый метод logoutOtherDevices.Вы можете узнать больше здесь (https://laracasts.com/series/whats-new-in-laravel-5-6/episodes/7), поскольку документация очень проста.

Если вы не можете обновить свою версию Laravel, вы можете проверить, как это делается в 5.6, и построить собственную реализациюдля 5.5

Пункт 4 из вашего вопроса. Посмотрите на контроллеры, найденные в app/Http/Controllers/Auth.

Что касается access_tokens и refresh_tokens, это совершенно другой и более сложный подход. Вы можете найти множествоонлайн-уроки, объясняющие, как это сделать.

Надеюсь, это поможет.

PS. Счастливого Нового Года !!:)

0 голосов
/ 11 декабря 2018
  • Laravel Passport является реализацией OAuth-сервера The PHP League
  • Тип предоставления пароля можно использовать для аутентификации по имени пользователя + паролю
  • Не забудьте скрыть свои учетные данные клиента, сделавзапрос авторизации в прокси
  • Сохраните токен обновления в файле cookie HttpOnly, чтобы минимизировать риск XSS-атак

Более подробную информацию вы можете увидеть здесь

http://esbenp.github.io/2017/03/19/modern-rest-api-laravel-part-4/

...