Laravel app with Lumen API (Authentication)

First, I'd like to +1 this, as I'm currently in the early stages of planning a new project where domain.com would host the main website (including a shop and backend) while api.domain.com will provide several services that don't have to be tied into the main site but probably will use the same database.

So I will probably have two projects (one with Lumen and one with Laravel). My question would be what would be the best approach to tie both projects together. For example I would want both projects to have the same Eloquent Model classes. Is there a best-practices article on how to outsource a Laravel API to a seperate Lumen project?

Regarding your question: I think what you are trying to achieve won't play out well with Lumens approach. Actually, Taylor talked about this in the latest Laravel Podcast. Maybe take that one for a spin?

I want to contribute to this discussion but I am unsure if it will fit.

Currently my API service is being migrated to Lumen/Laravel from Silex.

Inside the "old" app - we have MySQL orm + Redis + Cassandra as our makeup in our datastorage. All outside apps communicate with the API and receive an auth token that is put in Redis as a common share between underlaying API so that it knows that the user has been authenticated. There is a TTL to ensure re-negociation.

The reason we designed it this way is that the API is independent from the Client APP (web, mobile, etc) and all it negociate with is the API output as interface contract. This enables scaling as you can just make the data store your common ground to your app and scale from there.

Unfortunately - I have not been able to migrate to PHP 7 as of yet because datastax php-drivers has an issue in compiling on travis for me to run my test unit. Until they upgrade im stuck in 5.6.16. However while benchmarking from Silex to Lumen I have gained approx 10-12% in speed without code refactor. While using windgrind / cachegrind I was able to determine less function call over all when switching to Lumen.

As far as your question go - if you go to common redis storage for your auth tokens you can just send a command to set the TTL to -1 (or expired) which will effectively destroy the token (or let it expire) and have your app re-negociate. So far - so good in my end. Im not 100% sure if its the best optimal approach but so far IMO its working well.

+1

WEB APP (server 1) ______________ <<<< HTTP REQUEST >>>_______ LUMEN REST API (server2)

Oauth2 ? http://esbenp.github.io/2015/05/26/lumen-web-api-oauth-2-authentication/

@nathandunn Cookies can be shared amongst subdomains, but I think the approach you’re talking about won’t work with Lumen 5.2 (at least out of the box) and I believe any state handling, such as sessions, is going to be removed from Lumen, as it was intended to be used for stateless applications like RESTful APIs. You’re therefore going to have to come up with an alternative authentication mechanism.

If you’re wanting to go the API-driven route with your application, JSON Web Tokens (JWT) seems to be a popular choice these days. However, I’ve not used them in an app myself yet so can’t really offer any specific advice about implementation I’m afraid!