oAuth 2 question about oauth-advanced. Confirming oAuth Spec. How do we support multiple developers?

[robert]

Hi,

I've been reviewing the auth-advanced proxy. The example works but I have a couple questions and comments:

1) Is this example following the oAuth 2.0 spec for the auth-code flow? The reason I ask is because it seems the login page is requesting the auth-code on behalf of the client app. How does the login page know which client-id to send? In the scenario where we are supporting many third party apps, where does the login page obtain the client id and how would it know the app redirect URL? I take it the client-id would be sent from the clientapp to the login page as a client-id parameter?

2) Reading the oAuth 2 spec, the client app should send a request of response_type=code to /authorize and then the auth server should redirect to a login page for the user to login and authorize. Then, after success, the login page redirects results back to auth server where the auth server would generate and return the code to the client? Perhaps I misunderstand the spec? If my understanding is correct, as google has for it's API here, then the Apigee example is incorrect: https://developers.google.com/identity/protocols/OAuth2WebServer#preparing-to-start-the-oauth-20-flo...

Not trying to be confrontational but just want to ensure I understand correctly and for the benefit of the community. To me, the Apigee oAuth 2.0 example works fine for in-house applications but in setting up a developer program where we want to support multiple developer apps (each having a different client id), it doesn't seem to work. Again, perhaps it is my misunderstanding? At a minimum, the client apps would need to send their client id to the login app. Or we could probably create a /login api that would require the client id and redirect the user to the login page while forwarding the client id and redirect url. In the latter instance, the login app would again call the /auth on behalf of the client -- which seems incorrect (again, could be my misunderstanding of the Apigee implementation).

Regards,

Robert

[naseerm]

Apigee provides a flexible OAuth model to cater to various enterprise OAuth use-cases.

For point number 1, you can have as many client_id's registered in Apigee as you need, these client_ids have a Many-To-One relationship with Apps. This way an App can be accessed by multiple client_ids if that is your need or you can have multiple Apps and each App can have one or more client_ids. An important point for you to note here is : OAuth specifications does not define any standards on associating client Ids to apps or URIs (Reference to login page in your query), Apigee's association of client_ids to Apps and API-Products provides you an approach that scales very well and provides an effective solution for addressing the above gap in OAuth specifications.

For point number 2, the source of truth for Authorization Code Grant Type or any defined grant type is OAuth specification defined here. The flow starts by passing client_id which is passed by the UserAgent. Apigee can store the requested client_id and corresponding state and nonce parameters in cache and issue a redirect, once the callback is received, apigee can validate incoming client_id, code and state parameters with the values stored in the cache in the original request.

Hope this helps,

Naseer