Service keys for read-only API routes

[nabeelio]

Instead of having to use a pilot's personal API token, provide the ability for the admin to generate service keys, which can then be checked by middleware on the read-only API routes

[MrJohn6774]

Any plan to adopt laravel sanctum ? With that package, you won't even need to deal with X-API-KEY anymore. For the frontend, axios can automatically handle the session cookie and CSRF token as long as axios in request.js is properly configured.

If an external app, i.e. ACARS software, wants to access the api, sanctum can automatically generate personal access token and the external app will be authenticated as a long as the requests have a valid Bearer token in the header.

And finally you can setup the permissions for API route like this

[nabeelio]

Yes, it's a possibility, if I can migrate existing keys easily. I have to look into it in some more detail

[arthurpar06]

I tried sanctum to see how it works.
It looks pretty cool, it allows you to generate tokens that are attached to a model so you can create tokens for a user but also for an airline for example. Then we can give each token abilities which then allows us to make different tokens for different endpoints, exactly what we want to do. It uses a more standardized stuff (Authorization header with bearer) rather than our own X-API-KEY header.
I think it fits our needs quite well.

The only problem is to migrate the existing keys and for that I don't have any good solutions. Sanctum keys are hashed and stored in a separate table which makes them fairly interchangeable with our existing keys. If this is what we adopt I fear it will be a breaking change. The token that is passed in the header is only accessible when you generate it, after that we can't do anything except delete the token and make another one.
So this would mean that everyone would have to regenerate a token and put it in their acars. Also I'm afraid that an earlier version of acars won't work with a phpvms version that uses sanctum and vice versa

[BossOfGames]

I tried sanctum to see how it works. It looks pretty cool, it allows you to generate tokens that are attached to a model so you can create tokens for a user but also for an airline for example. Then we can give each token abilities which then allows us to make different tokens for different endpoints, exactly what we want to do. It uses a more standardized stuff (Authorization header with bearer) rather than our own X-API-KEY header. I think it fits our needs quite well.

The only problem is to migrate the existing keys and for that I don't have any good solutions. Sanctum keys are hashed and stored in a separate table which makes them fairly interchangeable with our existing keys. If this is what we adopt I fear it will be a breaking change. The token that is passed in the header is only accessible when you generate it, after that we can't do anything except delete the token and make another one. So this would mean that everyone would have to regenerate a token and put it in their acars. Also I'm afraid that an earlier version of acars won't work with a phpvms version that uses sanctum and vice versa

Has there been consideration for Passport instead of Sanctum? The key different would be OAuth.

That being said, it may be used by a handful of orgs. Not too many people will roll a setup that requires phpVMS to be the center of multiple authenticated applications.

[arthurpar06]

The issue with OAuth is that it's heavier and more complex than the current system/sanctum. From my point of view, it introduces a lot more complexity without necessarily providing more useful features. Additionally, we face the same problem as with Sanctum, where we are unable to migrate our current system to Passport/Sanctum without having to change all the keys for everyone (which is a bit inconvenient).