Launch HN: ShareWith (YC W21) – Easily share internal websites securely

[jakemoshenko]

Hi HN! We are Jake [jakemoshenko], Joey [jschorr], and Jimmy [jzelinskie] of Petricorp (https://petricorp.io). We’re building authorization services that reduce the overhead of adding a complex authorization policy to your apps and internal resources.

We’ve been building developer services and tools for over 15 years, and throughout that time we’ve repeatedly run into the problem where whatever authorization solution we pick for a new service at first, turns into a major limitation later down the road. Relational database backed libraries like the ones found in popular web frameworks have proven inflexible and a scaling bottleneck, and distributed policy engines such as Open Policy Agent [1] turn the evaluation scalability problem into one of distribution and consistency. In the past, we’ve even had to shelve product features because the effort required to safely alter the policy and migrate the data was higher than the value of the feature!

To solve these problems we’re building a multi-tenant SaaS platform based on Google’s Zanzibar paper [2], which allows for flexible tenant-defined policy, at planet scale. This new platform offers the consistent experience of a centralized auth solution, with the scalable nature of a distributed system. By taking on the operational overhead of running the platform ourselves and providing users with client libraries that reduce complexity, we're shouldering the burden to enable authorization decisions that are fast, accurate, and accessible across applications.

Today we’re launching our first product integrated with that platform: ShareWith (https://sharewith.io). ShareWith brings Google-docs style sharing to anything that you can run behind a reverse proxy or authenticate with OpenID Connect (OIDC) [3]. We think ShareWith is a great alternative to VPNs, which are hard to set up and configure, hard to federate access to, and don’t allow for fine-grained permissions or sharing with people outside of your organization.

We’ve already found a few interesting uses of the service: We secure traffic to our own internal dashboards by running them behind OAuth2 Proxy [4] instances configured with ShareWith. Other companies are using it to avoid building the boilerplate for adding sharing and permissions into their products entirely!

Because organizations in ShareWith are billed per unique participants that have had resources shared with them, the pricing model shouldn't inhibit protecting new things. Adding another service or adding an existing user to a new service doesn’t impose any additional cost.

ShareWith website protection is implemented using an extended OIDC provider. Normally, an OIDC provider is responsible only for returning an identity. Our provider will also match up a given access request with a pre-designated authorization requirement, and then check that the requestor has had that access shared with them. If not, we will pause the authentication flow and give them an option to request access, which notifies the owner: a familiar pattern to anyone who has ever had to request access to a document.

Underneath the hood, we are making dozens of requests to our platform, from writing and updating policy, to the individual access control checks. To answer an authorization check request, we first build a graph containing edges and nodes from both the policy and the individual relationships between users, groups, and resources. We then take that graph and attempt to find a path from the resource to the user. Once a path is found, or no such path can be found, the service informs the caller of the decision. Thanks to the distributed nature of the service, these answers are quickly computed by building and evaluating subgraphs in parallel, and each piece of data is replicated to ensure reliability.

Try out what we’ve built so far by following our guide (https://sharewith.io/first/) to protect an example service. If you want updates from the team, be sure to sign up for our mailing list (https://sharewith.io/newsletter) or follow us at https://twitter.com/petricorpio. If you're interested in integrating with our underlying authorization platform, you can reach out to us directly at [email protected].

We've learned a lot building ShareWith, but now we want to hear what you think about what we’ve built so far, and the direction in which we’re heading! We’ll be hanging around in the comments today if you have any questions or feedback.

[1] https://www.openpolicyagent.org/

[2] https://research.google/pubs/pub48190/

[3] https://openid.net/connect/

[4] https://oauth2-proxy.github.io/oauth2-proxy/

[TheFinalDraw]

How would you say your service stacks up against something like TailScale (https://tailscale.com/), which seems to solve the same problems but with end-to-end encryption and without the need to setup separate OAuth2 proxies? Where does ShareWith really shine and make things more easy/fast/secure/scalable/better than competitive solutions?

[jzelinskie]

TailScale is great -- I've met the founders and use it for my own personal network.

At it's core, ShareWith is more about being able to take anything that supports OIDC and adding the ability to dynamically request access in the login flow. OAuth2Proxy, which is a popular way to protect generic HTTP resources, is one convenient way to demonstrate that functionality, but you could leverage that same functionality in a completely different way native to your application if you don't want to have to build that same workflow for your app.

For the borderless network use case, an access request workflow really changes how you use protected resources because getting access to something becomes simple and routine. In a VPN setup, you're unlikely to share with users outside of your organization because of the overhead from provisioning and setup. Consider how you can easily share a Google doc with an outside contractor, but it's not worth the effort to give them access to a JIRA ticket.

[mahesh_rm]

Thank you for posting this here. I didn't know Tailscale existed. Just tried out. It is great.

[Zaheer]

This is cool. Was trying to deploy something with just private / internal access recently. It'd be cool if the steps could be simplified. Seems like currently I'd need to configure Oauth2proxy. How can I go from a locally running server with no auth protection to deploy in as few steps as possible? Right now I'd need to add an Oauth2proxy layer. I'm sure I could do it in a few hours... can it be entirely eliminated?

[jschorr]

For now, some form of proxy is required (unless your application supports OIDC already, in which case, you can just point it to our OIDC endpoint), but we are currently investigating ways to streamline this process even further. Stay tuned!

Edit: We provide copyable instructions in-app for running OAuth Proxy via Docker, so that should reduce the initial setup time down a bit

[gtank]

Super cool. I've been waiting for someone to pick up Zanzibar since the paper came out!

What are your plans for surfacing the policy relations to developers?

[jakemoshenko]

When you say policy relations, do you mean specifically the policies that we've written to drive ShareWith? Or do you mean the ability for developers to write their own policies for their own apps?

For the former, I can see that it might be important and informative to show how the various roles and their relationships relate to access, and we should write a blog post soon explaining how we interact with the platform to create ShareWith!

For the latter, we plan to open up the platform to developers as quickly as we can, so stay tuned!

[azlyth]

This could spare certain engineers so many Slack conversations.

Any plans on making something like a Helm chart to deploy to Kubernetes easily?

[jschorr]

We've actually integrated with our Kubernetes ingress to protect our own dashboards via ShareWith. Right now, our "Usage" tab shows how to setup oauth proxy or use via OIDC directly, but we're looking into expanding the examples for Kubernetes and other common use cases

[evancordell]

This looks great!

How is revocation handled? Will a proxy using sharewith as an oidc provider hit the authz graph on every request?

[jzelinskie]

Revocation is done in the ShareWith app or API. The ShareWith OIDC service does not handle the refresh tokens; those get handled by your upstream SSO. It's entirely up to whatever application is consuming our OIDC to decide how to set cookies that would make the session short or long lived. In the case of OAuth2Proxy, the default cookie lasts 5 minutes.

[js4ever]

Congrats for launching! You should really simplify the process, because right now after reading your quickstart it seems more complicated to use this compared to implementing a basic auth system inside the app

[jzelinskie]

Thanks! This is good feedback. The guide is effectively a verbose walkthrough setting up OAuth Proxy, which is the only way you could add authorization to a pre-existing application outside of your control, for example Prometheus.

For new projects, it might seem like picking up built-in auth system is easier until you realize you have to build a model of hierarchies of organizations, groups, etc... In my experience, some of these libraries cannot even express that model despite it being the most commonly required for web apps. ShareWith implements that model for you and even handles some of the trickier corner-cases like arbitrarily nesting groups.

[ldelossa]

Very cool! Excited to give this a try and see what else you guys come out with. - Louis.

[samkim]

Since you mentioned Google docs style sharing, does Sharewith support abilities for different users eg viewer vs commenter vs editor?

[jakemoshenko]

In the ShareWith app we have support for different roles that can mutate access, e.g. resource/group manager or viewer, where managers can grant additional access.

Because we layer in access at the authentication provider layer, we don't really have any impact on the downstream application. It's possible we could do some smart things with oauth scopes in the future!

[dataminded]

Is this similar to Cloudflare Access but with a better developer experience?

[jakemoshenko]

Similar! We're focusing much more on the seamless sharing side of the experience vs upfront policy configuration. ZTNA supports more protocols out of the box; we have plans to expand the the variety of services we can protect based on user priority.

[1-KB-OK]

Looks great! Well done jake, joey, jimmy