I think the biggest problem is that OAuth2 itself doesn't really tell you how the implementation details look like.
To quote the RFC:
The token may denote an identifier used to retrieve the authorization
information or may self-contain the authorization information in a
verifiable manner (i.e., a token string consisting of some data and a
signature). Additional authentication credentials, which are beyond
the scope of this specification, may be required in order for the
client to use a token.
Access tokens can have different formats, structures, and methods of
utilization (e.g., cryptographic properties) based on the resource
server security requirements. Access token attributes and the
methods used to access protected resources are beyond the scope of
this specification and are defined by companion specifications such
as [RFC6750].
For example you could use JWT to validate a request or you could use the token only as an identifier and ask a service whether the token is allowed for that resource.
Depending on your OAuth2 provider the implementation can vary, so my guess is the framework can only provide you the common thing (extract the token for you) or it would have to implement all possible OAuth2 implementations, which seems not feasible at this point.
I personally have used pauldijou/jwt-scala in the past, which you might want to take a look at.