Передовые практики Laravel Passport для выдачи нескольких токенов - PullRequest
2 голосов
/ 20 марта 2019

У меня есть вопрос о Laravel Passport и о наилучшем способе управления api access_tokens.

В настоящее время мы имеем:

  • Токен, выданный grant_type: password и без области действия:
      $data = [
           'grant_type' => 'password',
           'client_id' => $client_id,
           'client_secret' => $client_secret,
           'username' => $user->email,
           'password' => $user->password,
           'scope' => '',
       ];
    
  • Токен только для просмотра изображения пользователя , создав его так:
    $token = $user->createToken('User Picture token', ['view-picture'])->accessToken;
    

Первый токен, выданный grant_type: password, будет использоваться только для получения личной информации пользователя.

Это хорошая практика?

Мы хотим ограничить доступ к ресурсу следующим образом: Ресурс «сообщения», который содержит действия CRUD для своего токена доступа с определенной областью действия.

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

Для чего предназначен личный токен доступа?

Это правильный путь?

РЕДАКТИРОВАТЬ 1:

Для управления правами пользователей мы используем Gates & Policies от Laravel.

1 Ответ

0 голосов
/ 28 марта 2019

Laravel Passport дает вам возможность реализовать полноценный сервер Oauth2 за считанные минуты. Это означает, что вы можете смонтировать полный сервер не только для управления доступом к вашим собственным приложениям, но и для сторонних приложений.

Когда я сказал "ваши собственные приложения" Я имею в виду те, которые были разработаны вами и / или вашей командой. Под «сторонними приложениями» я подразумеваю те, которые разработаны другими разработчиками, имеющими доступ к вашему API. Области применения токенов - это хороший способ ограничить действия, которые могут выполнять эти сторонние приложения от имени ваших пользователей.

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

Из Паспортной документации :

Область действия токенов

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

Теперь, если ваш API будет использоваться только вашими приложениями, я имею в виду, если вы не собираетесь раскрывать или публиковать свой план API кому-либо, кроме своей команды, вы можете просто авторизовать пользователей с ролями и разрешениями и / или реализовать Laravel Gates / Политики.

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

...