ProxyAuth × BeyondCorp: building an access layer for applications

A few days ago, someone commented on my project:

“You should look into Google's new thing. It's what comes after BeyondCorp. You'll find it directly relevant.”

They were referring to Beyond Zero, Google's new security model for the AI era.

After reading about it, I found the comparison with my project pretty interesting.

Not because ProxyAuth is trying to reproduce Google's architecture, but because we're looking at a similar fundamental question:

How should access to applications and resources actually be controlled?

What is ProxyAuth?

ProxyAuth is an open-source authentication reverse proxy .

The idea is simple: put it in front of your applications and let it become the access control point.

It can handle authentication, sessions, 2FA, roles, groups and access rules before a request reaches the application.

This means that an application doesn't necessarily need to implement its own complete authentication system.

For example, you can put ProxyAuth in front of:

• Grafana
• Internal dashboards
• Administration panels
• APIs
• Web applications
• Internal tools
• Services that don't have authentication themselves

ProxyAuth can protect all of them while keeping their access policies separate.

One instance, multiple applications

One of the things I particularly wanted to solve is managing multiple services without creating a separate authentication layer for every application.

ProxyAuth supports multiple virtual hosts, with independent configuration and authorization rules.

So:

• grafana.example.com
• admin.example.com

don't have to behave the same way.

Different users can have different roles and groups, and access can be restricted depending on the application or route.

The goal is to keep the access layer centralized without making all applications behave like one big system.

Authentication isn't the whole story

For me, the interesting part starts after the login.

Knowing that someone is authenticated doesn't automatically mean they should be allowed to access everything.

ProxyAuth therefore separates authentication from authorization .

A user can be authenticated but still be denied access to a particular resource.

There are also additional protections such as:

• Rate limiting
• CSRF protection
• Token revocation
• IP restrictions
• mTLS
• Anti-replay protection
• 2FA

ProxyAuth can also send its logs to systems such as Grafana Loki, which makes the access layer observable rather than turning it into a black box.

Why the BeyondCorp comparison caught my attention

BeyondCorp helped popularize a very important shift in enterprise security:

Access should not simply depend on whether someone is "inside" the network.

Google's new Beyond Zero goes further, focusing on contextual, risk-based and resource/action-level authorization, including the new challenges created by AI agents.

That's where I see an interesting overlap with the direction of ProxyAuth.

The question is moving from:

“Is this user authenticated?”

towards:

“Should this request be allowed?”

And eventually:

“Should this specific action on this specific resource be allowed right now?”

That's a much bigger problem than authentication alone.

I'm not trying to replace Authelia, Authentik or other projects

There are already excellent solutions in this space.

ProxyAuth isn't about declaring that another project is bad or obsolete.

I built it because I wanted a different approach:

A reverse proxy where authentication, authorization and access control are part of the same layer protecting the applications behind it.

It's also an open-source project, so I'm interested in comparing the ideas rather than creating another “X vs Y” argument.

Where I want to take it

The part I'm most interested in now is what happens when the thing requesting access isn't necessarily a human anymore.

APIs, services, automation and AI agents introduce a different problem.

An authenticated identity isn't necessarily a trustworthy action.

If an agent has access to a service, what exactly is it allowed to do?

• Should that permission be permanent?
• Should the context of the request matter?
• Should a high-risk action require another verification step?

These are questions I'm starting to explore with ProxyAuth.

I don't have the answer to all of them.

That's actually one of the reasons I'm posting this.