Part Two: TBAC or Token Based Access Control -- how is it different?

Last week, I posted an article Introducing Token-Based Access Control (TBAC). This article seeks to go a little deeper, to flush out what TBAC actually is!

First we should start by defining "token". In this article, a token is a JWT that could be an assertion issued by an identity provider, a software statement issued by a federation, or an attestation issued by a device or platform. In other words, “token” is a catch-all for a package of data you can trust based on cryptographic verification techniques.

There are many Access Control ("AC") systems out there, and luckily, they are not mutually exclusive. In fact, many access control models overlap or extend others. The sweet spot for TBAC is access control for an embedded or local PDP. To summarize some of the more relevant ACs for enterprise IAM:

RBAC focuses on roles assigned within an organization.

ABAC focuses on attributes of the subject, resource, and environment.

ReBAC focuses on the relationship between the subject and the resource

PBAC is more of an overarching meta-framework--RBAC, ABAC, ReBAC are the tools, while PBAC is a toolbox that gathers them in one convenient, accessible container.

TBAC embeds the subjects' identity, claims and trusted contextual data within a token, allowing stateless and decentralized access control.

Because tokens are signed, TBAC enables enterprises to make additional policies around "Who issued this token?” (contextual provenance), "Is the assertion still valid?" (time-bound, revocation status, audience-specific, proof of possession), and "Does the token carry enough information to allow an autonomous decision."

TBAC also reduces the cognitive load placed on developers to understand the nuanced differences between various token types like OAuth tokens (e.g. access token, software statement), OpenID Connect tokens (e.g. id_token, Userinfo token), and other specialized tokens that are soon emerging–WIMSE tokens and OAuth transaction tokens for example. TBAC removes the need for developers to differentiate between token types and to juggle multiple SDKs for token parsing and validation.?

Another advantage of TBAC for developers is that it relieves the need to explicitly map the? subject references. Tokens may convey multiple subjects implicitly. For example, an id_token contains both a subject (person), an audience (workload), and an issuer (organization). So while an RBAC or ABAC request are atomic with regard to a subject, a TBAC request might imply multiple authorizations–is this piece of software, acting on behalf of this person, authorized to call a certain API endpoint??

Implicit subjects are one of the biggest differences of TBAC versus?ABAC, RBAC, and ReBAC. To the developer, in place of a subject, a TBAC request includes a bundle of tokens. A TBAC response may involve combining several distinct ABAC or RBAC authorization requests with boolean operators. For example, only allow access if the Person has a valid subscription, AND the software is a mobile application published by our company on the Google Play Store.?

Of course, TBAC is critically dependent on issuer-side policies to ensure the right information is available for those decisions. It’s a garbage-in / garbage out problem–if the JWTs themselves are wrong or missing information, all bets are off.? Organizations that are great at customizing tokens have an advantage in creatling elegant authorization solutions.

Hopefully that gives you a better understanding of where TBAC differs from other access control systems. More flushing out will happen in the near future!?