Laravel, Passport, and Distributed Services Architecture.

ENVIRONMENT

Mandate to stay within the laravel/vue/php/mysql stack.
Single Page Vue.js/Laravel application. Meaning Vue 100% of the UI, and Laravel 100% api only.
Services Architecture with ~10 major services.
10 auth/profile/service-directory servers w load balancing.
Varied number of servers for the other services, depending upon needs (federated).
100+ content servers, each with =< 100 mysql databases each.
Many, many, terabytes of data.
All tables keyed by integer-converted-and-segment-reversed UUID's.
Redis (because we have been using it with Laravel now for a few years and it's fine for our purposes)
Each service responsible for informing the Auth/Profile servers about certain profile changes (stats etc).

It is a pretty standard scalable architecture in use today, with one significant difference in that we use custom per-object Access Control List (ACL) within each db. So all we need to know on any server providing any service or set of services, is that a request is being made by a user who is authenticated by the Auth/profile servers, and which user is making it.

DUMB QUESTION

Current architecture is db-rpc (meaning, we just use db connections to reach the services provided by each database), but this tunnels a great deal of data thru the site's servers, and requires a monolithic network. We want the simplicity of web services API's) located anywhere in the world, with the user's app able to reach each (or all) of them as needed.

Lots of internal debate about how to handle services authentication, but what gives performance vs risk in this architecture. (assume we know the jwt/oAuth/Passport schemes but that we're arguing over how granular to make the tokens, and how much trust to put in them (such as, do we have to verify each request via the service to an auth server, or is encryption of the token contents for a given client/secret enough?

Thanks in advance

Thanks

One of the values of putting something into writing is that it clarifies your thinking a bit. But the answer is pretty clearly JWT, and Passport does a fair enough job of token management, that if we override it and add a few more fields to the token, we might be able to stick with passport rather than pulling it and just moving fully to JWT.

Otherwise, we'll pull passport and just use a JWT throughout the system, with a short duration token refreshed regularly. We can do this because the keepalive heartbeat service will drive the refresh automatically for us.

So if anyone else has the same thoughts (and they asked and un-answered all over the web) the answer is that Passport provides a midsized solution, but if you must scale to many services, then use JWT plugins and create the token contents that you need.

At least that's where we ended up.

Moderators