OAuth Authorization flow and redirect

Question

I started looking at OAuth - Google's and Facebook's implementation. Both of the implementations, in the authorisation flow, seem to send the "Authorization code" back to the web browser. I was wondering what is the benefit of sending the code to the browser vs just hitting the redirect_uri from the authorisation server? If we send code to the browser we risk that someone somehow gets hold of it while the risk does not exist if the code is sent straight to the server (redirect uri target).

Answer 1

The delivery of the Authorization Code is not more a security issue than is sending the user's password from the browser to the facebook server (for example). That means, if there is an insecure connection, an attacker would be able to compromise the user's authentication anyway. For that reason, OAuth is meant to be executed with HTTPS.

The reason why it needs to be implemented like that is because only this way the OAuth client is able to identify the user who requested OAuth. This is because when a user for example clicks on the facebook button on StackOverflow, it immediately connects him to facebook where the OAuth process starts. StackOverflow so far doesn't know that this user requested OAuth via facebook. Only through now redirecting the user to StackOverflow along with the Auth Code does StackOverflow know that this user (with his session ID) used facebook OAuth and got this Auth Code. Now StackOverflow is able to connect Session ID with Auth Code and knows who requested facebook's OAuth.

edit I've looked at the RFC of OAuth, and I have to make a correction regarding my first point. While it is highly recommended for the redirect endpoint to use HTTPS, it is not mandatory yet. See Endpoint Request Confidentiality. So the Auth Code indeed might be sent unencrypted at some point, that is when redirecting to the original server which has not HTTPS activated. But still, to me this is a huge security issue with the whole OAuth process. HTTPS should imo be mandatory. If a server can't HTTPS it's connection, it shouldn't play with OAuth after all.

Answer 2

It's sent back to the browser because it is essential to do it this way.

It might be crazy, but the whole OAuth/OpenId security is based on the fact that your browser will do the right redirect.

Let's look at an attack if you don't use the browser as a redirect but first let's define a simplified version of the OAuth "framework" for our example.

• Client : The application you wish to connect to
• Browser : Your browser...
• Provider : The OAuth provider (Ex.: Google or Facebook)
• Evil : The attacker.

The normal flow

1. Browser ask client to login
2. Client redirect browser to Provider
3. Provider authenticate browser then redirect to Client with token
4. Client communicate with Provider giving the token for authorization.
5. Client grant authorization to browser.

Your flow

1. Browser ask client to login
2. Client redirect browser to Provider
3. Provider authenticate browser and send token to client giving him authorization
4. Client grant authorization to browser

The problem here is that the client is not sure that the browser it is communicating with is the same browser that authenticate himself with provider.

An attack on your flow

1. Browser access Evil for some bad reason
2. Evil impersonate Browser and ask Client to log in.
3. Client send redirect link to Evil
4. Evil forward the link to Browser which redirect him to Provider
5. Provider authenticate browser and send token to Client giving him authorization
6. Client grant authorization to Evil thinking it is Browser

See the problem in the last step?

This would not have happen if you were using a browser redirect to send the token to the client. By using a browser redirect, you make sure that the Browser that is authenticating with Provider is the same Browser that is trying to gain authorize right with Client.

This is a crucial step. Especially since many Provider will send the token automatically after the first time if you are log in. So, Evil could gain access to your account just from you visiting his page and you would not even know.

The same attack with normal flow

1. Browser access Evil for some bad reason
2. Evil impersonate Browser and ask Client to log in.
3. Client send redirect link to Evil
4. Evil forward the link to Browser which redirect him to Provider
5. Provider authenticate browser then redirect to Client with token
6. Client communicate with Provider giving the token for authorization.
7. Client grant authorization to browser.

Here evil was eclipsed at the end because of the redirect. This is why the protocols do so many checks on the redirect url to make sure it will not redirect to a malicious site stealing the authorization token.

OAuth/OpenId protects you again phishing attempt. But they can only do it because your browser is doing the right redirect. On desktop/mobile app this is not really working, hence why the protocols are less secure on desktop/mobile app.

Specifically, it protects the Client against phishing attempt. The client must make the very hard decision : Is the browser asking for authorization the same as the browser that authenticate with the provider? And the only thing helping the client to do that, is the redirect and the fact that your browser is secure.

Since it directly protects the Client against phishing, it indirectly protects you.