Closed ivan-novakov closed 9 years ago
Thank you for reviewing this -- I agree that we have a problem with this sample. We'll look at the best way to make it correct.
We are trying to implement an OAuth2 server proxy with Apigee using an external authentication service and it is not an easy task. At the proxy we need to validate the result of the authentication. Right now we are considering the following options:
This sample is superseded by the "sample-proxies/oauth-advanced" sample, which was designed to represent best practices for implementing the Authorization Code grant type (3-legged OAuth).
Added a note to the oauth-login-app README explaining this. There's also more information on this grant type here: http://apigee.com/docs/api-services/content/oauth-v2-policy-authorization-code-grant-type
It is possible that I'm not getting something right, but I think there is an issue with the suggested "web server flow" described in the oauth-login-app sample proxy: https://github.com/apigee/api-platform-samples/tree/89aaaf327153f2bd1ba357eb58c39a6601d4fc2d/sample-proxies/oauth-login-app
First, the client app redirects the browser to the
/authorize
endpoint of the proxy. That endpoint redirects the browser to an external login application. That application authenticates the user and redirects the browser to the/authorizationcode
endpoint of the proxy passing the user ID as a GET parameter.Now I'm missing some kind of validation that the authentication process really happened. It seems that the client app may redirect the browser to the
/authorizationcode
endpoint directly passing any user ID as a GET parameter. The server should not trust anything that passes through the browser, as it can be modified.