
The process of open-sourcing BuzzFeed’s single sign-on experience - joeyespo
https://increment.com/security/open-sourcing-buzzfeeds-single-sign-on-process/
======
Walkman
Oh man, my heart breaks when I see yet another auth framework _yet again_ on
HN front page, because I work for a company selling Identity Access Management
solutions, so I'm not allowed to work on my dream authentication framework [1]
for obvious legal reasons. I know a lot of problems regarding authentication
and SSO, and I have such a simple solution in my head for a lot of use cases
which would be useful for a lot of companies. It is especially annoying
because I see how companies pay millions of dollars for fucking terrible
solutions I don't think it's fair.

The only way I could start working on this if I quit my job, but that might
not be very ethical thing to do. Any advice what should I do? What would you
do?

[1]: [https://github.com/kissgyorgy/fancy-
auth](https://github.com/kissgyorgy/fancy-auth)

~~~
barkingcat
Why is this not ethical? Once you quit your job you are free to work on any
project unless you have signed some sort of non-compete and even then, it's
probably the non-compete that's non-ethical and illegal.

~~~
FPGAhacker
Depending on the size of the company you worked for, and their legal budget,
they may decide to go after you for things you produce even without a non-
compete. Or rather they go after ownership of what you produce, claiming it is
based on knowledge you gained while performing your job duties for them.

It is far from guaranteed to happen, but it's a risk with a chilling effect.

~~~
jonathankoren
Noncompetes are rarely enforced.

Move to California if you’re really scared.

~~~
lazyasciiart
Will that protect you from a suit filed in the place of your last employment?

~~~
elithrar
No, because you signed the contract in another state. They can still sue you
there in the majority of cases.

~~~
jonathankoren
Interstate noncompetes are unenforceable in California. See Application Group,
Inc. v. Hunter Group, Inc (1988).

Also, one could argue that enforcing a noncompete nationally, would be
regulating interstate commerce, and thus the pervue of the federal government.
There is no federal noncompete law.

[https://en.wikipedia.org/wiki/Non-
compete_clause](https://en.wikipedia.org/wiki/Non-compete_clause)

~~~
redtexture
Could it only take a filing in federal court, in the state where the NDA
specifies which state's laws shall considered, to bring the former employee
into the local regime of the NDA, under a diversity of jurisdictions process?

~~~
jonathankoren
No. It's against the public policy of the State of California for a noncompete
to be valid, and so the contract is invalid.

There's a compelling state interest not to enforce contracts that harm their
residents. California has decided that more harm is done by enforcing such a
contract than not.

But yeah, I'm sure you can find lots of lawyers to file as many motions as you
want as long as your checks cash, but in the end you're going to have to
decide that this is really worth it, especially since there's a very real
possibility that you'd end up going up against the State of California.

------
shay_ker
This part is really eye-opening on getting an organization to open source
their code:

[https://increment.com/security/open-sourcing-buzzfeeds-
singl...](https://increment.com/security/open-sourcing-buzzfeeds-single-sign-
on-process/#securing-our-systems)

There's understandably a lot of pressure in open sourcing anything security
related. I wonder if that's because this SSO project belongs to Buzzfeed, and
not a company that specializes in API gateways, like Kong:

[https://github.com/ohioit/kong-oauth-sso](https://github.com/ohioit/kong-
oauth-sso)

So many devs end up implementing oauth & sso through an API gateway when they
move to microservices (we did). I'm just surprised that those features don't
exist in popular gateways like nginx & haproxy in the non-enterprise versions.
It seems sorely needed!

------
minimaxir
Link to the Show HN of BuzzFeed SSO:
[https://news.ycombinator.com/item?id=17828293](https://news.ycombinator.com/item?id=17828293)

------
Lx1oG-AWb6h_ZG0
Maybe I’m missing something, but what is the advantage of maintaining a
separate oauth provider (sso-auth)? Since they apparently need to support just
google creds, why not let sso-proxy talk to google directly? Why do they need
to maintain a separate token infrastructure?

The other (related) question is how the token refresh works - is it tied to
the underlying refresh token generated by google, or is it something
completely independent?

~~~
X-Istence
sso-auth allows you to authenticate against Google once, and then any other
requests that come to it can be redirect back to the calling application
without first hitting Google.

If you registered each new app directly with Google, every time the user
visited a new app, they would be redirect to Google to provide permission to
the app to log them in, and then be redirected back.

This is described in: [https://tech.buzzfeed.com/unleashing-
the-a6a1a5da39d6](https://tech.buzzfeed.com/unleashing-the-a6a1a5da39d6)

~~~
Lx1oG-AWb6h_ZG0
> Now, their employees can securely access Ghost Land at ghost-
> land.sso.pacworld.com

That’s the part I’m confused about. They force all sites that need SSO to be
under the same subdomain. If they can share the same session cookie, why does
each microservice need to redirect at all? Can’t they all use the same oauth
app underneath?

~~~
Buge
One possible reason is they might want each microservice to be a separate
security domain. So that if one microservice is compromised, attackers cannot
use credentials stolen from that microservice to control other microservices.

------
barbecue_sauce
Seems strange to me to use OAuth for internal SSO. I'm not sure I would want
my Google identity explicitly linked to my corporate identity.

~~~
tphan
The company would create a new Google account for you.

------
gammateam
We use ethereum address namespace for standardized cryptographic key pairs,
and standardized signing.

Through our API we also let people build hosted solutions that let people make
familiar usernames and passwords, for people that would find too much friction
getting into the ethereum ecosystem.

But its not like you need cryptocurrency to sign.

Any wallet will do, We’ll also release our own eventually which will just be a
code fork with our own branding And people wont even know about any of that
web3 cryptocurrency stuff.

~~~
xfitm3
Spam?

~~~
gammateam
why would it be spam?

