What does HackerNews think of oauth2-proxy?
A reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.
My personal solution for HTTP stuff that should be private but I want to access from anywhere is to add another independent authentication layer.
I've so far settled on SSO using oauth2-proxy[1] out of convenience, but probably even basic http auth is enough.
That means that even if the running service authentication is broken, or like in this case, bypassed, it will still be caught by the first layer of authentication. See my HA instance[2] for an example.
For home assistant the tradeoff is that the native app doesn't work, but I'm sure there's a smart way to whitelist requests just for my device, I just haven't gotten around to it since the web page has been sufficient so far.
The picture-of-a-tweet nails it, but the author misses the point. It's not "we have Python devs" it's "reST has the best syntax for extensibility": if you need to start doing some sort of macro or pre-processing, reST's syntax is cut out for that. M↓ is not; you'll need to do it out of band. Or, to put it differently, reST's directives offer extension hooks.
> You’ll need to set up an identity and access management (IAM) service in front of your static website. Unless IAM is your jam, it’s better to avail of a managed service to tackle it.
We throw ours behind Github, I think using https://github.com/oauth2-proxy/oauth2-proxy ; then Github is our IAM.
Honestly, while I think reST has a more cleanly thought out syntax that will allow you to grow the complex use cases docs will inevitably hit … the tooling just isn't as good, IMO. Markdown parsers are prolific … reST … not so much, particularly outside of Python. (And IMO, docutils in Python is not very easy to use if you want fine control over parsing & output. It's there, but just hard to take advantage of.) M↓'s syntax is also somewhat limiting: there's just not a lot it can do. (Admonitions, in particular, are useful in tech docs and missing.) There's always HTML, … but that's just not the same.
(I've no experience w/ AsciiDoc.)
That's kinda overwhelming though ... imagine that if the maintainer pops up somewhere, suddenly 100 motivated people may chime in "hey please review this important pull request that's been sitting over here for a while".
There are some kinds of open source projects that are prone to this ... some are really not so bad to maintain if you have the right kind of discipline, because they converge on a stable set of functionality and platform compatibility evolves slowly, but some just naturally have endless room for variations and special cases, and as users increase, PRs increase linearly (instead of sub-linearly as you'd hope). I'm thinking in particular of https://github.com/oauth2-proxy/oauth2-proxy (of which I contributed to an older fork)
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.
There's also S.S.Octopus, and Pomerium. https://github.com/buzzfeed/sso https://github.com/pomerium/pomerium
They all have different OAuth providers, so check them each out to see which one works with your identity provider. (GitHub OAuth + SSO makes using these a no-brainer)
For just SAML, there's saml-auth-proxy, though I haven't looked into it much. https://github.com/itzg/saml-auth-proxy
https://github.com/oauth2-proxy/oauth2-proxy
It allows me to put different services behind oauth-logins, with confidence. Not too heavyweight or complex, and has a decent history of good support.
https://github.com/oauth2-proxy/oauth2-proxy is a maintained fork.
https://github.com/oauth2-proxy/oauth2-proxy
I've used that to gate-access to internal things behind gsuite domains, and it supports authentication against github and other providers too.