0

I have the following architecture for accessing a REST service that requires authentication:

enter image description here

  • Oidc token flow managed at the client
  • Access token verified at the server in the auth service (proxied by the api gateway), exchanged for a jwt that contains authorisation information about the user.
  • The resource is accessed

In the current model, every request needs to verify the access token (which is normal), but also needs to retrieve the authorization information on every request, which I don't feel is ok.
The jwt used in this model is only for internal use at the server cluster, as there really is no need to send it back tot the client. Also generating a jwt on every request doesn't feel quite right.

Storing the jwt in a server store (cache / database) is something I don't feel is right with this model, because this makes the system stateful again (in case of multiple api gateways, there is need again for sticky sessions, synchronisation etc). Hence this doesn't offer a solution.

One possible solution would be that authorization is not checked upfront along with the authentication (i.e. verification) process, but only depending on the requested route / action. I don't particularly like this, as this requires back and forth messaging when a protected resource is accessed. It doesn't smell like clean architecture.

What is the advised way to go about this?
Related, I wondered if it is enough to perform authentication in the api gateway. These microservices work independently, and I feel a bit uncomfortable that the api gateway grants all access while keeping the underlying services 'dumb'. Is this a misplaced sense of paranoia?

1 Answer 1

0

I do not see the problem in authentication it's more authorization.

Legit solution is to enforce networking rules with iptables so any traffic besides api gateway is not allowed only from api gateway.

One of security rules is to take care of attack vectors which in your case is api gateway. For more security you should check business logic on api gateway if privilege escalation is possible and if so implement authorization inside.

Why is it fine to have auth only on api gateway:

  • If attacker privilege escalates api gateway and grabs some subset of JWT-s there impact is near to same as api gateway having full access to services.
  • If attacker obtains JWT for some resource over api gateway there isn't any mechanism to stop him using the sam JWT on internal services if he gains access you adds a bottleneck to app

If your paranoia is big enough make sure to SSL encrypt traffic between api gateway and other services and iptables should be enough: - On same host: localhost port -> services endpoints - Different hosts: public static ip -> services public static ip/ips.

More info on subject look for threat modelling: https://www.owasp.org/index.php/Application_Threat_Modeling

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .