Our team wants a central gateway service (GW) that does authnz + request forwarding for all our frontend clients trying to reach our backend services. For example, if client A wants to reach Service X, A will call GW and GW will do some company-specific authnz before forwarding the request to Service X.
The issue is, there can be many different Clients each requiring slightly different authnz checks. For example, Client A may require authnz to include a PASETO validity check + a call to another Service to validate another token, versus Client B which might need no PASETO check but a call to a different Service with a special request header value. etc. etc.
We are kind of stumped on how best to implement this GW service, such that it can gracefully cater to all these different clients with different auth schemes, whilst also being loosely coupled to the clients. We've come up with 2 different possibilities which I will outline below:
Approach 1: Set auth-scheme model
- AuthScheme 1: call Service T for terms of use check, call Service L to get a product license check, call Service EFG for a login check. If all passes, forward to intended backend service.
- AuthScheme 2: validate PASETO included in request, call Service EFG for login check. If passes, forward request.
- AuthScheme 3: validate PASETO included in request, call Service XYZ for login check. If passes, forward request.
In this approach, if a new client needs an AuthScheme thats a different mix-and-match of the separate puzzle pieces, then this GW service needs to be updated with that new scheme.
Approach 2: Subscribe-to-Service model
GW will offer any amount of middlewares that a client can ask for before forwarding the request. This lets the clients mix-and-match the offered authnz checks to build their own unique authnz schemes on the go.
Services/Middlewares offered:
- Terms of Use check
- Product License check
- PASETO signature check
- Login token check against Service EFG
- Login token check against Service XYZ
But in this approach, the client needs to somehow include all this info for what authnz checks to include, with each request it wants forwarded.
What we would like from you is some advice on if we've missed any better/obvious solutions, or if there's any benchmarks or precedence for either/or approach mentioned here. (FWIW, the GW service is planned to be implemented in GoLang)