What is the benefit of the scope in OAuth2?

Question

In the question, substitute scope with state. Since there is an answer based on the wrong question, I'll let everything below as is. The answer is useful nonetheless.

---

This question refers to the current draft v30 of OAuth2 and GitHub's implementation thereof.

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?

Answer 1

State Parameter

The scope parameter is not used to secure the authentication request against CSRF attacks (see below). But there is another parameter called "state", which matches your description.

[Asking the user]

This step cannot be skipped.

I am afraid, this assumption is not correct. It is very common, that the user is only asked for permission, when he uses a client application for the first time. After that the server remembers the client application and grants access automatically.

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).

Other means may include that the application is trusted by the server (e. g. owned by the same company) or that the user's decision was saved.

So without a state parameter, the attacker can trick a user to log in to an application, that is known to the user in principle or generally trusted by the server.

Scope Parameter

The scope parameter is used to indicate a list of permissions, that are requested by the client:

The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter.

For example permissions for a social network may include:

post_to_my_wall  send_notification  post_to_my_friends_wall  read_my_age

The value of the scope parameter is expressed as a list of space- delimited, case sensitive strings. The strings are defined by the authorization server.

The server may provide all requested permissions or a modified list (for example because the user denied some permissions):

If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted.

Source: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-30#section-3.3

Answer 2

(answer is based on the assumption that OP meant to talk about the "state" rather than the "scope")

I don't think the "state" parameter is meant to be a security feature. It's just a parameter that the consumer can use to put some data that it want to retrieve after the authorization flow is completed.

This is useful in the case where the consumer cannot maintain a state on its own (stateless client, not session based, etc.). Since the authorization flow involves redirecting the user browser to the provider, the client may, for example lose track of which page the user was on when they triggered the auth flow (or what the user was trying to do).

By passing that information in the state param, the client will get it back after the autorization flow and can redirect the user to the appropriate location for example.