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?
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.
I worked for a premier backup software company that invested a lot in me. It was a small company and I rose quickly within the ranks to become second after the owner. I greatly respect(ed) the guy and was thankful for what he had given me, when we parted ways I would have given everything to work on my dream backup solution from scratch but knew it would be a below the belt blow to launch a competitor, especially given all I knew about their product, its inner workings, and deficiencies.
It’s been a long time ago now and I would have no qualms about getting into that business today as sufficient time has passed. But I wouldn’t change my decision if I could.
(btw, this is what being an awesome boss looks like.)
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.
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.
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?
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.
> 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?
Why is this not ethical? A lot of people I know who started their own company usually spun the idea off of experience from their prior employer. If its not ethical why not build it in your current company?
Everything I learned about authentication, I learned at this company by digging the code base and understanding our customer's problems. I don't think this is the same like "I worked a lot with XY web framework so I start a startup with XY." I actually learned the domain of authentication only on company time.
> If its not ethical why not build it in your current company?
That's a good question I'm not allowed to answer here :D
If that is not ethical then the entire Western business world will collapse.
This is what "work" accomplishes. You go to work, exchange your time for services done for the company. In exchange, the company gives you money, and yes - extreme amounts of domain knowledge, to the extent that you might be the only person on the planet who knows X topic. Then you take it to the next workplace, to spread it and to innovate. If your current company doesn't like it, they can 1) increase the pay - like pay you so much money that you're willing to stay. or 2) sue you and crush you so that even if you go elsewhere lawyers will be on you everywhere you go.
This is how every single person alive on the planet does it.
Without knowledge transfer and this type of behaviour, we would never progress beyond the industrial age.
> I actually learned the domain of authentication only on company time
True, but that same type of argument can be made for any of us. It's important not to take that argument too far, though. Remember that your company benefits from you learning & growing as well.
To be honest, I think the same way as you do. I feel really bad being a dick to an employer because I feel like I owe them something (although many HN'ers would argue we owe our employers nothing).
For me, it's helpful to make my guilt concrete - do I feel like I owe something to the company, or to specific people who mentored me? Usually it's the latter. And usually - hopefully - if they're good people, they'd be understanding if I made a decision that's best for me.
The advice I'd give to you is do what's best for you, which in this case seems like quitting and working on what you care about. But also show appreciation for the people that helped you along the way and don't burn bridges. A heartfelt thank you note/email (specific & different for each person) goes a long, long way. People remember these things and will think of you in the future.
And if they don't care or remember? Then you made the right choice to leave.
> I learned at this company by digging the code base and understanding our customer's problems.
Under this logic your'e stuck with your current employer forever. Resumes and interviews are all about what you learned at your previous jobs, so if you don't want to make use of that anywhere else, then you might as well shred your resume and forget about ever getting hired ¯\_(ツ)_/¯.
I bet your company goes around hiring experienced people and in fact I would bet that codebase was written by someone who had worked in authentication before, probably somewhere else. So unless it's not illegal (like company secrets) nothing to worry about.
> 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?
If you do this, make sure you have enough funds to support yourself for a while, and try to find someone who you can team up with.
Those are the two tips I have from having quit my job recently to work on a passion project. Actually, if you come up with a figure for how much you should have in savings, I'd say aim for double that figure. Every project is more difficult than we anticipate.
You have no moral duty to continue acting in the interest of your current employer. This wiki page discusses some of the issues around these situations. https://en.wikipedia.org/wiki/Non-compete_clause
If your idea is good then presenting that idea doesn't seem to be a problem. The issue is when you want to horde it to make a business out of it yourself.
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:
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!
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?
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.
> 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?
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.
There is no requirement for all of them to be under the same domain. It's not made clear in the article, but the documentation shows how you can run all of them under different domains too.
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.
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