Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 13 down vote accepted

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.


share|improve this answer
You are right. I meant the state parameter all along. The scope is completely clear to me. I feel so stupid right now... :( But thanks anyway. Maybe I'll open another question for the state parameter. – musiKk Aug 12 '12 at 18:10
@musiKk, I also explained why the state parameter is important. Is there still something unclear? – Hendrik Brummermann Aug 12 '12 at 18:38
I thought about it a bit more and I guess you're right. I based most of my assumptions on GitHub's implementation where indeed you can't skip the "ask the user" step the first time (at least I wouldn't know about it). I guess the main security reason against unintentional log-ins is protecting the user against vulnerabilities in the client. Thanks again for your patience. – musiKk Aug 12 '12 at 23:11

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

share|improve this answer
Quoting RFC 6749: "The [state] parameter SHOULD be used for preventing [CSRF] as described in Section 10.12." So I guess it is a security feature. – musiKk Mar 15 '14 at 22:17

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.