- In the top of the flow, the first step is to validate client id’s app. If it’s successful, Edge will redirect to the login app, right?
Correct.
a. What happen if client app ignores this step and starts with redirect to login app?
Good question. In my implementations, I design the API Proxy to initiate an authorization “session”, by populating a cache entry with some metadata about the client, and redirecting to the login endpoint with an identifier of that session. In practice it looks like this:
<Flow name="authorize_app">
<Condition>(proxy.pathsuffix MatchesPath "/authorize") and (request.verb = "GET")</Condition>
<Description/>
<Request>
<Step><Name>OAuthV2-GetInfo</Name></Step>
<Step><Name>AM-AuthorizationSession</Name></Step>
<Step><Name>CP-AuthorizationSession</Name></Step>
</Request>
<Response>
<Step>
<!--
The response is a 302 redirect to the login-and-consent app.
-->
<Name>AM-RedirectToLoginApp</Name>
</Step>
</Response>
</Flow>
You may be able to infer the purpose of the various policies. OauthV2-GetInfo is a GetOAuthV2Info policy, which retrieves information about the client (based on the client identifier). If the client id is invalid then this policy fails. AM-AuthorizationSession just creates a payload containing information about the client. CP-AuthorizationSession puts that payload into cache, using the messageid as the cache key. And finally AM-Redirect just sets the Location header pointing to the login endpoint, with the messageid as a queryparam.
Later, separately, the Login-and-consent app can call back into the Apigee Edge (on a session endpoint) to query information about the client. This might include: the client name, the developer name, the logo for the client app, and so on. (It’s up to you).
b. What is the redirect_uri in this step? Does it mean “login app uri” or “client app callback uri” (same with 2b)?
The redirect_uri is registered per client. It can be verified by Apigee Edge, in this way: Using GetOAuthV2Info, Apigee Edge retrieves all of the registered metatdata for the client into context variables. At that point the proxy can check that the passed-in redirect_uri matches the registered redirect_uri. The redirect_uri is not actually used until the code is retrieved (a later step). It can be optionally validated here in this step, though.
Similarly, this step can also explicitly validate the set of scopes the client is requesting, too.
- In the Generate Auth Code request, What is the client_id in this step? Is it a client_key of “client app” or “login_app”?
The client_id is for the registered client app. It is the same client_id as is passed to the /authorize endpoint.
b. Is redirect_uri in this step a uri of client callback (for sending back auth code)?
Yes.
I have a working example if you would like to examine it. Find it here. You should be able to just deploy it into your own organization and run it. There is a provisioning script that sets everything up, so it should be pretty easy. (and when you’re finished, that script will tear everything down, too.)
As of now, the README now includes a sequence diagram showing the actors and how they all connect.
