OpenID Connect with or without reverse proxy?

Question

Many popular reverse proxies (tomcat, nginx, ...) seem to handle OpenID Connect and act as a Relying Party to hide the authentication complexity to all applications behind the reverse proxy, which just receive http headers containing user info.

Is this a good practice, to have just one Relying Party (the reverse proxy) declared in the OP, as opposed to have as many Relying Parties as there are applications ? It seems to me the security can only be weakened by grouping all apps under a single configuration (token timeouts, etc) and declaration from the OP perspective, so I'm puzzled as to why it's implemented in major reverse proxies and why it's sometimes recommended.

Can applications behind the reverse proxy really be agnostic of the authentication protocol ? For example, for tomcat, the official documentation suggests that it's the apps' job to refresh the token, which seems to go against the goals of this whole architecture...

When the application wants to refresh the access_token, it may call the module on the following hook...

Answer 1

I'm not really familiar with the tomcat use case, however in the case of nginx I have never seen it used as a relying party. For django/flask applications it's either the application which is the relying party OR in the case of an API neither are RP.

The main reason is that if you use your reverse proxy server as the RP, it will have a unique client id (or it will be a configuration nightmare) and thus all users will be authenticated for all applications hosted behind the reverse proxy. It isn't uncommon to have multiple, very different applications behind a unique reverse proxy and singular authentication schema and unique client id per application to be able to give access on a per user/per application basis. The same will apply to the claims, as each application might require a different set of claims from the IP.

Another reason is that openid will usually provide the authentication layer without the permission layer. Sometimes you'll have specific claims that could provide the user with a general level of permission, but you won't have a claim for each object if, for example, you need an object level permission schema. So the application will need to know the user to define its permission thus use the id token and validate it with the IP. It doesn't need to implement the whole authentication process but it's so close that it's almost effortless to implement a code flow at this point.

And in the case of an API + front SPA or a mobile application, neither the back application nor the reverse proxy are RP, the front application will do the whole authentication scheme by itself to obtain the token and the API application will simply validate the token with the IP.

Answer 2

Also consider the time complexity of maintaining and supporting, or responding, to an issue in, or locking down one endpoint, vs multiple endpoints.

Also, one secure endpoint is better than multiple insecure ones. The question is whether multiple secure ones is better than one. I would say that that would firstly depend on what monitoring you have in place and what you capacity is to detect a breach, as well as what you have in front of those endpoints, and also how many people you have who can respond to issues, and also how agile you are in responding to issues, and maintaining them.