> This is a reasonably fundamental issue of is the plugin should be separate or extend AuthComponent (Using the startup() method is replicating the behaviour of AuthComponent).

Please see below.

> Some methods have to be provided via a component (e.g. the OAuth class methods) and so the main argument for separation is that it could all be done in a single component. So that's why I chose not to build it as Authentication object.

I think the current implementation of the component might not work well when used together with Auth and Acl components.

IMHO, it's better to have a separate and simple Authenticate class, i.e: we just authenticate the tokens.  For authorization, one could use the default AclComponent for this with their choice of Authorize object (or with Controller::isAuthorized()).

> If it could be shown to work nicely then I would probably be in favour of switching to that pattern of a component + an authentication object, and I don't see any reason to offer the old pattern as an option?
Is this towards what you were thinking?

Yes, I think it's possible to extract the oauth-php specific methods into a separate Lib class and still maintain compatibility with the current methods.  I'm in the middle of this, but holiday gets in the way. :)

But we should still offer the current OAuthComponent for BC purposes, and for those who only need simple 'authorization' based on OAuthComponent::$allowedActions. I'm fine with marking it as deprecated though.