Should I verify HTTP Referer in OAuth 2 Callback?

Question

I am successfully able to authenticate Facebook and Google accounts using my Oauth2 servlets. I am using state with a timer and a session cookie to try to verify that it is indeed a legitimate Oauth callback.

1. Is there any benefit if I also examine the HTTP Referer header to ensure that I was redirected from the provider's OAuth page?

2. If no benefit, could there be a problem if I also examine the HTTP Referer field?

Answer 1

No.

1. I can simulate any headers I want as a malicious attacker. I can make it look like I'm coming from http://cia.fbi.gov.vpn/uber1337h4x. This is obvious and well known.

2. Any pages coming from HTTPS do not send a refer header as per RFC2616 sec15:

   Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

3. Breaks usability as per RFC2616 sec15:

   Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent.

In short, you are not given greater security. Your security is not in inspecting a vastly insecure transport protocol, it's in the OAuth layer. You also break usability.

Don't do it.

Answer 2

The answer is:

No, you shouldn't use it, and there is NO valuable benefit of doing it.

Authorization Servers are very aware of this also. And here was stated.

From the mailing list of OAuth-WG:

Callback URL pages SHOULD redirect to a trusted page immediately after receiving the authorization code in the URL. This prevents the authorization code from remaining in the browser history, or from inadvertently leaking in a referer header.

• If you are worry about CSRF, you SHOULD NOT use the HTTP Referer as a technique to verify the origin of an authorization, that's why the parameter state is (which sound you're using).

• If you worry about an specific security concern of the oauth2 protocol, there is a full section inside the draft.

• If you worry about other Security Considerations, this is the source.

I suggest you give all your effort implementing all the validations around the param: state.

Edit:

After reading the nuances of the question, you are really answered your own question. The use of cookies (probably HTML5 local storage) for both cases, is the best solution we know so far.

• The first nuance is about CSRF and one of the possible countermeasures available is Checking the HTTP Referer header, and this was already addressed in the protocol.

• The second nuance, I'm not completly sure, but is probably a case of Extension Grant, this is because it sounds that you may work as an "auth proxy requester", same as SAML oauth2 extension.