In the question, substitute
state. Since there is an answer based on the wrong question, I'll let everything below as is. The answer is useful nonetheless.
GitHub's "Web application flow" is more or less an implementation of Authorization Code Grant as described in the spec. The client (the Web application) directs the user to a special page on GitHub which asks whether the user wants to allow the application access to his or her resources. If this is confirmed, the user is redirected back to the client which then uses a temporary code to retrieve the OAuth token for future use.
If the client provided a
scope parameter for the user's request to GitHub, the redirect contains that parameter as well. If the scope is some secret only known to the client, the client can be sure that nobody else created that request, i.e., that the user has not been the victim of a CSRF attack.
But is that really necessary?
If we choose not to use a
scope parameter and the user is indeed the victim of a CSRF attack, he or she must still accept the question asked by GitHub whether the client is allowed access to the user's information. This step cannot be skipped. Indeed the spec says
[The] authorization server authenticates the resource owner and obtains an authorization decision (by asking the resource owner or by establishing approval via other means).
If the attacker uses other techniques like clickjacking to trick the user into accepting the request, I reckon all bets are off anyway and the scope won't protect the user either.
In conclusion: Against what threat does the scope actually protect the user?