I am a fan of separating authorization logic and business logic – that’s why I favour the claims-based authorization manager approach. That’s also why I wrote the ClaimsAuthorize filter.
If you don’t want to go down the route of a full fledged authorization manager but use the scopes concept from OAuth2 (see here), here’s a simplified approach:
public class IdentityController : ApiController
{
/// <summary>
/// Returns the claims of the current principal
/// </summary>
[Scope(“read”)]
public IEnumerable<ViewClaim> Get()
{
var principal = Request.GetClaimsPrincipal();
return ViewClaims.GetAll(principal);
}
/// <summary>
/// Update identity data
/// </summary>
[Scope(“write”, “update”]
public void Put()
{
}
}
The [Scope] attribute is an authorization filter that simply checks for the existence of scope claims with the specified value.
That’s a really simple approach to coarse grained authorization that goes well together with access tokens coming from an (our) authorization server. You can of course mix that with an authorization manager if you like.
The attribute is part of IdentityModel. The sample above can be found here.
leastprivilege.com 
Pingback: Hawk Support in Thinktecture IdentityModel v3.3 | www.leastprivilege.com
Pingback: OAuth2 and OpenID Connect Scope Validation for OWIN/Katana | leastprivilege.com
Doesn’t this Scope based authorization go against your earlier preachings about permission per resource? Are we back to just general “read” or “write”? How do we properly secure the different parts of the systems using these scopes?
Scopes are for clients, resource/actions for users.
That meant absolutely nothing to me :-)
I guess I just found out what I will be googling this weekend…
Users are the carbon-based lifeforms in your system, client the silicon-based ones.
https://vimeo.com/user22258446/review/79095048/9a4d62f61c
If I want to protect WEB Api with OAuth, what is the best practice for mapping/naming the scopes?
I read OAuth and Open ID standards, couple of times, but it does not help, so far :-)
Lets say we have two Web API services and Identity Server 3. We want to protect those services with OAuth.
So in each service we have some controllers and in each controller we have some methods that clients will call. So, on every call, we need to check if client is authorized to access specific method. Some client will be authorized for some method of the same controller, for other methods it will not.
For WCF its easy, we implement very nice claim based security, and relate the user with claims that includes “roles” related claims, usernametokenvalidator, check for claims through attribute, and so on. This is very easy.
How we do this in OAUTH?
After OAuth dance (depending on the flow), client will get token at the end of dance, and it will use that token to access the service. The token will contain scopes.
Do we perform check for specific scopes when some WEB method is called? Or we do this is another way?
If we use scopes for this, than How the service knows that the token is related to that service and not to another one?
Thanks Dominick
Think of scope as the equivalent to audience or appliesTo in WCF. Nothing changes related to user authorization.