There's a degree of confusion in your comment. I pointed out the fact that OAuth handles authentication, not authorization. Those who fail to understand this clearly don't know the basics of the whole system. This is what I posted in my previous reply to your post.

The same applies to JWTs. They are the output of an authentication process. They do not authorize anything. They bundle a set of claims along with metadata used to prove they can be trusted and when they are valid. They are designed in a way that resource servers can validate them locally before actually handling any authorization concern.

The authorization part is handled by the systems which check these claims. It's a separate concern, handled separately by separate systems. If you were familiar with any OAuth flow, you'd be aware that this part takes place only after any of the flows take place, and is way outside of their scope.

This is what I'm talking about. If you do not understand the problem domain then you are in no position to criticize or complain about how solutions are implemented. You can only complain about the time you're wasting criticizing things you know nothing about.

Restricting the scope is mostly useful for when you need to interact with services that talk to other underlying services without granting them full access to those, but in practice, that's not a very common case outside of the web.

Ultimately that distinction doesn't really matter, what's important at the end of the day is how you implement the access control. Using an opaque token and an introspection endpoint is a terrible idea. JWT is a good solution. All of the OAuth flows do is just provide convoluted ways for the user to authenticate with a identity provider, generating a JWT on his behalf, and do not contribute to security in any meaningful way.