There are several other answers (ex:- this and this) explaining the background of state and how it avoid csrf.
Best thing is to refer what is given by specification creators. RFC6810 - OAuth 2.0 Threat Model and Security Considerations contains many threats and counter measurements for OAuth 2.0. In that Threat: CSRF Attack against redirect-uri gives a solid overview on the threat. Following is an extract,
An attacker could authorize an authorization "code" to
their own protected resources on an authorization server. He then
aborts the redirect flow back to the client on his device and tricks
the victim into executing the redirect back to the client. The
client receives the redirect, fetches the token(s) from the
authorization server, and associates the victim's client session with
the resources accessible using the token.
Now client has tokens which belongs to attacker. No, attacker won't be able to access anything that belongs to client in resource server. But if client perform a storing operation (ex :- Document create), this will be sent to malicious party. Now malicious party get access rights to those freshly created resource. This is highlighted as below,
The
effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's
resources. Or, when using OAuth in 3rd-party login scenarios, the
user may associate his client account with the attacker's identity at
the external Identity Provider. In this way, the attacker could
easily access the victim's data at the client by logging in from
another device with his credentials at the external Identity
Provider.
So basically threat is associated with fresh data created at resource server.
