One sees a lot of Americans “re-describing” standard security mechanisms. Presumably one has to be exceptional to call things by different names and then get away with the pretense that one has been original and inventive.
An JWT/SAML audience field is a name-scope – for a world of identity based access control. its focussed on crypto and crypto-protected IBAC (in theory of assurance terms). Its easy to see its 30 year old heritage (in just the internet era). A encrypted DES key was “released” to its intended recipient, in such as the PEM protocol (and IRTF PEM’s NSA-designed forerunners). That recipient had a name, bound to the key – and known as a certified key (or certificate). The originator’s security procedure thus enforced an identity-centric “intended recipient” control, authorizing only the party with rights to the name (that party presumably having the requisite keying material, too) to even ATTEMPT to do the decryption necessary to deliver the service (of DES key transport). A trusted computing model was assumed, in which the unauthorized recipient was denied access to the very *service* enforcing intended-recipient controls (vs refusing to decrypt a blob). This concept distinguishes between those recipient complying with their authorizations and attackers who might use non-certified implementations (to bypass the control and thus have access to the protocol blob).
A JWT scope is what folks trained in orange book theory call a permission (vs a right). Permissions are a class of privilege, to alter the state/config of the reference monitor enforcing such as a crypto or security boundary. A scope of “can use camera” alters the windows reference monitor allowing the API at the security boundary to make system-level transport connections between apps and the device, denied by default.
Now, clap for the exceptional and their artistry. Slow hand clap, preferably.
In OAuth2 or OpenID Connect you don’t necessarily always use the audience to partition your token space – the scope concept is also commonly used (see also Vittorio’s post from yesterday). A while ago I created a Web API authorize attribute to do the validation based on scopes (see here).
Since scope-based token validation can become so fundamental to your APIs – I moved the logic to an OWIN/Katana component so all frameworks can benefit from it, e.g.: