Caddy VS oauth2-proxy

It looks nice and friendly, but for developers I can recommend exploring caddy[1] or nginx[2]. It's a useful technology to have worked with, even if they're ultimately only used for proxying analytics.

[1] https://caddyserver.com/

I began to self-host a Minecraft server using Crafty Controller, an Excalidraw instance, Docmost to replace Notion, Plane to replace Jira, and Penpot to replace Figma. To be able to access them from the internet, I used Nginx Proxy Manager to set up reverse proxies with SSL. You can use Traefik or Caddy instead, but I enjoyed the ease-of-use of NPM. For a dashboard solution, I started with Homarr, but later switched to Homepage because I'm apparently incapable of making a decision and sticking with it.

This approach offers a level of customizability similar to what xcaddy does for the Caddy server, eliminating the complexities associated with writing Rhai scripts to customize a precompiled binary, as is the case with the Apollo Router.

Caddy is a server written in Go programming language, known to be easy peasy to configure (Unlike configuring Nginx), and it also includes https by default.

Caddy is the ultimate web server anyone should be using. This is true for production as well as for local development. It is very fast, and by default obtains and renews SSL certificates automatically. This is useful for when you want to test certain website feature that is only allowed when they're accessed with HTTPS. You get free TLS for all your subdomains, and it does that in a scalable way.

Did you happen to look at caddy? It at least used to have some degree of support for plan9: https://github.com/caddyserver/caddy/issues/1093

https://github.com/caddyserver/caddy/issues/5759 :

> When generating a CA cert via caddy and putting that in the trust store, those private keys can also forge certificates for any other domain.

RFC5280 (2008) "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" > Section 4.2.1.10

oauth2-proxy is an open-source reverse proxy and static file server that provides authentication using OAuth 2.0 and OpenID Connect (OIDC) providers. It acts as an intermediary between the client and the backend server, ensuring that only authenticated requests are forwarded. By integrating with various identity providers like Google, GitHub, and many others, oauth2-proxy simplifies the process of adding authentication to web applications. It supports multiple authentication flows, including the Authorization Code Flow with Proof Key for Code Exchange (PKCE), making it suitable for both client-side and server-side applications. Additionally, oauth2-proxy can handle session management, token validation, and user information retrieval, providing a robust and flexible solution for securing web applications.

I believe it's almost always the "groups" claim <https://github.com/oauth2-proxy/oauth2-proxy/issues?q=cookie...> but I would suspect any sufficiently large set of claims would do it (e.g. a huge "iss", erroneously returning the user profile jpeg attribute, who knows)

For authentication, there are several options like oauth2-proxy, Keycloak, OpenUnison, Traefik, Istio’s EnvoyFilter. For this tutorial we will use oauth2-proxy.

Recently I looked into having a relatively simple SSO setup for my homelab. My main objective is that I could easily login with Google or GitHub auth. At my previous job I used both JetBrains Hub [1] and Keycloak but I found both of them a bit of a PITA to setup.

JetBrains Hub was really, really easy to get going. As was my previous experience with them. The only thing that annoyed me was the lack of a latest tag on their Docker registry. Don't get me wrong, pinned versions are great, but for my personal use I mostly just want to update all my Docker containers in one go.

On the other hand I found Keycloak very cumbersome to get going. It was pretty easy in dev mode, but I stumbled to get it going in production. AFAIK it had something to do with the wildcard Let's Encrypt cert that I tried to use. But after a couple of hours, I just gave up.

I finally went with Dex [2]. I had previously put it off because of the lack of documentation, but in the end it was extremely easy to setup. It just required some basic YAML, a SQLite database and a (sub)domain. I combined Dex with the excellent OAuth2 Proxy and a custom Nginx (Proxy Manager) template for an easy two line SSO configuration on all of my internal services.

In addition to this setup, I also added Cloudflare Access and WAF outside of my home to add some security. I only want to add some CrowdSec to get a little more insights.

1. https://www.jetbrains.com/hub/

2. https://dexidp.io/

3. https://github.com/oauth2-proxy/oauth2-proxy

3. https://github.com/alex3305/unraid-docker-templates

Authentication providers like Auth0 and Okta have become commonplace in software development. These providers help take this work off of your plate, and this can be made even easier by using a reverse proxy that provides authentication capabilities, like oauth2-proxy.

There's also other problems you might run into when using JWT: - First using scopes for permissions like Slack does can generate a token so large that a server might refuse it (One of many examples: https://github.com/oauth2-proxy/oauth2-proxy/issues/644, any rational server won't allow unlimited sized header), in my company they did this with the convention of read:team:product:resource but if you're an admin and have every rights by default, then you can't use the generated token by default as it will be too large. I think Quarkus works that way and you might encounter some problems with you don't configure it correctly. - Second is that it will cost a lot of bandwidth to send this header each time you're doing something, and probably won't be the perfect answer for what you want to do (do you really have third parties calling your API ?) - Third is about security concerns, you might say that having your permissions in a token is not as bad as you might think but in case of a Man In The Middle attack, you could leak information about your company, process or business intelligence that could have been prevented. - Fourth and that'll be the last, is that you can't revoke a JWT. And if you say you can, then you don't need a JWT at the first time because it would defeat the principle of a self contained JWT.

That is not how you do Zero Trust. You want to use an Identity Aware Proxy. There are lots of ways you can implement this with Google as your core auth. For example Pomerium or oauth2-proxy.

I use self-hosted Apache Guacamole (RDP) through a reverse proxy with Google SSO (oauth2-proxy[0]). So easy to access my desktop from virtually any browser (mobile isn't the best though). This would be a good solution for gaming, but for other activities RDP is unbeatable imo.

[0] https://github.com/oauth2-proxy/oauth2-proxy