How to get a Bearer token?

Question

API

Hello.
The application uses Passport. When authorizing authorization from the frontend, a POST localhost/oauth/token is sent to the backend with the following data:

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

And this answer comes:

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

The frontend remembers the token in the Bearer cookie and sends it in other requests for data.

Now you need to implement the functionality to enter the super admin under different clients. There is no client password and therefore /oauth/token will not work.

I get the id from the oauth_access_tokens table through the User model:
$token = $user->token()->id;

As I understand it, this is the access_token that I get using the HasApiToken trait.
But this token (80 characters) is very different from the Bearer token (999 characters) and requests for data do not work through it.
Maybe I do not quite understand how oauth 2 works, but please tell me how to get a Bearer token knowing the access token?

Thanks in advance!

Answer 1

Understood.
Created personal access token

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

And I get access_token in this way

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

Answer 2

I'm not familiar with the Passport implementation, but the general OAuth2 principles are the same everywhere .
You are authenticated (that is, the system recognizes you in person (in the login-password): oh, yes, this is NNovosad !!). In response, they send you an access_token - here's a thing for you to "action". You must declare your intention with this token. That is, the second phase begins - authorization. This usually means that you go to some endpoint, which, after checking the validity of the access_token, can confirm whether you can perform such an action X or not.
A cursory examination of the docks suggests that you need to implement a provider that will issue you a Bearer token according to the scope (scope) or not.
An example from life: a man enters the entrance of a factory. His passport and lists are verified and a pass is issued - this is authentication. And now this man is on the "territory of the plant" and wants to write out accountants for slow work. Can he do this or not? Now, if his authorization (scope - "accounting management") is not lower than the head of the board of the plant, then of course he can. In life, authorization occurs by visual signs, and in the digital world - like this, through tokens that allow the action to "smash to smithereens"!
In Google products, for example, you do not need to create your own providers, but you can set roles for the specified accounts, if such an account requests an action (for example, DownloadGoogleDoc()), then in accordance with the role settings, Bearer will be issued or not) . Scope is specified as url- for google-doc-api.
I hope the workings of OAuth2 have become clearer for you.