5 ms·
Hey, there were a few reasons behind this. - ease of migration was a big one, we had 100+ instances of bitly's oauth2_proxy, and were able to seamlessly migra
by itwasntandy 8y ago
Hey,
there were a few reasons behind this.
- ease of migration was a big one, we had 100+ instances of bitly's oauth2_proxy, and were able to seamlessly migrate them to this, without any changes to the services being protected.
- ease of deployment was also important. Our solution doesn't have any datastore dependencies, and is stateless, so was straightforward to deploy into our PaaS ( https://tech.buzzfeed.com/deploy-with-haste-the-story-of-rig-ca9a58b5719a https://tech.buzzfeed.com/deploy-with-haste-the-story-of-rig... ).
- when we built this, there were far fewer solutions than there are today. For example, Ory's Oathkeeper ( https://github.com/ory/oathkeeper https://github.com/ory/oathkeeper) was released after we were already using sso internally at BuzzFeed.
thanks!
- ashayh 8y agoIs it possible to use this with Nginx auth_request? I use bitlys oauth2_proxy like so because it doesn't support websockets.
- itwasntandy 8y agoMaybe - 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/oauthproxy.go#L321 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.md https://github.com/buzzfeed/sso/blob/master/docs/sso_config.... ) would not work with this, because the original URI would not be checked.