[GH-ISSUE #5241] OIDC-based access lists #3147

New issue

Open

opened 2026-02-26 07:37:57 +03:00 by kerem · 0 comments

kerem commented

2026-02-26 07:37:57 +03:00

Owner

Originally created by @Talismanian on GitHub (Jan 28, 2026).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/5241

Problem:

Not all sites have built in authentication, but NPM can help in this regard through access lists.

Currently, proxy hosts filtered by access lists require specific username and passwords to be added in the NPM interface. Authentication is via basic HTTP. This means that any changes for access must be done via NPM as an admin and reinforces the weaknesses of using passwords as an authentication method for hosts that require restricted access.

Solution:

When altering the access list, you are presented with an option to add a standard basic HTTP password or an OIDC connection. The connection receives the client ID and secret provided by the OIDC provider and other relevant details.

When a user visits the relevant site, they are presented with the OIDC login. If the application is configured in the OIDC manager to allow this user, then they are let in.

Alternatives

Ideally, built in authentication is preferable but this could be a solid and robust Plan B, especially for sites with insufficiently strong authentication built in.

Originally created by @Talismanian on GitHub (Jan 28, 2026). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/5241  **Problem:** Not all sites have built in authentication, but NPM can help in this regard through access lists. Currently, proxy hosts filtered by access lists require specific username and passwords to be added in the NPM interface. Authentication is via basic HTTP. This means that any changes for access must be done via NPM as an admin and reinforces the weaknesses of using passwords as an authentication method for hosts that require restricted access. **Solution:** When altering the access list, you are presented with an option to add a standard basic HTTP password or an OIDC connection. The connection receives the client ID and secret provided by the OIDC provider and other relevant details. When a user visits the relevant site, they are presented with the OIDC login. If the application is configured in the OIDC manager to allow this user, then they are let in. **Alternatives**  Ideally, built in authentication is preferable but this could be a solid and robust Plan B, especially for sites with insufficiently strong authentication built in.