Hands-off Authorization for SaaS

You don't roll your own authentication - why roll your own authorization?

Introducing Authorization as a Service

What a user can see and do in your platform gets complicated. Our new service simplifies that problem, keeping it fast, transparent and, importantly, yours. Spinning up a new SaaS business? Evolving your line-of-business app? Building a shared database project? With pecan, we've got you covered.

Use cases

All-in-one

Developing an API for your new SaaS? Use pecan as an identity provider for your authentication needs, then implement resource-based access control, feature flags, and multi-tenancy using one of the client libraries.

Authorization

Building a server and already have authentication covered? Use pecan for resource, role, and claim management. Look up a profile using the authenticated user's id, and unlock flexible authorization within your app.

Integration

Your API server uses a third party identity provider that already defines all your roles? Use pecan to define what resources those roles can access, and move management of authorization data out of your application.

Resources, roles, and attributes

You are building your own platform, a group of resources that users access to get things done. Your administrators set up different roles to describe which users can access what resources, and different administrators have different levels of access to the user profiles themselves. The platform attaches some extra attributes so it can be smart about what data can be seen by each user. And building the module that covers all that distracts you from your core business, giving your competitors an edge.

If that description sounds right to you, pecan is the tool you need. By adding software engineering smarts to a claims-based security profile, authorization becomes a standardized layer you apply to every service you manage.

With pecan, we think about authorization so you don't have to. Spend more time on the problems that affect your customers, not your platform.

Design in the cloud, decide at the edge

Authorization is a hard problem, and you face challenges unique to your business. Copying your confidential information up to a third-party service in the cloud comes with challenges and risks, and you want full control over the performance profile of your platform. That means you want your data to stay where it is, you want control over any code that runs in your platform, and you want to make authorization decisions locally.

That means you want pecan. We use the cloud to make co-ordination easy, but unlike most other authorization services we bring the user profiles to your data, not the other way round. Careful design went into maintaining forward compatibility as you release new versions of your platform, all client libraries are open source and auditable, and a key design aim was to ensure every authorization decision could be made locally, in your platform, running your code.

Build your authorization model around your platform, not the other way around. How you do authorization should evolve as your understanding of your business matures.

Context is everything

The philosophy behind pecan is context over global state. Restricting a user to a single profile means only one group of super-users can be trusted to manage that profile. It can also mean authorization decisions touch everything stored in the app. Authorization gets more complex, risks grow, and app performance takes a hit.

Instead, a user can have many profiles, each with a different context. Accessing resources managed by a franchisee? Load the profile stored against the franchisee's organization, and have them take responsibility for granting you access to the data you need. Granting access to resources in your organization to that same franchisee? Grant enough access to their organization's profile, and have them delegate access to trusted users within their franchise.

Or perhaps your users log in with from multiple oauth providers? Use the same profile, but create different resources against each provider. As they verify each account, unlock the parts of your application that depend on those external resources.

We believe the resource owner should be in full control of their own system. That means bringing the user to the data for authorization decisions, not the other way round.

Frequently asked questions

A few things that come up on the regular. Still can’t find the answer you’re looking for? Reach out to our customer support team.

How do I create my security schema?: The pecan web app lets you create roles, claims, resources, organizations, and accounts. Roles and claims can be managed on the fly, while resources follow a release process.
How do I add pecan to my app?: Use one of the pre-built libraries or the pecan API to create an authorization service in your app. Fetch (or embed and load) the security schema for that app once on start, and then pass its user claims to make authorization decisions.
How do I fetch a user's profile?: An authenticated user has a unique key in an identity provider. That key becomes a claim in the user's profile in pecan. Use the authorization service to look up that profile using the claim, then fetch (and cache) all other relevant claims using the app's credentials.
How do I make an authorization decision?: Pass the current user's claims to the authorization services to check for access to a resource. No external requests are necessary - so it will be fast! Use the claims to identify the current user/tenant/organization, and then pass the full security profile to the authorization library of your choice (like the impressive Oso library) to implement attribute-based-access control.
Why not Zanzibar?: Google's answer to authorization is Zanzibar, described as a 'consistent, global authorization system'. It is impressive technology, and has spawned several consumer offerings. The catch - everything needs to be replicated into the external authorization service. Attributes, ids, relationships, everything. Which means disabling a button in your app involves asking Google for permission, which definitely doesn't empower your developers or your users.
Why not Oso?: Similar to Zanzibar, the Oso service requires you to replicate everything up into their external data store, which is a fundamentally different approach to making decisions at the edge with pecan. They do provide an authorization library, and using pecan to manage user profiles and passing claims to the Oso library is an encouraged example use case.

Simplify your stack. Start using pecan today.

Your new one-stop shop for everything authorization in your platform.