thanks for making it open source
They didn't make it open source. The headline is wrong.
Show HN: Open-source OAuth service for 40+ APIs
51–60 of 60 posts
Re: Show HN: Open-source OAuth service for 40+ APIs
#52Earlier quoted context omitted.
no no no.... my understanding is if you are using it in house for a product, you are fine but you cannot offer it as a hosted service to your customers. read "aws offers managed DB" you cannot do that but you should be able to use this in your "cat picture search engine that uses this DB hosted inhouse". that is a big difference
As far as I understand the elastic license I cannot create a SAAS product that includes this and then create a company selling that saas product to 1000s of paying clients (again; not the size of evil Amazon but a not that successful, lifestyle b2b saas business). It’s a crippling license that goes against many of the modern ideas of oss and only becuase Amazon abused it. So name and shame but don’t punish the rest.…
It's fine what they're doing. Just two things:
1. It doesn't solve my problem of finding an Open Source tool. I can just ignore it.
2. I won't read the code because they could claim I copied it if I wrote a similar tool. A browser extension to keep me from viewing Source-Available code would be nice.
Re: Show HN: Open-source OAuth service for 40+ APIs
#53Earlier quoted context omitted.
As far as I understand the elastic license I cannot create a SAAS product that includes this and then create a company selling that saas product to 1000s of paying clients (again; not the size of evil Amazon but a not that successful, lifestyle b2b saas business). It’s a crippling license that goes against many of the modern ideas of oss and only becuase Amazon abused it. So name and shame but don’t punish the rest.…
> MIT-but-not-for-Amazon. but that the problem. There cannot be MIT-but-not-for-Amazon. MIT is a do whatever you want license. The problem of 4 freedoms is restricted in MIT, that is why GPL exists. SSPL or this license extends that to exclude AWS. You are right, they could just exclude AWS but you cannot build a license around specific people or names, aws could just change their name and avoid that. If you were wri…
> aws could just change their name and avoid that.
But if you say Amazon or any of their subsidiaries. They are not going to rename Amazon to add 1 product to aws.
The wording is indeed difficult; for my taste to be something not considered abuse, it would need to be integrated in a bespoke product where it offers less than 5% of said products functionality. However that would allow aws. But I think it can be rewritten or added on-to by saying something like that it cannot be offered as a distinct service meaning you cannot say ‘we offer a search engine, here is elastic’; it can be a nocode product which allows you to add search and search apis from elastic by clicking them together if that nocode product also allows for many other features not offered in elastic. So some way to convey it needs to be integrated and not just a copy you can spin up.
However, that would be difficult and convoluted and hard to fight. That’s why I was thinking about adding mandatory FTEs if you use it to make money. That type of thing would simply have the aws lawyers not sign off using it.
Re: Show HN: Open-source OAuth service for 40+ APIs
#54Earlier quoted context omitted.
As far as I understand the elastic license I cannot create a SAAS product that includes this and then create a company selling that saas product to 1000s of paying clients (again; not the size of evil Amazon but a not that successful, lifestyle b2b saas business). It’s a crippling license that goes against many of the modern ideas of oss and only becuase Amazon abused it. So name and shame but don’t punish the rest.…
It's fine what they're doing. Just two things: 1. It doesn't solve my problem of finding an Open Source tool. I can just ignore it. 2. I won't read the code because they could claim I copied it if I wrote a similar tool. A browser extension to keep me from viewing Source-Available code would be nice.
Agreed. I would just know why they do what they do; it seems everyone using the Elastic license is because of what aws did with elastic search. If that is the case, there are other options friendlier for open source (vs source available) while not allowing aws (like) to do what they do. It’s not totally in line with freedom but at least makes it usable.
Re: Show HN: Open-source OAuth service for 40+ APIs
#55Looks interesting. But why do you recommend such large 20/40 usd droplets for running on digital ocean? Surely one would scale pretty far by simply using a dedicated postgres db - and a small app container? Or does the backend do some heavy lifting I'm missing?
You are absolutely right, I'll change this.
We made this doc when we were focusing on syncing data, which was much more intensive.
Though in the future, we plan to offer a proxy that would funnel your external requests and would require more processing power. The advantages of a proxy are that we can automatically authenticate requests, handle retries & rate limits, monitor & alert, etc.
Re: Show HN: Open-source OAuth service for 40+ APIs
#56Earlier quoted context omitted.
It's fine what they're doing. Just two things: 1. It doesn't solve my problem of finding an Open Source tool. I can just ignore it. 2. I won't read the code because they could claim I copied it if I wrote a similar tool. A browser extension to keep me from viewing Source-Available code would be nice.
Agreed. I would just know why they do what they do; it seems everyone using the Elastic license is because of what aws did with elastic search. If that is the case, there are other options friendlier for open source (vs source available) while not allowing aws (like) to do what they do. It’s not totally in line with freedom but at least makes it usable.
does this license violate 4 freedoms or not?
Re: Show HN: Open-source OAuth service for 40+ APIs
#57This is cool. I like the frontend aspect. Looks really handy for a lot of apps where integration with other services is a core feature (I've built several just over the past few years, so I definitely get it). I do wish it supported encrypted storage. For example, I wrote/maintain a Vault plugin to do basically the same work as the backend side of this project[0]. I wonder if you would be interested in supporting Vau…
Thanks a lot for all the insights, this is great!
"Rather our customers would get into situations where they inadvertently revoked access, the user that authorized the integration initially left the company and it was automatically disabled, etc. and there was no notification that it happened. Basically all of the lifecycle management side that couldn't be automated down to "refresh my token when it's about to expire" sucked. So anything you're looking to support there would be a huge value-add IMO."
I can definitely see value in notifying that API access has been revoked. If you think of any other case you'd like covered, I am interested!
Re: Show HN: Open-source OAuth service for 40+ APIs
#58Earlier quoted context omitted.
> Credentials are not encrypted at rest and stored in plain text LOL. Advertising something as a security product and doing this is absolutely ridiculous.
Well, you _could_ encrypt the tokens but you can't hash them like a password so they have to be stored in some format in their entirety. However, it seems reasonable to infer they are referring to storage in the DB itself. How would you suggest they encrypt it securely at rest for an out-of-the-box "setup and go" scenario? I will note that a lot of the existing "plugin" OAuth type providers for popular web frameworks…
What I'm doing is have a _separate_ encryption key for _each_ OAuth provider on the server, encrypt with that and save it in a HTTPOnly browser cookie. This way if the key gets stolen from the server, the attacker doesn't even have any user OAuth tokens. If the cookies are stolen from the user's browser, the attacker can't do anything with it. If one user's cookie is stolen AND the encryption key is stolen, only one user is affected. As the cookie is HTTPOnly, there is no XSS surface, the client need to communicate with the server to be able to API requests to the OAuth provider.
Re: Show HN: Open-source OAuth service for 40+ APIs
#59Is it really that hard? i have a few integrations with oauth api's and for the most part i just check the dates on the tokens before sending them through?
Re: Show HN: Open-source OAuth service for 40+ APIs
#60Earlier quoted context omitted.
no no no.... my understanding is if you are using it in house for a product, you are fine but you cannot offer it as a hosted service to your customers. read "aws offers managed DB" you cannot do that but you should be able to use this in your "cat picture search engine that uses this DB hosted inhouse". that is a big difference
As far as I understand the elastic license I cannot create a SAAS product that includes this and then create a company selling that saas product to 1000s of paying clients (again; not the size of evil Amazon but a not that successful, lifestyle b2b saas business). It’s a crippling license that goes against many of the modern ideas of oss and only becuase Amazon abused it. So name and shame but don’t punish the rest.…
> As far as I understand the elastic license I cannot create a SAAS product that includes this and then create a company selling that saas product to 1000s of paying clients.
Yes, you can. You're not providing Nango as a managed service; you're providing your SaaS as a managed service, which uses Nango for some things. But as long as your customers can't access a sizeable portion of Nango *for purposes outside your SaaS*, you're fine.
https://www.elastic.co/licensing/elastic-license/faq
IANAL.