Как получить Bearer токен?

Question

[NNovosad]

Здравствуйте.
В приложении используется Passport. При авторизации авторизации с фронтенда на бэкенд отправляется POST localhost/oauth/token с данными:

client_id: 1
client_secret: "here_client_secret"
grant_type: "password"
password: "here_password"
username: "here_username"

И приходит такой ответ:

access_token: "eyJ..." // тут длинная строка
expires_in: 99999999
refresh_token: "here_refresh_toke"
token_type: "Bearer"

Фронтенд запоминает в куку Bearer токен и отправляет его в остальных запросах за данными.

Сейчас же нужно реализовать функционал чтобы войти супер админом можно было под разными клиентами. Пароля клиентов нет и поэтому использовать /oauth/token не получится.

Я через модель User получаю id из таблицы oauth_access_tokens:
$token = $user->token()->id;

Как я понимаю это access_token, который я получаю используя трейт HasApiToken.
Но этот токен(80 кол-во символов) сильно отличается от Bearer токена (999 кол-во символов) и через него запросы за данными не работают.
Может быть я не совсем корректно понимаю как работает oauth 2 но подскажите пожалуйста как зная access token получить Bearer token?

Заранее спасибо!

Answer 1

[NNovosad]

Разобрался.
Создал personal access token

docker-compose exec php-fpm php artisan passport:client --personal

И получаю access_token таким образом

$accessToken = $user->createToken(config()->get('here_personal_access_token')->accessToken;

Answer 2

[Codebaker]

Я не знаком с реализацией Passport, но общие OAuth2 принципы везде одинаковы.
Вы аутентифицируетесь (то есть система вас узнаёт в лицо (в логин-пароль): о, да это же NNovosad !!). В ответ вам присылают access_token - на вот тебе штуку для "действия". Вы этим токеном должны заявить о намерении. То есть начинается вторая фаза - авторизации. Обычно это означает, что вы идёте на некий эндпойнт, который уже сверившись с валидностью access_token-а может подтвердить, можно вам такое действие Х выполнять или нет.

Беглый осмотр доков подсказывает, что вам необходимо реализовать провайдера, который по скоупу (scope) будет выдавать вам Bearer-токен или нет.

Пример из жизни: заходит человек на проходную завода. Его по паспорту и спискам сверяют и выдают пропуск - это аутентификация. А теперь этот человек на "территории завода" и хочет люлей бухгалтерии выписать за медленную работу. Можно ему так делать или нет? Вот если у него авторизация (scope - "управление бухгалтерией") не ниже руководителя правления завода - то конечно же может. В жизни авторизация происходит по визуальным признакам, а в цифровом мире - вот так, через токены, разрешающие действие "разнести в пух и прах"!

В гугл-продуктах, например, не требуется создавать своих провайдеров, а можно для указанных учетных записей задать роли, если такая учетка будет запрашивать действие (ну например, СкачатьГуглДок()), то в соответствии с настройками ролей, Bearer будет выдан или нет). Scope при этом указывается в виде url- для гугл-док-апи.

Надеюсь, работа OAuth2 стала яснее для Вас.