This is a fairly old post, so I'm assuming you figured this out already. In case you haven't, and for the benefit of everyone who stumbles across this page, I'll explain why it's more secure.
If you are trying to access secure services, some sort of credentials must be provided. Regardless of whether or not you are using a secure connection, the credentials are passed in plain text. Once your credentials are validated, the token service will send the token in plain text. So there are two chances for someone to intercept valuable information that would allow them to access the site. If they intercepted a token, they can typically only use it for a short period before it expires (in the case of a short term token). If they intercept the username and password, however, they can request tokens that would allow them to access the site for as long as the credentials are valid.
A scenario that's even worse is if the username and password or token are stored within the application. In this case that's all someone needs to do to discover it is to reverse engineer the application and read it. With all of the tools available this is really easy to do. In some cases, such as javascript, it's already plain text.
Enter the proxy page. The proxy page will typically store either username/password or the actual token. If you don't secure the proxy page, of course anyone can access it. That's why you secure the page, much like you would any page you want to limit views to. At that point you could control who has access to the page and who doesn't. The username/password or token is stored on the server only, and nothing is ever transmitted to the client.
- Anthony
