Internal Authorization Code Grant Type Flow

[carlosferreira]

I am building a login App internal that uses the Authorization code grant type flow.

The first step: REQUEST  - (GET /authorize) require the client_id parameter to be passed and then im using ExtractVariables by QueryParam require {state}, {response_type}, {redirect_uri}, {client_id} and {scope}. How can i get the 'redirect_uri' ?
RESPONSE - AM-SetLoginPage the policy build a HTML Form page with need the ExtractVariables, i need to simulator a login web page.

Second step: REQUEST - (POST /authorizationcode) i'm using ExtractVariables to extract the variables from Loggin Form Page.
RESPONSE - OA2-GenerateAuthorizationCode with the variables attributes.

Third step: REQUEST - (POST /token) OAuthV2-GenerateAccessToken. 

[dchiesa1 · Accepted solution]

then im using ExtractVariables by QueryParam require {state}, {response_type}, {redirect_uri}, {client_id} and {scope}.

Extractiing from what? From the inbound request?

In the /authorize request, I think all of the required or optional fields - client_id, response_type, state,redirect_uri, code_challenge - can be accessed within Apigee directly via context variables. There's no need to use ExtractVariables. Just reference variables like request.queryparam.client_id etc.

How can i get the 'redirect_uri' ?

It's a query param, so you can get it by referring to the appropriate variable. If you want to validate that, then you need to perform a VerifyAPIKey or GetOAuth2Info policy using the client_id. The latter looks like this:

<GetOAuthV2Info name='OAuthV2-GetInfo'>
    <ClientId ref='request.queryparam.client_id'/>
</GetOAuthV2Info>

The result of that policy will set a context variable like oauthv2client.OAuthV2-GetInfo.redirection_uris , and you can compare what the client sent to what is in the list, and validate that way. Or, you can skip the manual validation at this time, because Apigee will automatically validate the uri later, during GenerateAuthorizationCode.

i need to simulator a login web page.

Yes, you need to construct a login-and-consent experience in order to make this work.

I've built these, repeatedly, before... not sure if this old repo is working with Apigee X. https://github.com/DinoChiesa/Apigee-Edge-OIDC-Demonstration. But even if not, you might be able to re-use or re-purpose the login-and-consent webapp that is bundled there.

I am building a login App internal that uses the Authorization code grant type flow.

What is your goal here? An internal app that uses authorization_code grant type? Why? The 3-legged flow is designed for use in cases in which the resource manager and the app are not delivered by the same source. The resource manager meaning "Apigee + the upstream" and the app meaning "the client app that connects to Apigee and the upstream". If you are building a thing for internal use, then it sounds like all of those things are being built by the same actor (the same company) and so there is no need for 3-legged flow. Does that make sense?

Anyway if you could take a step back and explain what your real goal is , the goal BEFORE you came to the conclusion that you needed to build a simulator login page, maybe I might have some other suggestions.

[carlosferreira]

Thank you very much Dino, I'll put your knowledge into practice and if I have any questions, I'll get back to you.