sso-wall-of-shame VS oauth2-proxy

Hi! Tailscalar here. This is very topical for me! Over the past 3 weeks I've been working with internal stakeholders to remove our SSO tax - the sso tax is a pet hate of mine. A couple of weeks ago we removed it from our pricing plan after my proposal was approved, and today I released a blog on our website to announce it more widely: https://tailscale.com/blog/sso-tax-cut

I knew of https://sso.tax (which we are not listed on but I did include in my blog), but didn't know there was another website too!

I'm not the person you've asked, but I'm somebody who has been purchasing SaaS/software for businesses large and small for years. My take:

1. If SSO and other basic modern security features are locked into "Enterprise" pricing tiers then the service is at the bottom of the list (see: https://sso.tax). I'd love to say instant disqualification but too many SaaS companies have it in their head that only wealthy enterprises use SSO, despite SSO platforms being widely available and some quite cheap to acquire and start using.

2. If I need to request a quote to start any kind of service to see what the product is about then I'm not likely to pursue it. Don't make me jump through hoops when I'm just trying to see if a product can fit my needs.

3. If license terms are too complex or easy to violate that's a hard pass. Infrastructure monitoring tools are a great example. The licensing is often per "device" or per monitored metric, and some vendors are very loose with their definition of "device". (Don't use LogicMonitor with k8s unless you like throwing money in the garbage can). Hard lessons learned.

4. If the only details I can find regarding how you secure your product are claims of SOC2 and ISO27001 certification then that's a very likely pass. Those controls are great to have, necessary even, but anyone who has had to work to meet those compliance objectives knows that they're much more about organization controls than they are product security. Give me an idea about how you protect data and whatnot on a security page somewhere, not an attestation that dev and prod are separate and you have logs.

On the side of the positives, outside of not hitting the negative marks, I value ease to work with, responsive and competent support, strong pre and post-sales solutions architecture and support/training (if the product is complex enough to warrant that), and supports SSO. I bring up SSO again because it's a hard requirement for SaaS purchases everywhere I go -- no SSO, no go. Social login is not a substitute and is highly undesired.

Hope this helps.

Don’t be shy, here’s the link: https://github.com/robchahin/sso-wall-of-shame/issues.

It sounds like you're unaware of why SSO is considered a security feature at all them, but it's covered right on the site: https://sso.tax/

It's to allow centralized access management. Stuff like firing someone and revoking their access from one platform instantly, instead running around and changing permissions in every tool manually. Or ensuring people in department A can't be invited to some platform for people in department B in order to limit information access.

SSO tax is predicated on the idea that the moment you outgrow the informal arrangements and liberal access, you're really a business. Seems pretty fair?

Last time I had to implement Okta integration for DocuSign at my employer it was absurdly expensive. If Google does this right then I’d be ever so happy.

DocuSign on the SSO Tax site: https://sso.tax/

There’s a strong, widespread objection to hiding security features behind a paywall: https://sso.tax/

If 2fa is the only way you can differentiate in order to force enterprises to pay, it’s better to have a fee for security than to die because you can’t make money… but broadly, as a security company, you should aim for maximum security for every user.

I totally understand. I'm aware of the SSO tax. It's just honestly a complex feature, with a significant maintenance and support burden, and I leaned making it EE so that it'd be worth all the effort to implement and maintain (i.e. I want it to be a new-positive feature for revenue). But if I could get help from other contributors, I'd be fine with SSO being a CE feature too.

Need to put them up for the SSO Wall of shame. https://sso.tax/

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

Meet https://oauth2-proxy.github.io/oauth2-proxy/ It could be deployed in the cluster somewhere and reuse it where needed. We do this to authenticate prometheus,alertmanager ui for useres

At work, I've used oauth2-proxy as a sidecar container (on Kubernetes) for an app that has no authentication mechanism. Pretty straightforward, works well. I think this or Authelia is your best bet.

BTW also keycloak and other similar products offer the oauth-proxy capability, I even used the original oauth2-proxy https://github.com/oauth2-proxy/oauth2-proxy for a while, but it was getting too difficult to maintain for me. I used for a while https://github.com/thomseddon/traefik-forward-auth that was a smart hack configuring a single upstream provider, but it look abandoned. So I was considering authentik but apparently it's just oauth2-proxy embedded in it, at that point why not use oauth2-proxy directly.

Like auth basic? Mate, its 2023 get that RestAPI endpoint behind an OAuth proxy. github.com/oauth2-proxy/oauth2-proxy is a good one on a budget or use some cloud provider's ApiGateway and IAM services.

I use it in combination with oauth2-proxy, which sits in front of my network and the various services I host. https://github.com/oauth2-proxy/oauth2-proxy