How do I authorize access to ServiceStack resources using OAuth2 access tokens via DotNetOpenAuth?

Question

I've created an OAuth2 authorization server using DotNetOpenAuth, which is working fine - I'm using the resource owner password flow, and successfully exchanging user credentials for an access token.

I now want to use that access token to retrieve data from secure endpoints in a ServiceStack API, and I can't work out how to do so. I've examined the Facebook, Google, etc. providers included with ServiceStack but it's not clear whether I should be following the same pattern or not.

What I'm trying to achieve (I think!) is

1. OAuth client (my app) asks resource owner ('Catherine Smith') for credentials
2. Client submits request to authorization server, receives an access token
3. Client requests a secure resource from the resource server (GET /users/csmith/photos)
   • The access token is included in an HTTP header, e.g. Authorization: Bearer 1234abcd...
4. The resource server decrypts the access token to verify the identity of the resource owner
5. The resource server checks that the resource owner has access to the requested resource
6. The resource server returns the resource to the client

Steps 1 and 2 are working, but I can't work out how to integrate the DotNetOpenAuth resource server code with the ServiceStack authorization framework.

Is there an example somewhere of how I would achieve this? I've found a similar StackOverflow post at How to build secured api using ServiceStack as resource server with OAuth2.0? but it isn't a complete solution and doesn't seem to use the ServiceStack authorization provider model.

EDIT: A little more detail. There's two different web apps in play here. One is the authentication/authorisation server - this doesn't host any customer data (i.e. no data API), but exposes the /oauth/token method that will accept a username/password and return an OAuth2 access token and refresh token, and also provides token-refresh capability. This is built on ASP.NET MVC because it's almost identical to the AuthorizationServer sample included with DotNetOpenAuth. This might be replaced later, but for now it's ASP.NET MVC.

For the actual data API, I'm using ServiceStack because I find it much better than WebAPI or MVC for exposing ReSTful data services.

So in the following example:

the Client is a desktop application running on a user's local machine, the Auth server is ASP.NET MVC + DotNetOpenAuth, and the Resource server is ServiceStack

The particular snippet of DotNetOpenAuth code that's required is:

// scopes is the specific OAuth2 scope associated with the current API call.
var scopes = new string[] { "some_scope", "some_other_scope" }

var analyzer = new StandardAccessTokenAnalyzer(authServerPublicKey, resourceServerPrivateKey);
var resourceServer = new DotNetOpenAuth.OAuth2.ResourceServer(analyzer);
var wrappedRequest = System.Web.HttpRequestWrapper(HttpContext.Current.Request);
var principal = resourceServer.GetPrincipal(wrappedRequest, scopes);

if (principal != null) {
    // We've verified that the OAuth2 access token grants this principal
    // access to the requested scope.
}

So, assuming I'm on the right track, what I need to do is to run that code somewhere in the ServiceStack request pipeline, to verify that the Authorization header in the API request represents a valid principal who has granted access to the requested scope.

I'm starting to think the most logical place to implement this is in a custom attribute that I use to decorate my ServiceStack service implementations:

using ServiceStack.ServiceInterface;
using SpotAuth.Common.ServiceModel;

namespace SpotAuth.ResourceServer.Services {
    [RequireScope("hello")]
    public class HelloService : Service {
        public object Any(Hello request) {
            return new HelloResponse { Result = "Hello, " + request.Name };
        }
    }
}

This approach would also allow specifying the scope(s) required for each service method. However, that seems to run rather contrary to the 'pluggable' principle behind OAuth2, and to the extensibility hooks built in to ServiceStack's AuthProvider model.

In other words - I'm worried I'm banging in a nail with a shoe because I can't find a hammer...

Jegger

Does OpenId Auth Providers for ServiceStack fit you needs? Here is documentation - OpenId 2.0 Authentication Support – Eamon

This package might provide a useful code example: Configure an ServiceStack backend to accept OAuth2 Bearer tokens – Medea

As for authorization, the recommended reading for built in roles and permission support is here: #12095594 and here's a more complete example of adding a custom OAuth provider than the one you linked: davetimmins.wordpress.com/2013/04/12/… -- you're right. I don't see any examples that completely integrate the two, OAuth authentication together with roles and permissions authorization. – Medea

Back again. What role does ServiceStack play in your implementation? I had been thinking that SS would provide the resource, and needed to confirm authorization via the resource server. But your outline above, has the resource server returning the resource to the client. Which leads to the question - what do you need service stack for, in that scenario? And, if you're using ServiceStack to pass the resource to the client, why do you need a DNOA resource server? Is SS providing a facade to the client, obscuring the details of resource and authentication server implementation? – Medea

Answer 1

Update On further reflection, your initial thought, to create a RequiredScope attribute would be a cleaner way to go. Adding it to the ServiceStack pipeline is as easy as adding the IHasRequestFilter interface, implementing a custom request filter, as documented here: https://github.com/ServiceStack/ServiceStack/wiki/Filter-attributes

public class RequireScopeAttribute : Attribute, IHasRequestFilter {
  public void RequireScope(IHttpRequest req, IHttpResponse res, object requestDto)
  {
      //This code is executed before the service
      //Close the request if user lacks required scope
  }

  ...
}

Then decorate your DTO's or Services as you've outlined:

using ServiceStack.ServiceInterface;
using SpotAuth.Common.ServiceModel;

namespace SpotAuth.ResourceServer.Services {
    [RequireScope("hello")]
    public class HelloService : Service {
        public object Any(Hello request) {
            return new HelloResponse { Result = "Hello, " + request.Name };
        }
    }
}   

Your RequireScope custom filter would be almost identical to ServiceStack's RequiredRoleAttribute implementation., so use it as a starting point to code from.

Alternately, you could map scope to permission. Then decorate your DTO or service accordingly (see SS wiki for details) for example:

[Authenticate]
[RequiredPermission("Hello")]
    public class HelloService : Service {
        public object Any(Hello request) {
            return new HelloResponse { Result = "Hello, " + request.Name };
        }
    }

Normally ServiceStack calls the method bool HasPermission(string permission) in IAuthSession. This method checks if the list List Permissions in IAuthSession contains the required permission, so, in a custom IAuthSession you could override HasPermission and put your OAuth2 scopes checking there.

Medea

Actually, it looks like you'd want to override HasPermission, but the same principal applies, the code goes in your IAuthSession implementation. – Medea

Revised my answer to recommend a custom request filter as a better solution than creating a custom IAuthSession and overriding HasPermission() – Medea

Accepted for pointing me in the right direction - thanks! - but see my own answer for a full implementation and explanations. – Jegger

Answer 2

OK, after a lot of stepping through the various libraries with a debugger, I think you do it like this: https://github.com/dylanbeattie/OAuthStack

There's two key integration points. First, a custom filter attribute that's used on the server to decorate the resource endpoints that should be secured with OAuth2 authorization:

 /// <summary>Restrict this service to clients with a valid OAuth2 access 
/// token granting access to the specified scopes.</summary>
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true)]
public class RequireOAuth2ScopeAttribute : RequestFilterAttribute {
    private readonly string[] oauth2Scopes;
    public RequireOAuth2ScopeAttribute(params string[] oauth2Scopes) {
        this.oauth2Scopes = oauth2Scopes;
    }

    public override void Execute(IHttpRequest request, IHttpResponse response, object requestDto) {
        try {
            var authServerKeys = AppHostBase.Instance.Container.ResolveNamed<ICryptoKeyPair>("authServer");
            var dataServerKeys = AppHostBase.Instance.Container.ResolveNamed<ICryptoKeyPair>("dataServer");
            var tokenAnalyzer = new StandardAccessTokenAnalyzer(authServerKeys.PublicSigningKey, dataServerKeys.PrivateEncryptionKey);
            var oauth2ResourceServer = new DotNetOpenAuth.OAuth2.ResourceServer(tokenAnalyzer);
            var wrappedRequest = new HttpRequestWrapper((HttpRequest)request.OriginalRequest);
            HttpContext.Current.User = oauth2ResourceServer.GetPrincipal(wrappedRequest, oauth2Scopes);
        } catch (ProtocolFaultResponseException x) {
            // see the GitHub project for detailed error-handling code
            throw;
        }
    }
}

Second, this is how you hook into the ServiceStack HTTP client pipeline and use DotNetOpenAuth to add the OAuth2 Authorization: Bearer {key} token to the outgoing request:

// Create the ServiceStack API client and the request DTO
var apiClient = new JsonServiceClient("http://api.mysite.com/");
var apiRequestDto = new Shortlists { Name = "dylan" };

// Wire up the ServiceStack client filter so that DotNetOpenAuth can 
// add the authorization header before the request is sent
// to the API server
apiClient.LocalHttpWebRequestFilter = request => {
    // This is the magic line that makes all the client-side magic work :)
    ClientBase.AuthorizeRequest(request, accessTokenTextBox.Text);
}

// Send the API request and dump the response to our output TextBox
var helloResponseDto = apiClient.Get(apiRequestDto);

Console.WriteLine(helloResponseDto.Result);

Authorized requests will succeed; requests with a missing token, expired token or insufficient scope will raise a WebServiceException

This is still very much proof-of-concept stuff, but seems to work pretty well. I'd welcome feedback from anyone who knows ServiceStack or DotNetOpenAuth better than I do.

Jegger