Мне потребуется слишком много времени, чтобы подробно ответить на каждый из ваших вопросов, поэтому я попытался дать ссылку на соответствующие разделы в RF C для дальнейшего чтения.
По сути, я рекомендую вам использовать поток предоставления прав доступа к паролю для ваших сторонних клиентов (вашего мобильного приложения и веб-приложения). Одним из клиентов, который Laravel создал бы для вас, был бы "Laravel Клиент, предоставляющий пароль", и его документация доступна здесь .
Вам все равно потребуется Определите свой собственный маршрут регистрации, но вы можете использовать маршрут oauth/token вместо своего собственного /login маршрута.
- Что такое Сервер Oauth ? Это мой собственный сервер, на котором установлен API ?
Сервер OAuth будет вашим сервером, на котором работает Passport. Или в официальной терминологии в соответствии с RF C, сервер OAuth / сервер паспортов будет называться «сервером авторизации».
В вашем случае, «сервер ресурсов», который ваш API, обслуживающий ваш контент, будет тем же сервером, что и «сервер авторизации».
После Laravel Паспорт Конфигурация и миграция базы данных, Laravel Паспорт создал несколько таблиц в моей базе данных, я был бы очень признателен, если бы вы сказали мне, какова цель каждой таблицы? Имена таблиц: failed_jobs , oauth_access_tokens , oauth_auth_codes , oauth_clients , oauth_personal_access_clients , to_sauth .
Таблица failed_jobs не имеет прямого отношения к паспорту. Это связано с очередями Laravel. См. Работа с ошибочными заданиями .
Все остальные таблицы находятся там, чтобы Passport мог отслеживать клиентов и коды, которые он создал.
-
oauth_clients: см. Раздел RF C клиентов . oauth_access_tokens: см. Раздел RF C маркеров доступа . oauth_auth_codes: См. Предоставление кода авторизации . oauth_personal_access_clients: Клиенты персонального доступа, похоже, не являются частью официальной спецификации, но в основном это клиенты, когда пользователь хочет получить токен доступа напрямую, а не через приложение или веб-сайт. Обычно это разработчик, который хочет получить токен доступа, чтобы иметь возможность вызывать конечные точки API от своего собственного аккаунта. В таблице персонального доступа хранятся клиенты, специально созданные для этой цели. Обычно это только один из них. oauth_refresh_tokens: см. Раздел RF C refre sh tokens .
Правильно ли создавать личный токен доступа для моих двух типов пользователей? Что такое персональный токен доступа?
Каждый пользователь должен получить собственный токен доступа, но не личный токен доступа.
Персональные токены доступа - это просто доступ токены, которые были созданы специально для пользователей, которые хотят сами генерировать и использовать токен доступа. В частности, в Laravel Passport они являются токенами доступа, которые связаны с «Laravel Personal Access Client».
Таким образом, в вашем случае ваш сервер будет создавать «обычные» токены доступа для пользователей, а не «персональные» токены доступа.
Правильно ли я создаю личный токен доступа , когда учителя и ученики входят в свою учетную запись, или я должен найти другой способ справиться с этим ?! этот способ работает, но я ищу правильный путь, если есть что-то еще.
См. ответ на вопрос 3.
Странная вещь здесь Laravel Паспорт создавать токен каждый раз, когда пользователи входят в систему, и он не проверяет, создали ли они токен или нет? Если кто-то может получить доступ к конечной точке API, он может отправить запрос на конечную точку / login и создать много токенов. Это проблема? Как это исправить?
Не думаю, что это проблема. Маршрут oauth/token ограничен по скорости. Вы можете ограничить его еще больше.
Вы также можете прослушивать события и удалять или отзывать токены, если хотите ограничить количество токенов для одного пользователя.
Когда я создаю личный токен доступа , мне нужно передать аргумент методу createToken($arg), и он сохраняется в таблице oauth_personal_access_clients . какова цель этого? Это только для Laravel Паспорта цели, или, может быть, мне это понадобится в будущем?
Эта таблица только для Laravel Паспорта. Это также может быть полезно, когда вы захотите провести аудит или отладку чего-либо позже.
Строка, которую вы видите в таблице oauth_personal_access_clients, была создана при запуске php artisan passport:install.
Когда вы звоните createToken, новая строка вставляется в oauth_access_tokens.
У меня есть некоторые конечные точки, которые не защищены auth:api middleware , например, каждый пользователь, посещающий мое приложение, может искать имена учителей и уроки и ..., их не нужно делать Войдите или зарегистрируйтесь в первую очередь. Эти конечные точки доступны для всех в моем приложении, и они свободны для поиска и расширенного поиска некоторой информации. У меня вопрос: если я сделаю его доступным для всех, как я могу защитить эти конечные точки, которые только мое стороннее приложение и стороннее приложение может получить к ним доступ. Я имею в виду, что я не хочу, чтобы люди получали к ним доступ с помощью командной строки или почтальона или какого-либо из этих инструментов без маркера доступа, я хочу защитить эти конечные точки от злоумышленников, чтобы огромные запросы, чтобы отключить мой сервер. Как я могу защитить такие конечные точки? Я знаю, что могу ограничивать запросы в минуту, но я не знаю насколько ограничивает это? Есть ли другой способ?
Да, вам придется ограничить скорость. Вам придется поэкспериментировать и посмотреть, что работает для вас.
Я вижу, что есть термин, называемый клиенты в терминология Oauth , как я понимаю клиенты - это такие приложения, как веб-приложения или родное мобильное приложение и любые другие приложения, использующие мой API, называются клиентами . Я прав? И я думаю, что это для стороннего приложения аутентификация . Я немного запутался после прочтения Laravel Passport документации о клиентах , и когда я настроил Laravel Passport , он генерирует два клиента и сохранили их в базе данных. Нужно ли создавать клиента для моих приложений ?! Как я могу игнорировать поток авторизации просто для сторонних приложений?
Да, клиенты похожи на веб-приложения, мобильные приложения и т. Д. c. Обычно у вас будет новый клиент для каждого мобильного приложения, веб-приложения, CLI и т. Д. c., Но в дополнение к этим приложениям Laravel определяет клиентов «Клиент предоставления пароля» и «Клиент персонального доступа». которые имеют определенные c цели.
Вы можете использовать Laravel Клиент предоставления пароля для обоих ваших приложений, поскольку они являются приложениями сторонних производителей.
Вы можете игнорировать поток авторизации для сторонних приложений, используя маршрут /oauth/token, который предоставляется для клиентов с предоставлением пароля.
Раздел RF C о потоке учетных данных пароля доступно здесь .
Вы можете узнать больше о том, как RF C определяет клиентов здесь .
Какая польза от этих маршрутов ? они мне нужны для создания моих собственных приложений ?
Необходим для сторонних приложений: - /oauth/token
Не требуется для сторонних приложений:
/oauth/clients: сторонний разработчик должен видеть, каких клиентов он создал. /oauth/clients/{client-id}: для стороннего разработчика обновить одного из своих клиентов. /oauth/authorize: этот маршрут будет вызван сторонним разработчиком для запуска поток разрешения авторизации с их идентификатором клиента и секретом.
Подробнее о вышеупомянутых маршрутах можно прочитать в разделе "JSON API" в Управление клиентами .
Как я уже говорил, будущая цель этого приложения - сделать API доступным для сторонних приложений , мне нужно создать веб-страницу, на которой разработчики регистрируют учетную запись и получают / купить токен для доступа к моему API. Можно ли это сделать с помощью Laravel Паспорт или я должен написать свой собственный лог c, чтобы он работал? Нужно ли создавать клиент для моих сторонних клиентов?
Laravel Паспорт предоставляет Vue компонентов, которые вы можете использовать, чтобы разработчики могли умеет создавать клиентов. Вы можете использовать эти компоненты или создать свой собственный веб-интерфейс и вызывать JSON API-маршруты со своего собственного интерфейса.
Имейте в виду, что OAuth был изначально разработан для третьих сторон. сторонним приложениям необходим доступ к вещам от имени пользователя . Таким образом, вместо получения токенов доступа сторонние приложения получат идентификатор клиента и секрет клиента, и им потребуется go через один из потоков разрешений для каждого пользователя, которого они хотят действовать от имени из.
Если у вас никогда не будет сторонних приложений, которые должны действовать от имени пользователей, возможно, стоит рассмотреть другие протоколы, такие как упомянутые в комментариях.