sso

This problem+solution, like many others in the agentic-space, have nothing agent-specific. Giving a "box" API keys was always considered a risk, and auth-proxying has existed as a solution forever. See tokenizer[0] by the fly.io team, which makes it a stateless service for eg - no database or dashboard. Or the buzzfeed SSO proxy, which lets you do the same via an OAuth2-dance at the frontend, and a upstream config at the backend which injects secrets: https://github.com/buzzfeed/sso/blob/549155a64d6c5f8916ed909.... [0]: https://github.com/superfly/tokenizer

For those of us who are not devs writing applications, I found this section useful: https://openziti.github.io/docs/quickstarts/services/#zero-t... For access to my home network, I use two things: 1. Wireguard 2. An identity aware SSO proxy by Buzzfeed[0] I really like Buzzfeed's SSO implementation, but it hasn't received updates in a while and doesn't seem to be maintained to me. I could absolutely see OpenZiti replacing this for me. I really like Wireguard and have absolutely no complaints with it -- but if OpenZiti could replace this as well and match the performance I get on Wireguard I would consider implementing it at home (and would probably be a happy enough customer to push for it at work). One non-typical use-case I use Wireguard for is being able to do remote game streaming to my Windows hosts via Moonlight+Nvidia Gamestream. W

In addition to this suggestion, another viable route is to self-host those applications you rely on and don't expose them to the world (so as to reduce load/attack surface). Using a VPN can allow you to access the applications privately/remotely. e.g. I self-host the applications I rely on such as Teddit, Nitter, Bibliogram and Cloudtube and then use Wireguard to always remain connected to the network they are accessible on. I have also implemented identity-aware SSO[1] so I can expose those applications remotely to specific individuals. [1] https://github.com/buzzfeed/sso

However, Authelia... is not an OAuth or OpenID Connect provider yet (planned in the roadmap) is not a SAML provider yet. does not support authentication against an OAuth or OpenID Connect provider yet. does not support authentication against a SAML provider yet. does not support using hardware devices as single factor. does not provide a PAM module yet. oauth2_proxy is a great tool that lets you create a transparent OAuth proxy to provide SSO for any internal service. Protect an entire subdomain of services using one identity provider! Guides exist for integrating it with K8s, but luckily it's just a binary so you can protect non-K8s services with it too. It's also super easy to deploy, as you can configure the whole thing with just environment variables, or a config file. The docs are decent too. https://github.

Imagine you have an application like GitHub Enterprise or Phabricator, something that has a web interface and SSH for git access. You might trust SSH, but do you trust the web stack to not have vulnerabilities? I don't know about you, but I don't trust running third party apps, I won't publicly expose them. Instead I put them behind authenticating proxies, like Cloudflare Access[1], Google Identity-Aware Proxy[2], Bitly oauth2_proxy[3], and Buzzfeed SSO[4]. With an authenticating proxy an attacker can't even hit the web application until authenticating, so they can't exploit a vulnerability in the web application. They will have to pop the auth proxy first, which have less surface area, and then pop the web application. Applications that combine HTTP and SSH complicate things because the typical HTTP proxy won't proxy your SSH (git) conne

Maybe - we've not tried it, but I just asked Justin who architected sso, and he suggested that maybe https://github.com/buzzfeed/sso/blob/master/internal/proxy/o... could be used. However there would be some caveats - like for example `skip_auth_regex` (see https://github.com/buzzfeed/sso/blob/master/docs/sso_config.... ) would not work with this, because the original URI would not be checked.

Right now we have a dependency on Google as an OAuth2 provider, as that's what we use internally at BuzzFeed. However we've designed sso to allow us to easily add other providers. For example, there's this task ( https://github.com/buzzfeed/sso/issues/9 ) to create a default provider without Google dependencies for test purposes. We'd also welcome PRs adding other providers and believe any OAuth2 provider should be straight forward to add.

Yes, as mentioned in the blog post, we worked with Security Innovation to do a week long security assessment with full access to source code, design documents and endpoints. We also have a long term consulting arrangement with a widely respected security architect, and they helped review our design and implementation. Additionally, BuzzFeed has a bug bounty program on hackerone (https://hackerone.com/buzzfeed), and have invited partipating researchers to report on any issues found. We’ve paid out bounties for a number of minor issues, which were addressed prior to open-sourcing. Additionally, knowing that security is never done, we continue to make it eligible for bounties -- see https://github.com/buzzfeed/sso/blob/master/README.md#securi...

GitHub repo: https://github.com/buzzfeed/sso This is our identity aware proxy, which we've been using internally for a year. The blog post explains our motivations behind creating it, and open-sourcing it. It's available today, under MIT license. We'll be keeping an eye on the thread, and happy to follow up to any questions!