OAuth2 User-agent flow + two-legged OAuth

I have 2 questions about OAuth2's user-agent flow. (the current RFC draft of OAuth2's user-agent flow is here: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-11#section-2.2)

1)

Step C: The access token h开发者_Go百科as to be given in the fragment, because only the user-agent (browser) will have access to it. Why is it such a problem if it will get to the server-side (if there is any server-side) there are also easy workarounds so that the client-side can pass it to the server-side (cookie, hidden fields, ...)

2)

I want to implement OAuth2 user-agent flow, but with the two-legged version (request_token is enough, the consumer app can act as his users, so no need to authenticate the user at the service provider)

I have one major security gap with the combination of OAuth2's user-agent flow and the two-legged version:

The web browser handles all the redirection. This means that even though the service provider thinks it's sending the user to the specified host and domain, that host and domain is trivial for a user to redirect to their own machine -- or anywhere, by tweaking their DNS setup or /etc/hosts file.

Let's see this with 3-legged and with the 2-legged version:

• With 3-legged OAuth this isn't a major problem because the user still need to authenticate himself at the service provider. An attacker may set up a false domain leading to his machine, but he still need the credentials of the user. He can lure the user to his domain but he has to make the result of the domain lookup (done by the user's user-agent), which he can only do by having acces to the user's machine (which is more difficult)

• With 2-legged OAuth however: An attacker can easily set up a localhost (/etc/hosts) with the domain of the innocent consumer app and get the request_token. The user has nothing to do with it.. The attacker can now make calls on behalf of all the users of the innocent consumer app. Does anybody have any idea how to secure this gap?

Greetings, Chielus