I would like to request an enhancement to the current OAuth2 enforcement mechanism. At the moment, enabling OAuth2 protection applies authentication requirements globally to all routes under a given domain. This creates operational issues for systems that rely on automated or internal API communication, since these endpoints cannot complete user‑interactive OAuth2 flows.
Proposed Improvement
Introduce support for path‑level exemptions within the OAuth2 configuration. This would allow administrators to enforce OAuth2 authentication for the main application while explicitly excluding specific routes (e.g., /api/*) from OAuth2 validation. Possible implementation approaches include:
- A list of regex‑based or prefix‑based path exclusions
- Per‑route OAuth2 toggles within routing rules
- A rule‑evaluation layer that determines whether OAuth2 should be applied before forwarding the request
Rationale
Modern architectures frequently separate frontend user interfaces (which require OAuth2 authentication) from backend services that communicate programmatically. Without the ability to define exceptions, enabling OAuth2 can unintentionally break internal API calls, service‑to‑service communication, mobile app requests, and webhook integrations.
Adding path‑level OAuth2 exemptions would significantly improve deployment flexibility and align Zoraxy with common reverse‑proxy and identity‑gateway patterns used in production environments.
Another important change is identifying the email that was authenticated and allowing only registered email addresses to have access.
Thank you for your continued work on the project.
I would like to request an enhancement to the current OAuth2 enforcement mechanism. At the moment, enabling OAuth2 protection applies authentication requirements globally to all routes under a given domain. This creates operational issues for systems that rely on automated or internal API communication, since these endpoints cannot complete user‑interactive OAuth2 flows.
Proposed Improvement
Introduce support for path‑level exemptions within the OAuth2 configuration. This would allow administrators to enforce OAuth2 authentication for the main application while explicitly excluding specific routes (e.g., /api/*) from OAuth2 validation. Possible implementation approaches include:
Rationale
Modern architectures frequently separate frontend user interfaces (which require OAuth2 authentication) from backend services that communicate programmatically. Without the ability to define exceptions, enabling OAuth2 can unintentionally break internal API calls, service‑to‑service communication, mobile app requests, and webhook integrations.
Adding path‑level OAuth2 exemptions would significantly improve deployment flexibility and align Zoraxy with common reverse‑proxy and identity‑gateway patterns used in production environments.
Another important change is identifying the email that was authenticated and allowing only registered email addresses to have access.
Thank you for your continued work on the project.