Scope based Authorization in ASP.NET Web API

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.

This entry was posted in AuthorizationServer, OAuth, WebAPI. Bookmark the permalink.

8 Responses to Scope based Authorization in ASP.NET Web API

  1. Pingback: Hawk Support in Thinktecture IdentityModel v3.3 | www.leastprivilege.com

  2. Pingback: OAuth2 and OpenID Connect Scope Validation for OWIN/Katana | leastprivilege.com

  3. 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?

  4. Users are the carbon-based lifeforms in your system, client the silicon-based ones.
    https://vimeo.com/user22258446/review/79095048/9a4d62f61c

  5. iAuth says:

    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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s