Access control has long stood as a foundational pillar of security architectures. Over time, we’ve seen an evolving and often confusing landscape filled with various “xBACs”. These include RBAC (Role-Based Access Control), ABAC (Attribute-Based Access Control), PBAC (Policy-Based Access Control), ReBAC (Relationship-Based Access Control), and, more recently, TBAC (Token-Based Access Control), a term prominently discussed by Mike Schwartz of Gluu, though it originated earlier.
Each new acronym carries the potential to obscure rather than clarify. This post does not aim to coin another xBAC, but instead offers a structured view to help make sense of how these models interrelate — focusing on three fundamental questions:
- What data drives authorization decisions?
- How is that data gathered and transported?
- How are decisions made?
1. What Data Drives Authorization Decisions?
At the core of any access control model is data — the information used to determine whether access should be granted. While xBAC models highlight different data types, they often complement rather than exclude one another:
- RBAC centers on roles, typically managed via administrative processes. While often perceived as static, RBAC implementations can be dynamic — with roles automatically assigned based on criteria (e.g., "birthright roles"). Some advanced implementations are categorized as A-RBAC (Automated RBAC).
- ABAC introduces attributes — properties of users, resources, actions, or the environment. While it may sound like a superset of RBAC, it’s a different abstraction layer that often coexists with RBAC.
- ReBAC emphasizes relationships — such as organizational hierarchies or social graphs — using the structure of connections between identities and resources.
- PBAC focuses on policies as rules that can use roles, attributes, or relationships to make decisions.
- TBAC, as discussed by Schwartz, uses tokens (e.g., JWTs, SAML assertions) as encapsulated carriers of access-related information. It serves as a vehicle for transporting access data used in other models. used in other models.
These models vary not only in the type of data but also in the source and dynamics: static vs. real-time, coarse-grained vs. fine-grained. The trend is clearly moving toward dynamic, real-time, and context-rich decision-making, aligning with the needs of Zero Trust and adaptive security paradigms.
2. How Is Authorization Information Gathered and Transported?
Another key dimension is how the authorization-relevant data is delivered to the decision point. We can distinguish between:
- Direct Queries – Real-time access to identity sources or resource metadata (e.g., querying a directory service or policy information point, PIP).
- Embedded Tokens – Information is packaged in a token and sent with the access request. This “fire-and-forget” method is stateless and enables performance but lacks adaptability.
- Policy Repositories – Centralized stores contain access policies and may reference static or dynamic data from external PIPs.
While established approaches such as RBAC, ABAC and PBAC focus on direct queries and policy repositories, TBAC belongs in this discussion primarily as a delivery mechanism — it encapsulates data that could stem from any model (RBAC, ABAC, etc.) and is transmitted as part of a token. This highlights an often-overlooked point: Tokens don't decide, they deliver. The decision still aligns with external logic — be it RBAC roles, ABAC evaluations, or PBAC policies.
To add another perspective to the topic, it’s also important to note the rise of signal-based information: Modern systems increasingly incorporate real-time contextual signals, such as device posture, behavioral analytics, or location. Standards such as the Shared Signals Framework (SSF) enable more dynamic, event-driven data exchange — expanding beyond traditional PIPs (such as directories) toward volatile, high-volume, behavior-based inputs. This increases the importance of the medium carrying access-related information, as it must meet advanced authorization requirements.
3. How Are Decisions Made?
The final aspect is the decision-making process. Here, we distinguish between:
- Static Comparisons – Based on predefined entitlements, like access control lists (ACLs).
- Dynamic Policies – Conditions are evaluated at runtime based on current context and signals.
- Hybrid Approaches – A blend of static and dynamic, which is common in enterprise environments.
Today, even static entitlements often reflect policy-based logic. For instance, if a Kerberos token contains group memberships and these are matched to an ACL, the underlying logic ("if group matches, then grant access") is essentially a policy — even if not defined in a policy language like XACML or Rego. This is an example of how traditional implementations deploy advanced Authorization in a much more static environment, and while the mechanism is similar to a real-time decision policy, the foundation for the decision is static information/data.
Looking ahead, we may see AI and machine learning agents making access decisions without predefined policies. This introduces a potential “beyond PBAC” paradigm, where behavioral data and anomaly detection play key roles in adaptive authorization. Rather than checking rules, such systems will evaluate whether behavior is “normal,” shifting the focus from who you are to what you are doing — an evolution also discussed in our recent podcast on dynamic authorization.
Bringing It All Together
Rather than treating each xBAC model as a rival, we should view them as layers or lenses within a broader access control architecture. TBAC is not a standalone model, but a useful construct for packaging and delivering access-related data across systems — supporting RBAC, ABAC, PBAC, and others.
Another aspect is the changing requirements for access models. As lifecycles - and therefore time-to-market - become dramatically shorter, monolithic or static models are no longer sufficient to meet all requirements. As the range of applications, systems, and environments becomes more diverse, organizations benefit from combining different Authorization models as multiple models provide solutions to challenging use cases that may not be adequately addressed (or not addressed at all) by existing approaches.
To navigate the complexity of access control, focus on structuring your approach across these three guiding questions:
- What data drives decisions?
- Roles,
- Attributes,
- Relationships,
- Context,
- Behavior.
2. How is information gathered and transported?
- Queries,
- Tokens,
- Repositories,
- Signals.
3. How are decisions made?
- Static logic,
- Dynamic policies,
- AI-based inference.
With this structure, we gain a more holistic view of the evolving access control landscape. It empowers us to move beyond binary comparisons and see access control for what it truly is: An adaptable framework that can evolve with organizational needs, technological innovations, and security imperatives.
For a deeper dive, Martin Kuppinger’s earlier blog on Adaptive Policy-based Access Management (APAM) explores these developments further, including the increasing role of AI and the challenges of policy lifecycle management.
Access control is changing — but with clarity and structure, we can ensure that our terminology and our technology evolve together.
