3 ms·

Neat project, but I have to ask why you didn't go with an existing solution like Keycloak?

• 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 ago
    Is it possible to use this with Nginx auth_request? I use bitlys oauth2_proxy like so because it doesn't support websockets.
    • itwasntandy 8y ago
      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/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.