We are creating a api that uses authorization attribute request filter in all paths(except login, of course). The attribute request for authorization to another system. Because request filters are sync the request is blocked and waiting for response at this point. A solution can be that request filters can returns a Task. Something like this:

public override Task ProcessRequestAsync(IRequest httpReq, IResponse httpRes, string operationName){


.....


return Task.Factory.ContinueWhenAll(appHost.ApplyAsyncRequestFilters(httpReq, httpRes, request),
tasks => httpRes.IsClosed ? null : GetResponse(httpReq, request))
.ContinueWith(tResponse => HandleResponse(tResponse.Result, response =>
{
if (appHost.ApplyResponseFilters(httpReq, httpRes, response))
return null;

if (responseContentType.Contains("jsv") && !string.IsNullOrEmpty(httpReq.QueryString["debug"]))
return WriteDebugResponse(httpRes, response);

if (doJsonp && !(response is CompressedResult))
return httpRes.WriteToResponse(httpReq, response, (callback + "(").ToUtf8Bytes(), ")".ToUtf8Bytes());

return httpRes.WriteToResponse(httpReq, response);
},
ex => !HostContext.Config.WriteErrorsToResponse
? ex.AsTaskException()
: HandleException(httpReq, httpRes, operationName, ex)));
}

Although oAuth 2.0 is supported by ServiceStack with its AuthN providers, the assumption the current model makes is that clients wishing to access the service will first authenticate through the SS service (by calling the Auth endpoint). This AuthN then caches the users identity in the session of the SS service, and uses it to verify AuthN for subsequent calls. AuthZ is then provided with the users identity fetched from session cache.

However, in more distributed models AuthN may be handled outside of the SS service, by other services, perhaps from the client directly and users identity stored elsewhere. But the service may still need to be secured to AuthZ requests for specific users or identity providers (i.e. Facebook, Google, etc) by verifying the oAuth 2.0 bearer token.
Although oAuth 2.0 is actually implemented using other libraries (i.e. DotNetOpenAuth) putting together this kind of distributed service is still difficult to get right, and may be perceived too risky for a developer wishing to get started with SS.
Although SS offers all the necessary hooks and extensibility points to set up a solution like this, there are few if any examples of doing it right with SS.
Can we have a simple example of a SS service that uses one of the recommended extensibility points in SS (perhaps a RoleAttribute, or some such mechanism), and that authorizes service API calls made by clients who already authenticate the user with a specific AuthN provider (i.e. facebook)? IN other words, SS simply provides the authorization, and no authentication of service API calls.

An example like this would go leaps and bounds to helping SS implementers untangle their understanding of AuthN and AuthZ in service design, and help many get up and running with SS quicker in these distributed implementations.

It would be very interesting to have a better integration with oauth protocols.

Some ideas:
1. Authentication/authorization provided directly by SS. At moment is possible to use oauth, but only with some external libraries (DotNetOpenAuth or others).

2. The Access Token could be released with some oauth permissions defined in a global configuration setting. When the client request an access token, the request must contains a list of permission (like facebook, twitter and others API)

3. The permissions can be used for authorize some services only if the oauth access token provided in the request is valid for it. For example with custom attibute on service (like roles):
[OauthPermission("read_user_books")]