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.:
public class Startup
{
public void Configuration(IAppBuilder app)
{
// read OR write
app.RequireScopes(“read”, “write”);
app.UseWebApi(WebApiConfig.Register());
}
}
or…
public class Startup
{
public void Configuration(IAppBuilder app)
{
// read AND write
app.RequireScopes(“read”);
app.RequireScopes(“write”);
app.UseWebApi(WebApiConfig.Register());
}
}
leastprivilege.com 
Reblogged this on Peter's ruminations and commented:
One sees a lot of America “re-describing” of standard security mechanisms. Presumably one has to be exceptional to call things by different names and try to get away with the presence that one is being original and inventive.
An JWT/SAME audience field is a name-scope – for a world of identity based access control. Its easy to see its 30 year old heritage (in just 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. The security procedure thus enforce 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 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 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.
Hi,
Here I got confused with Scope based validation in OWIN. In your linked post(Scope based Authorization in ASP.NET Web API) it clearly mentioned that you can decorate the scope accessibility in the attribute of each controller or function level. But in your current post when we move same thing into the OWIN, we use that as app.RequireScopes() which handles for the complete app not for the individual controller or action method. How would I implement scope based authorization(as you did it linked post) in OWIN.
Pardon me if my question is too dumb.
You wouldn’t do fine grained scope validation with the OWIN approach. It is rather for checking a global scope – but very early in the pipeline.