Necessarily then, a Client has gone 'bad'.
Why then is this not an issue for the use case that OAuth was designed for, ie delegated authorization of API access? Could not such a Client also go 'bad' and do similarly malicious things?
In the delegated access use case for OAuth, all that an access tokens 'means' is that it allows a Client to access the corresponding User's protected resources. Clearly a Client can go bad and share this access token and (in a bearer token model) anybody else who obtains that token will also be able to access those same resources. Critically, all these additional Clients will only enjoy the permissions allowed by the scope attached to the original token.
As John points out
In the authorization case the client can be trusted with the access token because it has no real motivation to share it. They could give it to a third party and also grant them access to the information(protected resource), but they can just share the information anyway if they are badYes the Client can go bad and share the access token. But it already has access to the protected resources and can already do all the evil operations it desires against those resources. The fact that a shared token will allow multiple bad Clients to perform evil operations instead of only the original bad Client probably wont matter much to the user.
So in the authorization case, if a Client goes bad - it doesn't really matter whether that evil manifests as that Client doing malicious things with the token, or rather sharing that token and allowing other bad Clients to do the malicious things. Put another way, sharing the token doesn't change the 'scope' of the possible damage.
But this isn't the case when basic OAuth is used for authentication. If a malicious Client can use its own token to impersonate a User at some other (non-evil) Client, then the scope of the attack expands greatly - to include all the damage that malicious Client can do at the other Client.
