Laravel Passport and User Session

When it comes to a stateless approach such as Laravel Passport and Tokens the only way that I can think of that can help you solve your problem will be storing the token into an encrypted cookie or local storage, and then manage the token expiration time.

The downside to this is that it opens up security holes and issues. I would recommend reading This Article to get a basic idea about what are the security issues.

Back in the day, I had to make kind of the same application and I ended up using normal auth authentication and then once the user was logged in, the rest of the app was a SPA for the backend with Vuejs and Vue Router.

I am no means an expert but I haven't really figured out another way to tackle token-based authentication without opening some kind of security issue.

Hi @sidirgot, thanks for your reply.

The case is for a multi-tenant application that has to provide an API for both itself and third-parties to connect.

Each tenant inside the system has its own set of users and all sorts of functionalities, the idea is to provide an API driven solution so those tenants can have more freedom to customise their user's experience.

At the same time, we want to consume our own API, so we don't have to maintain multiple interfaces.

A simplistic version of the workflow would be something like:

1. Tenant access the API by issuing a bearer token using its Client ID and Secret (provided by Passport);
2. Tenant is then identified and has access to its own stuff.
3. Then, let's say the tenant needs to authenticate a user (for example, a phone app).

The way I see this happening is like:

1. Tenant calls the API using its bearer token (maybe machine-to-machine);
2. Tenant app asks for user credentials and then calls the API entry point giving it as payload
3. API replies back with a new (short-lived) token that authorizes the user
4. From that point, the tenant's third-party application will have to handle the short-live token storage, since each call will require both the tenant's bearer token (long-lived) and the user's short-lived one.

The approach above will have to be more or less the same when we want to consume our own API.

I don't see much of a way out, waiting for more opinions ;-)

Yeah, I understand then needs that you are having so I would say the best approach will be an encrypted cookie.

The user provides the credentials, the API responds with a short-lived Access Token that you then save into an encrypted cookie witch will be used for every other subsequent request.

I would love to hear other opinions since I am not aware of any other way to achieve this.