Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Find Your AuthZEN

Find Your AuthZEN

Avatar for Niko Köbler

Niko Köbler

September 20, 2026

More Decks by Niko Köbler

Other Decks in Programming

Transcript

  1. Find Your AuthZEN xBAC Authorization in Java @RolesAllowed({ "READER", "EDITOR"

    }) public void doSomething() { } @PreAuthorize("hasAnyRole('READER', 'EDITOR')") public void doSomething() { } = = . . . . . . @PreAuthorize("hasAnyRole('EDITOR','ADMIN') and #tenantId authentication.token.claims['tenant']")
  2. fl Find Your AuthZEN RBAC Role Based Access Control named

    roles assigned to users implicit set of permissions coarse-grained control at & uniform single tenant / no hierarchy no per-resource control no "What can this user see?" across large number of objects
  3. Find Your AuthZEN ABAC Attribute Based Access Control decides based

    on attributes of the principal, resource & request (role = engineer AND region = EU) good if stateless (everything is provided in request), needs explicit attribute lookups otherwise rules involve comparisons (<,>,=,not,in, ) policies versioned / policies as con g/code, not data . . fi common engines: OPA, Cedar, AWS IAM
  4. fi Find Your AuthZEN ReBAC Relation Based Access Control ne-grained

    authorization relation between user and resource (direct or concentric) stored relationship tuples (policy is data) one tuple per resource / per share similar to / kind-of ACLs based on Zanzibar paper from Google common engines: OpenFGA, SpiceDB, Ory Keto
  5. Find Your AuthZEN Policy vs. Relationship • Policy engines evaluate

    policies expressed in a DSL • Relationship engines (all in the Zanzibar tradition) store • Decisions are (mostly) attribute driven (claims, • Decisions depend on relationships that change at write against input data passed on each request. The engine is stateless; you supply the data. resource, metadata, request context, …). • All the data needed for the decision is in hand at request time (claims in token, elds on the resource, …), so the engine doesn't need to fetch anything to answer. relationship tuples in a database and answer queries against a stored graph. The engine is the database. time (group membership, document sharing, folder hierarchy, multi-tenant ownership). • The data behind the decision is too large or too dynamic to ship on every request (millions of memberships, deeply nested hierarchies) so the engine needs to own the store. • You need reverse queries: "list every resource this user can read" which inherently require a stored graph. • Permissions are per-resource and per-user, not just per- fi attribute.
  6. Find Your AuthZEN Zanzibar Paper by Google, 2019 Describing the

    authorization system used by Google Drive, YouTube, Calendar, Cloud, and most other Google products. It is the source of the design pattern relationship engines (OpenFGA, SpiceDB, Ory Keto, …) implement. A globally distributed database of relationship tuples that answers two questions in milliseconds at Google scale: 1. "Is user U related to object O via relation R?" (check) 2. "What objects of type T is user U related to via relation R?" (reverse index / list-objects) Two ideas make it work: 1. A typed schema de ning types and the relations between them. 2. A tuple store indexed for both forward and reverse queries, with a consistency mechanism (Zookies) fi that lets clients tie permission checks to the version of the data they read.
  7. Find Your AuthZEN AuthZ Engines Chances & Challenges separate /

    additional system to maintain (run, observe, patch, backup, …) application does not (need to) know the decision path (developers can focus on business logic) additional latency (for each request) caching vs. freshness same logic in all applications & services (if it changes, it changes everywhere at the same time) each engine has its own api
  8. Find Your AuthZEN OpenID AuthZEN WG Scope & Objectives "Be

    the OAuth2/OIDC/SAML of authZ" by: 1. Increase interoperability between existing standards and approaches to authorization 2. De ne and formalize interoperable communication patterns between major authZ components (P*P) 3. Establish and promote the use of externalized authZ as the preferred fi pattern.
  9. Find Your AuthZEN P*P Architecture 1. View Record #123 PEP

    2. Can user view record #123? 3. Evaluate Policies Manage Policies PAP PDP 6. View Record #123 5. Permit, user can view record #123 4. Retrieve additional attributes & information PIP
  10. Find Your AuthZEN AuthZEN API Version 1.0, January 2026 The

    Authorization API enables Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs) to communicate authorization requests and decisions to each other without requiring knowledge of each other's inner workings. The Authorization API is served by the PDP and is called by the PEP. The Authorization API includes evaluation endpoints, which provide speci c access decisions, and search endpoints fi for discovering permissible subjects, resources, or actions.
  11. Find Your AuthZEN Subject Context Resource Action AuthZEN Decision Access

    Evaluation(s) API Policy Decision Point Metadata Search APIs /.well-known/authzen-configuration Transport HTTPS JSON Binding
  12. Find Your AuthZEN AuthZEN Policy Decision Point Metadata { "policy_decision_point":

    "https: pdp.example.com", "access_evaluation_endpoint": "https: pdp.example.com/access/v1/evaluation", "access_evaluations_endpoint": "https: pdp.example.com/access/v1/evaluations", "search_subject_endpoint": "https: pdp.example.com/access/v1/search/subject", "search_action_endpoint": "https: pdp.example.com/access/v1/search/action", "search_resource_endpoint": "https: pdp.example.com/access/v1/search/resource" / / / / / / / / / / / / }
  13. Find Your AuthZEN AuthZEN Access Evaluation { "subject": { {

    "type": "user", "decision": true, "id": "[email protected]" "context": { }, "reason": { "resource": { "403": "Insufficient privileges." "type": "account", }, {"metadata": { "id": "123" }, "response_time": 60, "decision": true "response_time_unit": "ms" "action": { } "name": "can_read", }, "properties": { "environment": { "method": "GET" "ip": "10.10.0.1", } "datetime": "2026-09-22T11:12:24+02:00", }, "os": "ubuntu24.04.2LTS-AMDx64" "context": { } "time": "2026-09-22T11:12:23+02:00" } } } }
  14. Find Your AuthZEN Links • AuthZEN Working Group: https://openid.net/wg/authzen/ •

    AuthZEN Authorization API 1.0: https://openid.net/specs/authorization-api-1_0.html • Zanzibar: Google’s Consistent, Global Authorization System: https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/ • Zanzibar Academy: https://www.zanzibar.academy/ • OpenFGA: https://openfga.dev/ • SpiceDB: https://authzed.com/spicedb • Ory Keto: https://www.ory.com/keto • Open Policy Agent: https://www.openpolicyagent.org/ • Cedar: https://cedarpolicy.com/