In Oauth what is the benefit of the access token being opaque
Why was the decision taken that the Client doesn't need to be able to parse the access token?
It seems to me that if the token included, in addition to the current fields, a client_id and a user_id, it would make life much simpler, prevent spoofing, enable authentication, etc.
I've noted that as per section 1.4 of RFC 6749 it does not HAVE to be opaque, but it seems to me that much of OpenID Connect, if not all of it, is a way of making the Access Token into something meaningful. Yes, it adds an ID token, but the fact that it is implemented as something accompanying in stead of embedded in the access token does not change this fact. It seems every video, tutorial and blog post talks about it as if that is to be assumed to be the case (that access tokens will be opaque, because "The client is not the intended audience") ... And yet it is the API or resource provider who cannot establish authentication based on the the bearer having the token.
Actually I need to add that I don't think the token being opaque to the client is the problem. The problem is that the token is a bearer token that doesn't restrict WHO can use it.