What is AuthZen?

OAuth2 and OIDC handle authentication and coarse-grained delegation. They don’t really handle authorization, in the sense of “can this specific user do this specific thing to this specific resource right now?”

That’s the question AuthZen tries to answer in a standard way.

The fine-grained authorization problem

Coarse authorization is easy:

user.role == "admin"  →  allow

But real systems quickly outgrow it. Real questions look like:

• “Can Alice edit the invoice with ID 4271 in the finance workspace?”
• “Can this support agent view customer records for EU customers only?”
• “Can this shared link holder download for the next 24 hours?”

These decisions depend on the user, the action, the resource, the resource attributes, the context (time, location, MFA level), and business rules that often live outside the IAM system.

This is called fine-grained authorization (FGA), or sometimes attribute-based access control (ABAC). For most of the last decade, it has been every team’s homegrown mess.

The interop problem

Every fine-grained authz tool speaks a different dialect:

• One wants YAML files of allow/deny rules.
• Another wants a relationship graph.
• A third wants a policy language with its own DSL.

Change tools, rewrite everything. Run multiple apps, and they often pick different tools and end up unable to talk to each other.

AuthZen is a draft standard from the OpenID Foundation that tries to fix this. It defines a wire-level API for asking and answering authorization questions. Different policy engines can implement the same API, and applications can switch between them, or talk to several at once, without changing a line of code.

What AuthZen looks like

The core idea is a request/response shape:

POST /access/v1/evaluation

{
  "subject": { "id": "alice@example.com" },
  "action":  { "name": "edit" },
  "resource": {
    "type": "invoice",
    "id": "4271",
    "properties": { "workspace": "finance" }
  },
  "context": { "mfa": true }
}

{ "decision": true }

Read it as: “may subject S perform action A on resource R in context C? Yes or no.”

AuthZen does not say how the engine reaches that decision. That’s up to the policy engine, whether OPA, Cerbos, Cedar, OpenFGA, or something else. AuthZen only standardizes the conversation.

Why this matters

If AuthZen takes hold:

• Vendor swap. Try Cedar, decide you want Cerbos, swap the URL. Policies still need migrating, but the apps don’t.
• Multi-engine deploys. Use one engine for relationship-based queries and another for attribute-based rules. Apps speak one wire protocol either way.
• Tooling and gateways. API gateways, service meshes, and IAM platforms can speak AuthZen to any policy engine.

AuthZen vs OAuth2 scopes

A scope is a coarse capability label: “this token can read orders.” Useful as a first filter.

A fine-grained authorization decision asks: “can this user read this order right now?” Scopes can’t express that without exploding into hundreds of named scopes.

The healthy pattern: scopes gate the API at the door (is this token even allowed here?); AuthZen-style decisions happen inside the API (and is this specific action allowed?).

A mental model

OAuth2 scopes are the bouncer at the front door: token has the right sticker, you can come in. AuthZen is the manager inside: “you’re allowed in the building, but this particular room? Let me check the schedule, the booking, and whether you have your badge upgraded today.”

Coarse and fine, working together.

Where to go next

In FerrisKey

FerrisKey issues identity and coarse-grained authorization (scopes, roles, claims), which are the inputs an AuthZen-compatible engine needs. Integration with external policy engines is part of the roadmap; today, applications can use FerrisKey tokens as the subject payload sent to their PDP of choice.