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.