keto
The most scalable and customizable permission server on the market. Fix your slow or broken permission system with Google's proven "Zanzibar" approach. Supports ACL, RBAC, and more. Written in Go, cloud native, headless, API-first. Available as a service on Ory Network and for self-hosters.
Top Related Projects
Open Source, Google Zanzibar-inspired database for scalably storing and querying fine-grained authorization data
An authorization library that supports access control models like ACL, RBAC, ABAC in Golang: https://discord.gg/S5UjpzGZjN
Open Policy Agent (OPA) is an open source, general-purpose policy engine.
Policy and data administration, distribution, and real-time updates on top of Policy Agents (OPA, Cedar, ...)
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.
Deprecated: See README
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
Open Source, Google Zanzibar-inspired database for scalably storing and querying fine-grained authorization data
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.
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.
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.
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 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.
Deprecated: See README
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 CopilotREADME
Chat · Discussions · Newsletter · Docs · Try Ory Network · Jobs
Ory Keto is the first and most popular open source implementation of "Zanzibar: Google's Consistent, Global Authorization System". It provides a scalable, performant authorization server for managing permissions at scale.
- What is Ory Keto?
- Deployment options
- Quickstart
- Who is using Ory Keto
- Ecosystem
- Documentation
- Developing Ory Keto
- Security
- Telemetry
What is Ory Keto?
Ory Keto is an open source implementation of "Zanzibar: Google's Consistent, Global Authorization System". It follows cloud architecture best practices and focuses on:
- Scalable permission checks based on the Zanzibar model
- The Ory Permission Language for defining access control policies
- Relationship-based access control (ReBAC)
- Low latency permission checks (sub-10ms)
- Horizontal scaling to billions of relationships
- Consistency and high availability
We recommend starting with the Ory Keto introduction docs to learn more about its architecture, feature set, and how it compares to other systems.
Why Ory Keto
Ory Keto is designed to:
- Implement Google's Zanzibar authorization model at scale
- Provide low-latency permission checks for billions of relationships
- Support the Ory Permission Language for flexible access control
- Work with any identity provider through integration points
- Scale horizontally without effort
- Fit into modern cloud native environments such as Kubernetes and managed platforms
Deployment options
You can run Ory Keto in two main ways:
- As a managed service on the Ory Network
- As a self hosted service under your own control, with or without the Ory Enterprise License
Use Ory Keto on the Ory Network
The Ory Network is the fastest way to use Ory services in production. Ory Permissions is powered by the open source Ory Keto server and is API compatible.
The Ory Network provides:
- Low latency permission checks based on Google's Zanzibar model with built-in support for the Ory Permission Language
- Identity and credential management that scales to billions of users and devices
- Registration, login, and account management flows for passkeys, biometrics, social login, SSO, and multi factor authentication
- OAuth2 and OpenID Connect for single sign on, API access, and machine to machine authorization
- GDPR friendly storage with data locality and compliance in mind
- Web based Ory Console and Ory CLI for administration and operations
- Cloud native APIs compatible with the open source servers
- Fair, usage based pricing
Sign up for a free developer account to get started.
Self-host Ory Keto
You can run Ory Keto yourself for full control over infrastructure, deployment, and customization.
The install guide explains how to:
- Install Keto on Linux, macOS, Windows, and Docker
- Configure databases such as PostgreSQL, MySQL, and CockroachDB
- Deploy to Kubernetes and other orchestration systems
- Build Keto from source
This guide uses the open source distribution to get you started without license requirements. It is a great fit for individuals, researchers, hackers, and companies that want to experiment, prototype, or run unimportant workloads without SLAs. You get the full core engine, and you are free to inspect, extend, and build it from source.
If you run Keto as part of a business-critical system, you should use a commercial agreement to reduce operational and security risk. The Ory Enterprise License (OEL) layers on top of self-hosted Keto and provides:
- Additional enterprise features that are not available in the open source version
- Regular security releases, including CVE patches, with service level agreements
- Support for advanced scaling, multi-tenancy, and complex deployments
- Premium support options with SLAs, direct access to engineers, and onboarding help
- Access to a private Docker registry with frequent and vetted, up-to-date enterprise builds
For guaranteed CVE fixes, current enterprise builds, advanced features, and support in production, you need a valid Ory Enterprise License and access to the Ory Enterprise Docker registry. To learn more, contact the Ory team.
Quickstart
Install the Ory CLI and create a new project to try Ory Permissions.
# Install the Ory CLI if you do not have it yet:
bash <(curl https://raw.githubusercontent.com/ory/meta/master/install.sh) -b . ory
sudo mv ./ory /usr/local/bin/
# Sign in or sign up
ory auth
# Create a new project
ory create project --create-workspace "Ory Open Source" --name "GitHub Quickstart" --use-project
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 -f file://./config.ts
# Create a relationship that grants tom access to a document
echo "Document:secret#read@tom" \
| ory parse relation-tuples --format=json - \
| ory create relation-tuples -
# List all relationships
ory list relation-tuples
# Check if tom can read the document
ory check permission Document:secret read tom
Who is using Ory Keto
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 50.000 members and is growing. The Ory stack protects 7.000.000.000+ API requests every day across thousands of companies. 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!
| Name | Logo | Website | Case Study |
|---|---|---|---|
| OpenAI |
|
openai.com | OpenAI Case Study |
| Fandom |
|
fandom.com | Fandom Case Study |
| Lumin |
|
luminpdf.com | Lumin Case Study |
| Sencrop |
|
sencrop.com | Sencrop Case Study |
| OSINT Industries |
|
osint.industries | OSINT Industries Case Study |
| HGV |
|
hgv.it | HGV Case Study |
| Maxroll |
|
maxroll.gg | Maxroll Case Study |
| Zezam |
|
zezam.io | Zezam Case Study |
| T.RowePrice |
|
troweprice.com | |
| Mistral |
|
mistral.ai | |
| Axel Springer |
|
axelspringer.com | |
| Hemnet |
|
hemnet.se | |
| Cisco |
|
cisco.com | |
| Presidencia de la República Dominicana |
|
presidencia.gob.do | |
| Moonpig |
|
moonpig.com | |
| Booster |
|
choosebooster.com | |
| Zaptec |
|
zaptec.com | |
| Klarna |
|
klarna.com | |
| Raspberry PI Foundation |
|
raspberrypi.org | |
| Tulip |
|
tulip.com | |
| Hootsuite |
|
hootsuite.com | |
| Segment |
|
segment.com | |
| Arduino |
|
arduino.cc | |
| Sainsbury's |
|
sainsburys.co.uk | |
| Contraste |
|
contraste.com | |
| inMusic |
|
inmusicbrands.com | |
| Buhta |
|
buhta.com | |
| Amplitude |
|
amplitude.com | |
Many thanks to all individual contributors
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.
Documentation
The full Ory Keto documentation is available at www.ory.sh/docs/keto, including:
For upgrading and changelogs, check UPGRADE.md and CHANGELOG.md.
Developing Ory Keto
See DEVELOP.md for information on:
- Contribution guidelines
- Prerequisites
- Install from source
- Running tests
- Build Docker image
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 that can optionally be turned off. Click here to learn more.
Top Related Projects
Open Source, Google Zanzibar-inspired database for scalably storing and querying fine-grained authorization data
An authorization library that supports access control models like ACL, RBAC, ABAC in Golang: https://discord.gg/S5UjpzGZjN
Open Policy Agent (OPA) is an open source, general-purpose policy engine.
Policy and data administration, distribution, and real-time updates on top of Policy Agents (OPA, Cedar, ...)
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.
Deprecated: See README
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