One is the most confusing things in OAuth is a so-called 2-leg OAuth flow where an explicit authorization step involving the end user pressing an Allow or Deny button is not taken.
There are many resources on the web explaining what is an OAuth 2-leg flow. Most of those explanations are effectively describing the process where the 3rd party consumer accesses its own space on the resource server, possibly with the end user itself 'hiding' behind such a consumer.
But the classical OAuth is about the 3rd party consumer being able to access one way or another the resources of the end user. How does a 2-leg flow gets into the picture ?
Please read this blog entry. This is the best explanation I've seen so far and it was so good I had to stop doing my current task immediately and quickly update the CXF OAuth 1.0 code to be able to handle all the variations of the 2-leg flows better.
I think this 'pure' 2-leg flow described by Andrew is really close to a client credentials flow in OAuth 2.0. Without a pre-authorized access token (authorization code) the options are limited for a 2-leg flow.
Please see the updated documentation for more information on how CXF supports OAuth and its 2-leg flows in particular.