Convert Figma logo to code with AI

ory logoketo

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.

5,242
377
5,242
59

Top Related Projects

6,347

Open Source, Google Zanzibar-inspired database for scalably storing and querying fine-grained authorization data

19,698

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

10,829

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

5,416

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

1,323

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.

3,497

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

  1. 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")
}
  1. 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()
  1. 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

  1. Install Ory Keto:

    docker pull oryd/keto:v0.11.1
    
  2. Run Keto:

    docker run -p 4466:4466 -p 4467:4467 -e DSN=memory oryd/keto:v0.11.1 serve
    
  3. Install the Go client:

    go get github.com/ory/keto-client-go
    
  4. 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

6,347

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.

19,698

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.

10,829

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.

5,416

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.

1,323

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.

3,497

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 Figma logo designs to code with AI

Visual Copilot

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

Try Visual Copilot

README

Ory Keto - Open Source & Cloud Native Access Control Server

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?

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 openai.com OpenAI Case Study
Fandom Fandom fandom.com Fandom Case Study
Lumin Lumin luminpdf.com Lumin Case Study
Sencrop Sencrop sencrop.com Sencrop Case Study
OSINT Industries OSINT Industries osint.industries OSINT Industries Case Study
HGV HGV hgv.it HGV Case Study
Maxroll Maxroll maxroll.gg Maxroll Case Study
Zezam Zezam zezam.io Zezam Case Study
T.RowePrice T.RowePrice troweprice.com
Mistral Mistral mistral.ai
Axel Springer Axel Springer axelspringer.com
Hemnet Hemnet hemnet.se
Cisco Cisco cisco.com
Presidencia de la República Dominicana Presidencia de la República Dominicana presidencia.gob.do
Moonpig Moonpig moonpig.com
Booster Booster choosebooster.com
Zaptec Zaptec zaptec.com
Klarna Klarna klarna.com
Raspberry PI Foundation Raspberry PI Foundation raspberrypi.org
Tulip Tulip Retail tulip.com
Hootsuite Hootsuite hootsuite.com
Segment Segment segment.com
Arduino Arduino arduino.cc
Sainsbury's Sainsbury's sainsburys.co.uk
Contraste Contraste contraste.com
inMusic InMusic inmusicbrands.com
Buhta Buhta buhta.com
Amplitude amplitude.com amplitude.com
TIER IV Kyma Project Serlo Padis
Cloudbear Security Onion Solutions Factly All My Funds
Nortal OrderMyGear R2Devops Paralus
dyrector.io pinniped.dev pvotal.tech

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.