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 (