Passing ClientId in 3-legged OAuth (Authorization Code Grant Type)

stuartruiz
Participant I

I am building a login app that uses the authorization code grant type (3-legged OAuth) and am wondering how other people have solved the login app handling the public ClientId of the apigee app.

The first two legs of the flow (/authorize and /authorizationcode) require the client_id parameter to be passed so that apigee can determine which app you intend to access. My issue is that since the Login app needs the ClientId this either means our Login app has to manage public API keys or the client_id param must be passed as a query parameter or header in the redirect.

The former seems sub-optimal, because a simple changing of the public key could take down the system, and necessitate a configuration/code/database change to fix it.

However, I'm concerned about passing the ClientId around in the url or headers as that seems unsecure to me. Are my worries overblown or am I missing a crucial detail and not implementing this correctly? Thanks!

Solved Solved
0 2 341
1 ACCEPTED SOLUTION

I think your concerns are on track.

This example: https://github.com/DinoChiesa/devjam3-20170405/tree/master/Resources/oauth2-ac

...shows an authorization code flow in which Apigee generates an "authorize session" along with a unique ID for that session, and places that into cache. Apigee then issues a 302 to the client with that session id as a query param in the Location URL. The client follows the redirect to the login-and-consent app, which extracts the session id and calls into Apigee (with credentials!) to inquire the session. The login-and-consent app can then get all the information you need:

  • what is the app
  • who is the author of the app
  • when did the authorize session occur (if you like)
  • and other context (login hint, required fields, etc)

If that's too much work, then you can pass the client_id and other information in a header; these headers are encrypted when sent over TLS and won't be logged at either endpoint.

View solution in original post

2 REPLIES 2

I think your concerns are on track.

This example: https://github.com/DinoChiesa/devjam3-20170405/tree/master/Resources/oauth2-ac

...shows an authorization code flow in which Apigee generates an "authorize session" along with a unique ID for that session, and places that into cache. Apigee then issues a 302 to the client with that session id as a query param in the Location URL. The client follows the redirect to the login-and-consent app, which extracts the session id and calls into Apigee (with credentials!) to inquire the session. The login-and-consent app can then get all the information you need:

  • what is the app
  • who is the author of the app
  • when did the authorize session occur (if you like)
  • and other context (login hint, required fields, etc)

If that's too much work, then you can pass the client_id and other information in a header; these headers are encrypted when sent over TLS and won't be logged at either endpoint.

Very informative response, thank you for taking the time. I like the simplicity of passing by header but that may have more to do with my unfamiliarity with Apigee than the solution's merits. I see the authorize session in the diagram you linked, but how exactly is that done? Are those policies and cached objects available in Apigee or something that is created outside of Apigee?