It's by far the easiest auth system to implement first if you write something custom.

I don't think it is.

I'm just saying that if you can build your app assuming it's behind an authenticating reverse-proxy, it frees you from a LOT of work designing a system to authenticate the user with credentials or whatever. It's just username = request.Headers["X-Forwarded-User"], done. No validation, no encryption, no hmac, no password hashing function, no password storage, no password resets, etc etc etc

• open source Kanban project management software Kanboard
  • REMOTE_USER
• Jenkins
  • X-Forwarded-User
• Docker suggesting using it to secure access to a registry (Not sure how applicable this one is.)
• Microsoft recently published some docs on how to configure Azure AD to do proxy auth, as well as another article
• Authelia (?)
• Some Oracle enterprise apps
• Some stack overflow questions in this area:
  • https://stackoverflow.com/questions/33368653/how-do-i-set-remote-user-in-a-http-header
  • https://serverfault.com/questions/180726/remote-user-through-apache-reverse-proxy

Perhaps this solution is more common in enterprise apps. Probably for the security reasons I mentioned before.

There's also RFC 7615 / Proxy-Authenticate on MDN which seems related.

Thoughts?

Edit also:

• Galaxy Project (?)
• odoo community (?)
• shibboleth (?)

It's by far the easiest auth system to implement first if you write something custom.

I don't think it is.

Cloudron used to have something very similar (in usage, if not technologically), using OAuth. They decided to drop it, because almost no apps supported it.

What you are describing would be indeed quite interesting, but more or less custom to cloudron : i think this would be even more difficult to convince upstream devs to implement, because it's so custom.

Do you know of any apps that currently support a similar thing ?

• I don't trust the login page and password handling to apps. Even if they auth via ldap -- they're still touching the password. Proxy auth eliminates this problem altogether, since they only receive the attestation of the user's identity (the header), no secrets, no cookies. I trust the proxy's auth login page way more.
• Ideally the app is never even accessible to the outside world until you're logged in. Apps often have vulnerabilities that can expose data even if you're not logged in. By putting the app behind an authenticating proxy, one can shield it from general internet access, narrowing the scope of attackers from "everyone that can access my ip" to "users on my cloudron" -- a large improvement.
• It's by far the easiest auth system to implement first if you write something custom.

Of course, all apps may not support this yet, and sometimes you do want a public-facing service, and some apps could never work like this (bitwarden), etc, hence "optional".

In my case, I would like to hide the public site of an Shaarli-instance behind the proxyAuth login. Such that authenticated users can browse the public page and I can additionally login using the builtin auth as admin.
I know, that this usecase is somewhat specific and customary, but it is just meant as an example of possible use cases for an proxyAuth-option with the standard apps.

Yes, proxyAuth exclusion is implemented. I only implemented a simple approach with a ! pattern for now (not an array).

Edit: I am blind I swear - just formatted the JSON incorrectly for the manifest.

• Session management in the user's profile page. i.e can logout from apps etc

I think @girish just meant that it would be possible to implement this in the future, not that it would be in the first version of proxyAuth.

Some benefits of having this on the platform side (as opposed in the app are):

• 2FA login

{
  "proxyAuth": {
    "path": "/admin" 
  }
}

To take exceptions:

{
  "proxyAuth": {
    "path": "/admin" ,
    "exclude": [
      "/webhook",
      "/
    ]
  }
}

Or with probably over-the-top features, make everything a map of path and exception(s):

{
  "proxyAuth": {
    "paths": {
      "/" : [
        "/webhook",
        "/public"
      ],
      "/admin": []
    }
  }
}

Honestly, I appreciate the minimal-first approach, and I think the middle option of adding a (understood to be auto-wildcarded) array of exclusions is the easier next step. I can't imagine anything that would need the super-complex variant would be something that would or should rely on such a mechanism to secure it.