Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

NielsNumbers's avatar

Whats the best way to make an api for client applications?

I want to create an API for 3-5 other applications. These applications are not SPAs, they are fully independed systems, like a shop that have to use my API.

If I get it right, then I think that https://laravel.com/docs/8.x/sanctum is not an option here.

I could use https://laravel.com/docs/8.x/passport because it comes with a client table, client hash etc, to allow other applications to communicate with my API, however I would not need the entire OAuth2 features.

Thus, I am thinking of writing my own clients table and authentication...

Is there any better choice? Maybe a package that just has the client authentication without OAuth2?

0 likes
6 replies
martinbean's avatar

@elenktik Use OAuth (and Passport). It’s literally what it was made for.

You have external clients that need to access protected resources on your API server. So your API server should issue access tokens to authorised users to be able to make API requests.

1 like
NielsNumbers's avatar

@martinbean yes they are external clients, but they have no users that want to access resources. Infact, there are no users at all on the other clients. They are just applications that send stuff to my main application, so OAuth is actually not needed and thats why I am thinking the passport package is maybe too much overhead.

jlrdw's avatar

They are just applications that send stuff to my main application

Sounds like you are retrieving from an API. So then you would follow their api spec and instructions.

1 like
NielsNumbers's avatar

@jlrdw no they are more like microservices that I have build myself, talking to each other

jlrdw's avatar

If you want security you can still have a token, see this example, but convert to laravel.

https://www.sitepoint.com/php-authorization-jwt-json-web-tokens/

Just make sure each 2-way communication has a "given" key or token or pin that is stored in database.

That is to avoid someone "hacking" in. Sort of like a login, but since a human isn't using you still need a token of some sort.

On a request, you compare the sent token with stored token to verify a match.

Please or to participate in this conversation.