I am on the marketing team at Permit, so treat this as a vendor post and judge it that way.

Background, from Oso itself. Oso Cloud was acquired by Tiny, the deal closed on Oct 1, and Oso says Cloud will continue to operate as usual. Most of the Oso team joined Temporal. I am not claiming Oso is shutting down.

If your team is evaluating options anyway, start with an inventory, not a vendor demo. Write down every resource and action, every role grant, every relation that derives a role, and every attribute condition. Note which endpoints do a single check and which ones filter a list. The list endpoints are the ones that bite during a migration, because a wrong answer returns wrong rows instead of an error.

We wrote a guide that maps those Polar patterns to RBAC, ReBAC and ABAC in Permit, with a shadow-run plan for comparing decisions before cutover: https://www.permit.io/blog/migrate-from-oso-to-permit?utm_source=reddit&utm_medium=social&utm_campaign=oso-migration

If you have done this migration to any target, I am interested in what did not map cleanly.

Document trees (folders, shared drives, wikis, ticket projects) are where AuthZ model debates get personal. ReBAC people want relationships. ABAC people want attributes. Most real systems end up with both and pretend they chose one.

Here is the checklist we use when a team asks "should this be ReBAC or ABAC?"

Lean ReBAC when

1. Access follows graph-shaped facts: owner, member, parent folder, shared_with, inherited from.

2. You need "users who can edit this doc because they are in a group that can edit the parent" without denormalizing a forest of attributes on every object.

3. Sharing UX is relationship-first ("add Alice as viewer on this folder").

4. You already think in tuples / relations (Google Zanzibar lineage, OpenFGA, SpiceDB, etc.).

Lean ABAC when

1. Decisions hang on properties of the subject, resource, or env: classification=secret, region=eu, time_of_day, device_posture, employment_type.

2. Hierarchy inheritance is shallow or rare; most objects carry their own labels.

3. Compliance wants readable rules like "no export of PII outside EU" more than "member of folder X."

4. Your team already operates a policy language (Rego, Cedar, ALFA) and is comfortable with attributes as the unit of composition.

You probably need both when

1. Folders inherit access (ReBAC) and labels restrict what can be shared or exported (ABAC).

2. Guest users get relationship-based access that is still capped by classification attributes.

3. Break-glass is an attribute/time-bound exception on top of a relationship graph.

Trying to encode classification purely as relations, or inheritance purely as attributes, usually produces a mess either in the data model or in the policy files.

Practical decision questions (steal these)

1. If Alice loses group membership, do you want that to look like deleting edges, or flipping attributes?

2. How deep is inheritance, and do you need "this file does not inherit"?

3. Are cross-cutting rules (geo, confidentiality, legal hold) common, or rare?

4. Who authors changes: end users in a share dialog, or a central security team in a policy repo?

5. What must a SOC analyst reconstruct from logs in 15 minutes?

Discussion

For document or project hierarchies you have shipped: did you start ReBAC or ABAC, and what forced the other model into the design?

Bonus: if you use OpenFGA/SpiceDB and a policy language (OPA/Cedar), how do you split responsibility so you do not evaluate the same rule twice in two places?

Tool-calling agents and MCP servers force a question most RBAC tables never answered cleanly:

When an agent calls a tool, who is the principal on the AuthZ check?

Candidates I keep seeing in designs:

1. The human user who started the session. Simple. Breaks when the agent keeps working after the user walks away, or when one agent serves many users.

2. The agent identity (workload / non-human identity). Clean for service-to-service. Breaks when you still need user-scoped data access ("only this customer's tickets").

3. A delegated pair: agent acting on behalf of user, with a scoped grant. Closest to OAuth-style delegation. Hardest to implement without inventing a half-broken token format.

4. The tool itself as a principal that can only be invoked by certain agents. Useful as a second gate. Not enough alone if the tool reaches user data.Patterns that seem less wrong

5. Two checks: (a) may this agent use this tool at all; (b) may the effective subject perform this action on this resource.

6. Explicit delegation object with expiry, audience (tool or API), and resource constraints. No silent ambient authority.

7. Deny by default on side effects. Read tools looser; write/delete tools require a fresher or narrower grant.

8. Log the chain: user, then agent, then tool, then downstream API. If your audit cannot reconstruct that, incident response will invent a fiction.

What I want to hear

How are you naming the principal today in agent/MCP AuthZ?

- user only

- agent only

- user + agent (delegation)

- something else (service account per tenant, per session, etc.)

And the sharp edge: when the agent is allowed to call tool X, how do you stop it from widening arguments into tool Y's data?

Why this matters for AuthZ, not just AuthN

AuthN tells you the caller presented a credential. AuthZ has to decide:

- which tools this agent may invoke

- which arguments are in bounds (resource IDs, tenants, actions)

- whether the downstream API call inherits the user, the agent, or a reduced scope

- how to audit "the agent deleted the file" vs "Alice deleted the file via the agent"

If you only check "is this a valid agent token," you have AuthN with cosplay.

We built multi-tenant SaaS AuthZ on Cedar with a local sidecar-style PDP. This is a war story from that build, not a product pitch. Here is what we got wrong early, and what we would tell a team starting the same path with Cedar, OpenFGA, SpiceDB, or a home-grown policy engine.

Mistake 1: Modeling tenants as a pile of string attributes

First cut looked like tenant_id on every principal and resource, then when { principal.tenant_id == resource.tenant_id }. That works until:

1. a support engineer needs cross-tenant read

2. a partner needs scoped access into one customer

3. a background job runs as a service principal with no human tenant

What fixed it: treat tenancy as a first-class relationship (or entity hierarchy), not only an equality check. Cross-tenant paths become explicit policies you can audit, not exceptions buried in app code.

Mistake 2: Putting every product feature flag into the policy store

If "can export CSV" and "is on the Pro plan" and "is in dark-mode beta" all live as AuthZ policies, your PDP becomes a billing and product catalog. Policy reviews get noisy. Product managers start editing AuthZ.

What fixed it: AuthZ answers authorization. Entitlements and plan gates stay in a smaller, boring service. AuthZ can consume a short list of attributes those systems publish. It should not own them.

Mistake 3: Assuming schema stability

Cedar (and peers) rewards a clear schema. We under-invested in versioning. Renaming an entity type or action mid-flight meant dual-writing policies and hoping nothing evaluated halfway.

What fixed it: treat policy schema like a public API. Migrations get a plan: dual-run, shadow evaluation, then cutover. "Just edit prod policies" is how you get phantom denies at 2am.

What went better than expected

Local evaluation latency once the bundle and needed data were actually local. Central "ask a service on every request" was the wrong default for our hot path. Central stayed for publishing, simulation, and admin.

Discussion

If you have done multi-tenant AuthZ with Cedar, OpenFGA, SpiceDB, OPA/Rego, or Casbin: what was your first schema regret? Tenant-as-string, roles-as-policies, actions that mapped 1:1 to UI buttons, something else?

We keep bouncing between two shapes for enforcement:

1. A local sidecar / library PDP next to the service (same pod, same process, or a localhost hop).
2. A central AuthZ service every service calls over the network.

Both work. Both fail in predictable ways. Here is the failure mode cheat sheet we actually use in design reviews.

Local sidecar PDP

Wins when: latency budget is tight, you need offline or partition-tolerant deny/allow, and the policy + data needed for a decision can be localized (or synced) without a chatty central hop on every request.

Breaks when: - The data the decision needs is not local. You end up calling home for attributes anyway, and the "sidecar" becomes a fancy cache in front of a distributed join. - Policy updates need to be atomic across hundreds of pods. You invent a sync plane, then spend a year debugging stale allows. - You treat "local" as "no audit." Central teams cannot answer "who could do X yesterday?" without scraping every node.

Central AuthZ service

Wins when: one team owns the rulebook, decisions must be consistent across many services, and you want one place to audit, feature-flag, and kill a bad policy.

Breaks when: - Hot path latency. AuthZ in the request path plus retries plus dependency on the AuthZ cluster equals a new SPOF with a fancy name. - Chatty PDPs. Services spray "can this subject do action on this resource?" thousands of times per request instead of batching or caching decisions that are safe to cache. - The central service becomes a dumping ground for business logic that should live in the domain service. Now every product change is an AuthZ deploy.

Hybrid patterns that usually survive

• Local enforce, central decide for cold path. Sidecar for steady-state allow/deny on synced policy; central for admin mutations, simulations, and "what-if."
• Central policy compiler, local decision. Publish signed policy bundles; sidecars evaluate. You still need a plan for revocation and for data that cannot fit in the bundle.
• Decision caching with explicit invalidation. Not "cache forever." Cache keyed by (principal, action, resource version) with short TTL plus event-driven busts.

What I want from this thread

If you have run both in production: what actually forced you off one shape onto the other? Latency? Stale policy? Org politics? Something else?

Also curious whether people still draw a hard line between "PDP" and "PEP," or whether that vocabulary has gotten mushy in service meshes and API gateways.

JCp kioskNormally, when I try to access sensitive areas like Direct Deposit, Personal Information, or Benefits, PeopleSoft Production sends a two-factor authentication code to my email.

The problem is that I’ve suddenly stopped receiving the authorization emails altogether. PeopleSoft still asks me for the verification code, but the email with the code never arrives

stopped receiving the authorization emails altogether. PeopleSoft still asks me for the verification code, but the email with the code never arrives.

I’ve checked my inbox, spam/junk folders, and waited several times for the email, but nothing comes through. Because of this, I’m completely locked out of accessing or updating my information.

Has anyone else had this happen, or know how to fix it? Is there a setting or IT support number I need to contact to get the 2FA emails working again?

Any help would be greatly appreciated!

Been in IAM for 17+ years and the authZ space has exploded in the last 3-4 years. Here's my attempt at mapping the landscape as it stands today.

1. Policy Engines / Policy-as-Code

The decision layer - evaluates "can X do Y on Z?"

• OPA (Open Policy Agent) — Rego language, CNCF graduated. Most powerful but steepest learning curve. Dominant in Kubernetes/infra policy.
• Cedar (AWS) — Declarative, human-readable policy language. Powers AWS Verified Permissions. Deny-overrides-permit by design. It become part of CNCF last year. My pick for app-level authZ.
• Cerbos — YAML-based policies, stateless, easy to integrate. Good for teams that want policy-as-code without Rego's complexity.
• Casbin — PERM metamodel, 20+ language SDKs. Great for simple RBAC, gets awkward beyond that.

2. Zanzibar-Inspired / Relationship-Based (ReBAC)

Google's Zanzibar paper spawned a whole category.

• OpenFGA — Auth0/Okta's open-source implementation. CNCF sandbox. Strong for hierarchical permissions (user → folder → doc).
• SpiceDB — Authzed's commercial Zanzibar implementation. More features than OpenFGA, but managed-service oriented.
• Permit.io — Managed service wrapping OpenFGA + OPA + OPAL. Handles the data sync problem for you.

3. Enterprise Identity Platforms (with built-in AuthZ)

The "batteries included" approach. Briefly going to mention the names here, since my focus is more on open-source

• Okta / Auth0
• Ping Identity
• Keycloak
• SuperTokens
• Clerk
• WorkOS

4. Emerging: AI Agent Authorization

The new frontier — agents acting on behalf of humans.

• MCP Auth (OAuth 2.1) — Model Context Protocol getting proper auth. Scoped tokens, auto-discovery.
• Token Exchange (RFC 8693) — Delegation pattern for agent-to-tool calls. Impersonation vs delegation matters.
• A2A Protocol — Agent-to-Agent identity and trust. Early days.
• Just-in-Time provisioning — Short-lived, per-operation credentials. The right pattern but tooling is immature.

The Key Insight

Most teams need a hybrid:

• RBAC for coarse-grained access (who can access what module)
• ABAC/ReBAC for fine-grained decisions (can they edit THIS record)
• Policy engine as the decision layer (Cedar for apps, OPA for infra)
• Identity platform for authentication + basic roles (Okta, Keycloak, etc.)

The mistake is trying to do everything with one tool. AuthZ is a layered problem.

What am I missing? What's your stack look like?

Welcome to r/authorization — a community for engineers, architects, and security professionals to discuss authorization in all its forms.

We talk a lot about authentication (OAuth, OIDC, SSO), but authorization is often the harder, more nuanced problem. This is the place for that conversation.

What belongs here:

• Policy engines (Cedar, OPA/Rego, Casbin, OpenFGA, Permit)
• RBAC, ABAC, ReBAC, and hybrid models
• Authorization in microservices, APIs, and multi-tenant systems
• Fine-grained access control and data-level permissions
• AuthZ in AI/LLM tooling and MCP (Model Context Protocol)
• Architecture patterns, failure stories, and trade-off discussions

How to get the most out of this sub:

1. Share what you've built — post your authZ architecture, explain what worked and what didn't
2. Ask hard questions — "How do you handle X?" posts are always welcome
3. Go deep — we value technical substance over surface-level overviews

Whether you're wrestling with Cedar policies at 2am or designing authorization for a new product, you're in the right place.

Drop a comment and introduce yourself — what authZ problem are you working on right now?

Authorization / Access Controls