OAuth2.0 - Generate Access Token Policy - Username & Password Elements importance ?

[anilsr]

Apigee Edge OAuth 2.0 policy Generate Access Token policy has XML Elements <username> & <password>.

Doc says ,

In cases where the app user name must be sent to the authorization server, this element lets you specify where Edge should look for the end user name. For example, it could be sent as a query parameter or in an HTTP header.

But why edge needs username & password ? What does it do with this information ? I believe generate access token will be executed after you verify credentials against target authorization server / some other backend system using serice callout / target system call. What does oAuth2 policy do with username & password ?

See an example here where Apigee Sample OAuth proxy captures username & password in the policy after credentials are validated using service callout. What's the use-case here ? Why does OAuth2 generate access token policy capture username & password after they are validated ? I have also seen these elements are optional, even if i remove same it works. But the question is, Why does OAuth2 generate access token policy capture username & password after they are validated ?

$$BOUNTY$$: I will reward 50 Points whoever successfully answers above question.

[sidd-harth]

Note - I do not have an answer, just sharing my experience.

This is exact issue I face few months ago while doing my certification. I did not give the username and password in Generate Access Token Policy because I thought I was validating them before in Service callout. I was getting 401 Unauthorized and did not understand where I went wrong. Later after reading docs I gave Username and password and it worked.

It is good you have raised the question, even I am keen to know why it is required.

[anilsr]

@Barahalikar Siddharth , Thank you for joining the discussion,

It now works even if i omit these elements, but not sure why these exist in this policy. Let's see if anyone has answer.

[davissean]

For the password grant type, Apigee will do a callout to an Identity system to validate these credentials. They may be held in BaaS, some User Service or an AD system.

I believe the policy just stores the existing variable in another variable. It would be worth testing if the policy fails when the values are undefined.

I have implemented the password grant type without this in the past, by manually doing a Service Callout, and using a RaiseFault if the backend generates an error that means the credentials are invalid.

[anilsr]

@Sean Davis , Thank you for your insights.

I don't see it's storing in some other variable in trace when we specify these elements in OAuth Generate Access Token Policy. I still do, service callout & raise fault. Question is what's the usecase of these elements in OAuth Generate Access Token Policy ? Policy succeeds even if these elements are not added to policy.

[gargi_talukdar]

Hi @Anil Sagar,

Please find related post here. Here Alex has explained that these fields are made mandatory to serve as a reminder to validate credentials.

[anilsr]

@GargiTalukdar , Thank you for the pointer. It's helpful.

Earlier, Looks like these elements are mandatory & the reason (reminder about validation of credentials) explained in above link make sense. As of today, these elements are optional. So, it doesn't make sense to have these attributes until unless there is an use-case like where edge auto populates username while verifying access token which @pdani mentioned in below answer. We need to verify that use case. Let's see if anyone has better answer regarding both the elements.

@docs Any idea ?

[#8]

Userid and password are not required to generate accessToken. They are validated first, then the oauth policy is executed to generate a token based on password grant.

The reason I would think userid (not password) should be passed in the oauth policy is to link the userid with token and when the token is validated in Apigee, userid will be populated in the flow variables. This way, apigee has the ability to inject this userid from flow variables in the request to the backend.

When Apigee validates the token, and sends the request to the backend (after validation), the backend loses the ability to track who the end user is. So as a best practice, userid should be injected in the request to the backend so that backend is aware of the end user.

[anilsr]

@pdani , userid is not available OOB as flow variable after verify access token until unless we add it as an attribute in GenerateAccessToken policy. Seems like it's more for validation as explained by @GargiTalukdar

[gargi_talukdar · Accepted solution]

Hi @Anil Sagar @Barahalikar Siddharth

The policy by default looks for these two elements in formparam for password grant, so if username and password are present as formparam , the policy will not throw any error even though username and password (variable reference) is not configured in the policy. But if these are not present as formparam then we have to mention the reference to these or else the policy will throw error.

I have tested this scenario and mentioned the same here

[anilsr]

@GargiTalukdar , Great Answer, Yes, You are right. It's there for the validation. I have verified same.

@docs , @Floyd Jones , @sgilson , @wwitman Can we update this information both in <UserName> & <Password> elements in OAuthV2 Policy ? Current doc is not clear why exactly these elements are present & i am sure like @Barahalikar Siddharth & Myself others also might got confused. Can we add a note saying these (<UserName> & <Password> ) elements will make sure username & password must be sent in request for password grant type & acts as a validation ? Feel free to change the words.

As promised, Transferring +50 Points, Thank you Again. Great Answer & Thank you for contributing to Apigee @docs.

[willwitman]

I’d like to offer this summary answer:

• For the password grant type, a username and password MUST be passed with the token request, or token generation will fail.
• However, the username and password are not used in any way by Edge, other than that they must be present in the token request.
  • They are not validated by Edge
  • They are not added to the accesstoken
  • They are not populated in flow variables
• In implementing the password grant flow, it is up to the API developer to make a callout to an IDP using the passed in credentials BEFORE the token generation policy executes in the token flow:
  • The OAuthV2 policy allows you to specify where it will look for the passed-in credentials. By default, they are in the request body, but they can be obtained from a query parameter, header, etc.
  • A Service Callout or other policy (that calls the IDP) can be configured to look for the credentials in the same location.
  • token request to Edge => service callout to IDP => generate token (only if IDP validation succeeds)
• I think Alex Koo's answer was good when he said “it serves as a reminder to validate the credentials”.
• The docs should be updated to reflect this -- they are misleading. I can take care of that. 🙂

For use cases where the user ID is needed in requests to the backend service (to maintain session state or for whatever reason), a good approach is to store the user ID with the token as a custom attribute. It’s then easy to retrieve the attribute and insert it into backend service requests.

[anilsr]

Awesome, I can see the updated docs. Thank you for quick action & great summary @wwitman !!