Resource owner password credentials flow documentation gaps...

We started working on implementing the Resource owner password credentials flow within our API and created an endpoint that can receive a emailId and password to authenticate, but are having a hard time finding more details on implementing this flow in Apigee. The documentation located at http://docs.apigee.com/api-services/content/oauth-20-client-credentials-grant-type states that the grant type is covered in Part 6, Lessons 6 and 7 of Foundation training.

However, there doesn’t appear to be a reference to Part 6, Lessons 6 and 7 in the course located at the Foundation Training link, which is http://academy.apigee.com/courses/elearning/foundation_training/Foundation_training

Can someone point us in the right direction? We are looking for the following information:

  • Is there a specific policy template that should be used for this flow?
    • The article covers the Basic Authentication policy, and mentioned OAuth with respect to overriding the OAuth handler, but it doesn’t go into details.
    • I looked at the list of policy templates, and there isn’t one specific to this flow.
  • We would like to return information, specifically the user identifier, so we can store it in the data store. Is there a specific schema Apigee expects?
    • If the authentication fails, we will return a 401 with a body containing details about the failed authentication. Will the response just be passed back to the client application?
    • If this is not the default behavior, can it be configured to pass this response back to the client application?
  • With respect to sending the request to the user service to authenticate, is the path and variables configurable?
    • The documentation states the path is /services/user/authenticateUser(emailId, password). Could this path be modified to something like User/Authenticate?
    • With respect to the parameters, how are they sent:
      • Are they sent in a header?
      • Are they sent in the body?
      • Are they sent as URL parameters?
Solved Solved
0 8 378
1 ACCEPTED SOLUTION

Hi @Anthony Coelho,

I think I can help point you in the right direction on some of your questions -- hopefully enough to make progress. I'll have to look into the training video link and fix it up - it may be out of date.

I'd start with this topic talks about password grant type.

Also check out this topic. It tells you exactly how to request an access token using the password grant type. It includes: the API call, the Policy xml, and an example response.

You can catch errors and return custom responses using the Raise Fault policy. The general topic on Fault Handling provides some more info and context.

When you are verifying a token, using the OAuthV2 policy with the VerifyAccessToken operation, you tell the policy to look for credentials in the header, query param, or form params. See this topic.

It's also possible to store attributes like a user UUID in the access token itself, as a custom attribute. Not sure if this helps you, but it's a common practice that lets you associate the oauth token with a specific user. I have an example I could share if you need it.

I'm not sure which doc has this path /services/user/authenticateUser(emailId, password). Can you point me to it?

Will

View solution in original post

8 REPLIES 8

Hi @Anthony Coelho,

I think I can help point you in the right direction on some of your questions -- hopefully enough to make progress. I'll have to look into the training video link and fix it up - it may be out of date.

I'd start with this topic talks about password grant type.

Also check out this topic. It tells you exactly how to request an access token using the password grant type. It includes: the API call, the Policy xml, and an example response.

You can catch errors and return custom responses using the Raise Fault policy. The general topic on Fault Handling provides some more info and context.

When you are verifying a token, using the OAuthV2 policy with the VerifyAccessToken operation, you tell the policy to look for credentials in the header, query param, or form params. See this topic.

It's also possible to store attributes like a user UUID in the access token itself, as a custom attribute. Not sure if this helps you, but it's a common practice that lets you associate the oauth token with a specific user. I have an example I could share if you need it.

I'm not sure which doc has this path /services/user/authenticateUser(emailId, password). Can you point me to it?

Will

Hi @Anthony Coelho did that help? Do you have any followup questions?

Hey Will, thank you for the response. I had already reviewed the documentation you provided links to which helped but didn't "tie everything together" for the password grant type. I ended up finding a YouTube video https://www.youtube.com/watch?v=7vBh8LT2xW4 that addressed our specific questions.

Excellent @Anthony Coelho.

For any further questions please feel free to leverage the community.

You can see all 4MV4D videos here: https://www.youtube.com/watch?v=3BEKp6DrmTo&list=PLIXjuPlujxxxe3iTmLtgfIBgpMo7iD7fk for help on other topics.

@Anthony Coelho , Glad to know 4MV4D videos helped in your case. Thank you @Prithpal Bhogill for making awesome video, FYI @rlau

@Anthony Coelho --

That's great, good to hear you got it working. That's an excellent video, and I embedded it into the Password Grant Type topic so others will find it more easily.

Will

Password Grant flow is documented here: http://docs.apigee.com/api-services/content/implementing-password-grant-type. Is that the flow you are looking at?

You can see a number of sample implementations here: https://github.com/apigee/api-platform-samples/tree/master/sample-proxies.

You will be using the generic OAuth policies to implement the flow.

Hey Sarthak, thank you for the response. I had already reviewed the documentation you provided links to which helped but didn't "tie everything together" for the password grant type. I ended up finding a YouTube video https://www.youtube.com/watch?v=7vBh8LT2xW4 that addressed our specific questions.