keto

Open Source (Go) implementation of "Zanzibar: Google's Consistent, Global Authorization System". Ships gRPC, REST APIs, newSQL, and an easy and granular permission language. Supports ACL, RBAC, and other access models.

4,774

347

4,774

View on GitHub

Top Related Projects

spicedb

4,924

Open Source, Google Zanzibar-inspired permissions database to enable fine-grained authorization for customer applications

casbin

17,484

An authorization library that supports access control models like ACL, RBAC, ABAC in Golang: https://discord.gg/S5UjpzGZjN

opa

9,505

Open Policy Agent (OPA) is an open source, general-purpose policy engine.

opal

4,143

Policy and data administration, distribution, and real-time updates on top of Policy Agents (OPA, Cedar, ...)

warrant

1,112

Warrant is a highly scalable, centralized authorization service based on Google Zanzibar. Use it to define, enforce, query, and audit application authorization and access control.

oso

3,467

Oso is a batteries-included framework for building authorization in your application.

Quick Overview

Ory Keto is an open-source access control server that implements Google's Zanzibar model. It provides fine-grained permission management for cloud-native applications, offering a scalable and flexible solution for authorization across microservices and distributed systems.

Pros

Implements the battle-tested Zanzibar model used by Google, offering a robust and scalable authorization system
Provides a RESTful API and gRPC interface for easy integration with various programming languages and frameworks
Supports multi-tenancy and complex relationship-based access control scenarios
Offers high performance and low latency, suitable for large-scale applications

Cons

Steep learning curve for developers unfamiliar with the Zanzibar model
Limited documentation and examples compared to some other authorization solutions
Requires additional infrastructure setup and maintenance
May be overkill for simple authorization scenarios in small applications

Code Examples

Checking if a user has a specific permission:

import "github.com/ory/keto-client-go"

client, _ := keto.NewCodeGenSDK(&keto.Configuration{
    Host: "http://localhost:4466",
})

allowed, _, _ := client.PermissionApi.CheckPermission(context.Background()).
    Namespace("files").
    Object("file:1").
    Relation("view").
    Subject("user:john").
    Execute()

if allowed {
    fmt.Println("User has permission to view the file")
}

Creating a relationship:

relationship := keto.RelationshipPatch{
    Action:    keto.RELATIONSHIPPATCHACTIONINSERT,
    Namespace: "files",
    Object:    "file:1",
    Relation:  "owner",
    Subject:   "user:alice",
}

_, _, _ = client.RelationshipApi.PatchRelationships(context.Background()).
    RelationshipPatch([]keto.RelationshipPatch{relationship}).
    Execute()

Querying relationships:

relationships, _, _ := client.RelationshipApi.GetRelationships(context.Background()).
    Namespace("files").
    Object("file:1").
    Execute()

for _, rel := range relationships {
    fmt.Printf("Relation: %s, Subject: %s\n", rel.Relation, rel.Subject)
}

Getting Started

Install Ory Keto:
```
docker pull oryd/keto:v0.11.1
```

Run Keto:

docker run -p 4466:4466 -p 4467:4467 -e DSN=memory oryd/keto:v0.11.1 serve

Install the Go client:
```
go get github.com/ory/keto-client-go
```

Initialize the client in your Go code:

import "github.com/ory/keto-client-go"

client, _ := keto.NewCodeGenSDK(&keto.Configuration{
    Host: "http://localhost:4466",
})

Now you can use the client to interact with Ory Keto's API.

Competitor Comparisons

spicedb

4,924

Open Source, Google Zanzibar-inspired permissions database to enable fine-grained authorization for customer applications

Pros of SpiceDB

More active development with frequent updates and releases
Built-in support for multiple storage backends (PostgreSQL, MySQL, CockroachDB)
Comprehensive documentation and examples for various use cases

Cons of SpiceDB

Steeper learning curve due to its more complex relationship model
Requires more setup and configuration compared to Keto's simpler approach
Limited built-in integrations with other authentication systems

Code Comparison

SpiceDB schema definition:

definition user {}

definition document {
    relation viewer: user
    relation editor: user
    permission view = viewer + editor
    permission edit = editor
}

Keto policy definition:

{
  "id": "document",
  "subjects": ["user"],
  "resources": ["document"],
  "actions": ["view", "edit"],
  "effect": "allow",
  "conditions": {
    "roles": {
      "type": "AnyOf",
      "options": ["viewer", "editor"]
    }
  }
}

Both systems allow for defining complex authorization rules, but SpiceDB's schema offers a more expressive and hierarchical approach to modeling relationships and permissions.

casbin

17,484

An authorization library that supports access control models like ACL, RBAC, ABAC in Golang: https://discord.gg/S5UjpzGZjN

Pros of Casbin

More flexible and supports multiple access control models (ACL, RBAC, ABAC, etc.)
Easier to integrate with various programming languages and frameworks
Larger community and more extensive documentation

Cons of Casbin

Steeper learning curve due to its flexibility and multiple model support
May require more configuration and setup for complex scenarios
Performance can be slower for large-scale applications compared to Keto

Code Comparison

Casbin policy definition:

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

Keto relation tuple:

{
  "namespace": "files",
  "object": "file:secrets.txt",
  "relation": "view",
  "subject": "user:john"
}

Both Casbin and Keto offer powerful authorization solutions, but they differ in their approach and implementation. Casbin provides a more flexible and language-agnostic solution, while Keto focuses on performance and integration within the Ory ecosystem. The choice between the two depends on specific project requirements, existing infrastructure, and desired level of customization.

opa

9,505

Open Policy Agent (OPA) is an open source, general-purpose policy engine.

Pros of OPA

More flexible and general-purpose policy engine, supporting a wide range of use cases
Larger community and ecosystem, with extensive documentation and integrations
Declarative policy language (Rego) designed for expressing complex policies

Cons of OPA

Steeper learning curve due to the Rego language and more complex architecture
May require more setup and configuration for specific authorization use cases
Can be overkill for simpler access control scenarios

Code Comparison

OPA (Rego policy):

package authz

default allow = false

allow {
    input.method == "GET"
    input.path == ["api", "users"]
    input.user.role == "admin"
}

Keto (ACL policy):

- id: read_users
  subjects:
    - "role:admin"
  resources:
    - "api:users"
  actions:
    - "get"

Summary

OPA is a more versatile and powerful policy engine suitable for complex scenarios across various domains. Keto focuses specifically on access control and authorization, offering a simpler setup for common use cases. OPA uses the Rego language for policy definition, while Keto employs a more straightforward ACL-based approach. Choose OPA for flexibility and broader policy needs, and Keto for streamlined authorization in web applications.

opal

4,143

Policy and data administration, distribution, and real-time updates on top of Policy Agents (OPA, Cedar, ...)

Pros of Opal

More flexible policy language (OPA's Rego) compared to Keto's ACL/RBAC
Built-in support for distributed caching and real-time updates
Easier integration with existing authorization systems

Cons of Opal

Less mature project with potentially fewer enterprise deployments
Steeper learning curve for Rego language compared to Keto's simpler model
May require more resources due to its distributed architecture

Code Comparison

Keto (ACL example):

{
  "namespace": "files",
  "object": "file:1",
  "relation": "view",
  "subject": "user:bob"
}

Opal (OPA policy example):

package authz

default allow = false

allow {
  input.method == "GET"
  input.path == ["files", file_id]
  input.subject.id == "bob"
}

Both projects aim to provide fine-grained authorization, but Opal offers more flexibility and expressiveness through OPA's Rego language. Keto's approach is simpler and may be easier to implement for basic use cases. The choice between them depends on the specific requirements of the project and the team's familiarity with the respective technologies.

warrant

1,112

Warrant is a highly scalable, centralized authorization service based on Google Zanzibar. Use it to define, enforce, query, and audit application authorization and access control.

Pros of Warrant

Simpler setup and configuration process
More user-friendly API design
Better documentation and examples for quick integration

Cons of Warrant

Less mature project with fewer contributors
Limited support for complex authorization scenarios
Fewer integrations with other tools and services

Code Comparison

Warrant:

const warrant = new Warrant({ apiKey: 'YOUR_API_KEY' });
await warrant.create('user', { userId: 'user-1' });
await warrant.create('permission', { permissionId: 'edit-post' });
await warrant.assign('user', 'user-1', 'permission', 'edit-post');

Keto:

c := client.NewClient("http://localhost:4466")
_, err := c.CreateRelationTuple(context.Background(), &acl.RelationTuple{
    Namespace: "blog",
    Object:    "post:1",
    Relation:  "edit",
    Subject:   "user:1",
})

Both Warrant and Keto provide authorization solutions, but Warrant focuses on simplicity and ease of use, while Keto offers more flexibility for complex scenarios. Warrant's API is more intuitive for basic use cases, but Keto's design allows for more granular control over permissions. The code examples demonstrate the difference in approach, with Warrant using a more straightforward method for assigning permissions, while Keto utilizes a more detailed relation tuple structure.

oso

3,467

Oso is a batteries-included framework for building authorization in your application.

Pros of Oso

More flexible policy language (Polar) for expressing complex authorization rules
Better integration with application code, allowing for in-code policy checks
Extensive documentation and tutorials for easier adoption

Cons of Oso

Less focus on distributed systems and microservices compared to Keto
Requires learning a new policy language (Polar) instead of using familiar formats like JSON or YAML
May have higher resource usage due to its embedded nature

Code Comparison

Oso (using Polar language):

allow(user, "read", post) if
    user.role = "admin" or
    post.author = user;

Keto (using Access Control Lists):

{
  "subjects": ["user:alice"],
  "actions": ["read"],
  "resources": ["post:123"],
  "effect": "allow"
}

Both Oso and Keto provide powerful authorization solutions, but they approach the problem differently. Oso focuses on embedding authorization logic directly into application code, while Keto is designed as a standalone service for distributed systems. The choice between them depends on specific project requirements and architectural preferences.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Chat | Discusssions | Newsletter

Guide | API Docs | Code Docs

Support this project!

Work in Open Source, Ory is hiring!

Ory Keto is the first and most popular open source implementation of "Zanzibar: Google's Consistent, Global Authorization System"!

Get Started

You can use Docker to run Ory Keto locally or use the Ory CLI to try out Ory Keto:

# This example works best in Bash
bash <(curl https://raw.githubusercontent.com/ory/meta/master/install.sh) -b . ory
sudo mv ./ory /usr/local/bin/

# Or with Homebrew installed
brew install ory/tap/cli

create a new project (you may also use Docker)

ory create project --name "Ory Keto Example"
export project_id="{set to the id from output}"

and follow the quick & easy steps below.

Create a namespace with the Ory Permission Language

# Write a simple configuration with one namespace
echo "class Document implements Namespace {}" > config.ts

# Apply that configuration
ory patch opl --project $project_id -f file://./config.ts

# Create a relationship that grants tom access to a document
echo "Document:secret#read@tom" \
  | ory parse relation-tuples --project=$project_id --format=json - \
  | ory create relation-tuples --project=$project_id -

# List all relationships
ory list relation-tuples --project=$project_id
# Output:
#   NAMESPACE	OBJECT	RELATION NAME	SUBJECT
#   Document	secret	read		tom
#
#   NEXT PAGE TOKEN
#   IS LAST PAGE	true

Now, check out your project on the Ory Network or continue with a more in-depth guide.

Ory Keto on the Ory Network

The Ory Network is the fastest, most secure and worry-free way to use Ory's Services. Ory Permissions is powered by the Ory Keto open source permission server, and it's fully API-compatible.

The Ory Network provides the infrastructure for modern end-to-end security:

Identity & credential management scaling to billions of users and devices
Registration, Login and Account management flows for passkey, biometric, social, SSO and multi-factor authentication
Pre-built login, registration and account management pages and components
OAuth2 and OpenID provider for single sign on, API access and machine-to-machine authorization
Low-latency permission checks based on Google's Zanzibar model and with built-in support for the Ory Permission Language

It's fully managed, highly available, developer & compliance-friendly!

GDPR-friendly secure storage with data locality
Cloud-native APIs, compatible with Ory's Open Source servers
Comprehensive admin tools with the web-based Ory Console and the Ory Command Line Interface (CLI)
Extensive documentation, straightforward examples and easy-to-follow guides
Fair, usage-based pricing

Ory Network Hybrid Support Plan

Ory offers a support plan for Ory Network Hybrid, including Ory on private cloud deployments. If you have a self-hosted solution and would like help, consider a support plan! The team at Ory has years of experience in cloud computing. Ory's offering is the only official program for qualified support from the maintainers. For more information see the website or book a meeting!

Ory Permissions, Keto and the Google's Zanzibar model

Determining whether online users are authorized to access digital objects is central to preserving privacy. This paper presents the design, implementation, and deployment of Zanzibar, a global system for storing and evaluating access control lists. Zanzibar provides a uniform data model and configuration language for expressing a wide range of access control policies from hundreds of client services at Google, including Calendar, Cloud, Drive, Maps, Photos, and YouTube. Its authorization decisions respect causal ordering of user actions and thus provide external consistency amid changes to access control lists and object contents. Zanzibar scales to trillions of access control lists and millions of authorization requests per second to support services used by billions of people. It has maintained 95th-percentile latency of less than 10 milliseconds and availability of greater than 99.999% over 3 years of production use.

Source

If you need to know if a user (or robot, car, service) is allowed to do something - Ory Permissions and Ory Keto are the right fit for you.

Currently, Ory Permissions [on the Ory Network] and the open-source Ory Keto permission server implement the API contracts for managing and checking relations ("permissions") with HTTP and gRPC APIs, as well as global rules defined through the Ory Permission Language ("userset rewrites"). Future versions will include features such as Zookies, reverse permission lookups, and more.

Ory Permissions, Keto and the Google's Zanzibar model
Who's Using It?
- Installation
Ecosystem
Security
- Disclosing Vulnerabilities
Telemetry

Who's Using It?

The Ory community stands on the shoulders of individuals, companies, and maintainers. The Ory team thanks everyone involved - from submitting bug reports and feature requests, to contributing patches and documentation. The Ory community counts more than 33.000 members and is growing rapidly. The Ory stack protects 60.000.000.000+ API requests every month with over 400.000+ active service nodes. None of this would have been possible without each and everyone of you!

The following list represents companies that have accompanied us along the way and that have made outstanding contributions to our ecosystem. If you think that your company deserves a spot here, reach out to office@ory.sh now!

Type	Name	Website
Adopter *	Raspberry PI Foundation	raspberrypi.org
Adopter *	Kyma Project	kyma-project.io
Adopter *	Tulip	tulip.com
Adopter *	Cashdeck / All My Funds	cashdeck.com.au
Adopter *	Hootsuite	hootsuite.com
Adopter *	Segment	segment.com
Adopter *	Arduino	arduino.cc
Adopter *	DataDetect	unifiedglobalarchiving.com/data-detect/
Adopter *	Sainsbury's	sainsburys.co.uk
Adopter *	Contraste	contraste.com
Adopter *	Reyah	reyah.eu
Adopter *	Zero	getzero.dev
Adopter *	Padis	padis.io
Adopter *	Cloudbear	cloudbear.eu
Adopter *	Security Onion Solutions	securityonionsolutions.com
Adopter *	Factly	factlylabs.com
Adopter *	Nortal	nortal.com
Adopter *	OrderMyGear	ordermygear.com
Adopter *	Spiri.bo	spiri.bo
Adopter *	Strivacity	strivacity.com
Adopter *	Hanko	hanko.io
Adopter *	Rabbit	rabbit.co.th
Adopter *	inMusic	inmusicbrands.com
Adopter *	Buhta	buhta.com
Adopter *	Connctd	connctd.com
Adopter *	Paralus	paralus.io
Adopter *	TIER IV	tier4.jp
Adopter *	R2Devops	r2devops.io
Adopter *	LunaSec	lunasec.io
Adopter *	Serlo	serlo.org
Adopter *	dyrector.io	dyrector.io
Adopter *	Stackspin	stackspin.net
Adopter *	Amplitude	amplitude.com
Adopter *	Pinniped	pinniped.dev
Adopter *	Pvotal	pvotal.tech

Many thanks to all individual contributors

* Uses one of Ory's major projects in production.

Installation

Head over to the documentation to learn about ways of installing Ory Keto.

Ecosystem

We build Ory on several guiding principles when it comes to our architecture design:

Minimal dependencies
Runs everywhere
Scales without effort
Minimize room for human and network errors

Ory's architecture is designed to run best on a Container Orchestration system such as Kubernetes, CloudFoundry, OpenShift, and similar projects. Binaries are small (5-15MB) and available for all popular processor types (ARM, AMD64, i386) and operating systems (FreeBSD, Linux, macOS, Windows) without system dependencies (Java, Node, Ruby, libxml, ...).

Ory Kratos: Identity and User Infrastructure and Management

Ory Kratos is an API-first Identity and User Management system that is built according to cloud architecture best practices. It implements core use cases that almost every software application needs to deal with: Self-service Login and Registration, Multi-Factor Authentication (MFA/2FA), Account Recovery and Verification, Profile, and Account Management.

Ory Hydra: OAuth2 & OpenID Connect Server

Ory Hydra is an OpenID Certifiedâ¢ OAuth2 and OpenID Connect Provider which easily connects to any existing identity system by writing a tiny "bridge" application. It gives absolute control over the user interface and user experience flows.

Ory Oathkeeper: Identity & Access Proxy

Ory Oathkeeper is a BeyondCorp/Zero Trust Identity & Access Proxy (IAP) with configurable authentication, authorization, and request mutation rules for your web services: Authenticate JWT, Access Tokens, API Keys, mTLS; Check if the contained subject is allowed to perform the request; Encode resulting content into custom headers (X-User-ID), JSON Web Tokens and more!

Ory Keto: Access Control Policies as a Server

Ory Keto is a policy decision point. It uses a set of access control policies, similar to AWS IAM Policies, in order to determine whether a subject (user, application, service, car, ...) is authorized to perform a certain action on a resource.

Security

Disclosing Vulnerabilities

If you think you found a security vulnerability, please refrain from posting it publicly on the forums, the chat, or GitHub. You can find all info for responsible disclosure in our security.txt.

Telemetry

Our services collect summarized, anonymized data which can optionally be turned off. Click here to learn more.

Guide

The Guide is available here.

HTTP API Documentation

The HTTP API is documented here.

Upgrading and Changelog

New releases might introduce breaking changes. To help you identify and incorporate those changes, we document these changes in UPGRADE.md and CHANGELOG.md.

Command Line Documentation

Run keto -h or keto help.

Develop

We encourage all contributions and recommend you read our contribution guidelines.

Dependencies

You need Go 1.19+ and (for the test suites):

Docker and Docker Compose
GNU Make 4.3
NodeJS / npm >= v7

It is possible to develop Ory Keto on Windows, but please be aware that all guides assume a Unix shell like bash or zsh.

Install From Source

make install

Formatting Code

You can format all code using make format. Our CI checks if your code is properly formatted.

Running Tests

There are two types of tests you can run:

Short tests (do not require a SQL database like PostgreSQL)
Regular tests (do require PostgreSQL, MySQL, CockroachDB)

Short Tests

Short tests run fairly quickly. You can either test all of the code at once:

go test -short -tags sqlite ./...

or test just a specific module:

go test -tags sqlite -short ./internal/check/...

Regular Tests

Regular tests require a database set up. Our test suite is able to work with docker directly (using ory/dockertest) but we encourage to use the script instead. Using dockertest can bloat the number of Docker Images on your system and starting them on each run is quite slow. Instead we recommend doing:

source ./scripts/test-resetdb.sh
go test -tags sqlite ./...

End-to-End Tests

The e2e tests are part of the normal go test. To only run the e2e test, use:

source ./scripts/test-resetdb.sh
go test -tags sqlite ./internal/e2e/...

or add the -short tag to only test against sqlite in-memory.

Build Docker

You can build a development Docker Image using:

make docker

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

Top Related Projects

Quick Overview

Pros

Cons

Code Examples

Getting Started

Competitor Comparisons

Pros of SpiceDB

Cons of SpiceDB

Code Comparison

Pros of Casbin

Cons of Casbin

Code Comparison

Pros of OPA

Cons of OPA

Code Comparison

Summary

Pros of Opal

Cons of Opal

Code Comparison

Pros of Warrant

Cons of Warrant

Code Comparison

Pros of Oso

Cons of Oso

Code Comparison

Convert designs to code with AI

README

Chat | Discusssions | Newsletter Guide | API Docs | Code Docs Support this project! Work in Open Source, Ory is hiring!

Get Started

Create a namespace with the Ory Permission Language

Ory Keto on the Ory Network

Ory Network Hybrid Support Plan

Ory Permissions, Keto and the Google's Zanzibar model

Who's Using It?

Installation

Ecosystem

Ory Kratos: Identity and User Infrastructure and Management

Ory Hydra: OAuth2 & OpenID Connect Server

Ory Oathkeeper: Identity & Access Proxy

Ory Keto: Access Control Policies as a Server

Security

Disclosing Vulnerabilities

Telemetry

Guide

HTTP API Documentation

Upgrading and Changelog

Command Line Documentation

Develop

Dependencies

Install From Source

Formatting Code

Running Tests

Short Tests

Regular Tests

End-to-End Tests

Build Docker

Top Related Projects

Convert designs to code with AI

Chat | Discusssions | Newsletter

Guide | API Docs | Code Docs

Support this project!

Work in Open Source, Ory is hiring!