A few questions for setting up OAuth 2.0 for the first time

Not applicable

I've set up my own api proxy for my existing api, and I've set it up to work with the provided oauth api proxy. Now I want to setup a legitimate oauth api proxy in front of my existing api's proxy for use in production.

It seems like the provided oauth api proxy is not sufficient for use in production because of the following:

  • Default Target Endpoint URL is http://www.sample.com...not sure how this api proxy even works with a target endpoint like that...
  • This block in the GenerateAccessTokenClient policy (emphasis added):
    • <SupportedGrantTypes> <!-- This part is very important: most real OAuth 2.0 apps will want to use other grant types. In this case it is important to NOT include the "client_credentials" type **because it allows a client to get access to a token with no user authentication** --> <GrantType>client_credentials</GrantType> </SupportedGrantTypes>
    • I'm confused about this block because of the documentation at http://apigee.com/docs/api-services/content/oauth-introduction, in the "Summary of OAuth 2.0 use cases" section:
    • *Use Case:* B2B (extranet), intranet, other
    • *Trustworthiness:* Highly trusted apps, written by internal developer or developers with a trusted business relationship with the API provider. Apps that need to access resources on their own behalf.
    • *Suggested OAuth 2.0 Auth Grant Types:* **Client credentials**
    • *Description:*
    • Typically, the app is also the resource owner
    • Requires Client ID and Client secret keys
    • Requires app to be registered with service provider

How can I go about creating a legitimate oauth api proxy for production? I've also looked at these documents but they seem to be leading me in different directions:

http://apigee.com/docs/api-services/content/oauth-20-client-credentials-grant-type

http://apigee.com/docs/api-services/tutorials/secure-calls-your-api-through-oauth-20-client-credenti...

Solved Solved
2 5 1,168
1 ACCEPTED SOLUTION

Hi Michael,

I can see how setting up OAuth can be confusing, and these are excellent questions. As we've been trying to improve the docs around OAuth, this is good feedback for us. I'll try to address your questions one by one and I hope others will correct me if I lead you astray...

  • About the Target Endpoint -- The target endpoint is not really required for the default "oauth" proxy. This is because the proxy's endpoints call OAuthV2 policies that do the work of generating tokens. In an OAuthV2 policy, if the <GenerateResponse> element is set to 'true', it tells the proxy to return a response directly (which will include a token) or if false, it saves the response info in flow variables that you can access later and return (or not) as you wish. A backend target is not required for any of this.
  • About <SupportedGrantTypes> -- This element specifies which grant types the OAuthV2 policy will accept. There are some rules around supported grant types that you can read about in the OAuthV2 policy reference (http://apigee.com/docs/api-services/content/oauthv2-policy). But, basically, most of the OAuthV2 policies that generate tokens require you to pass in a "grant_type" parameter, and this element provides a level of enforcement.
  • About client credentials -- This grant type is completely legitimate for certain use cases, such as when the client app (as opposed to the user of the app) is the owner of protected resources. The IETF spec on OAuth 2 provides pretty good descriptions of each of the grant types. I think the comment in the sample policy is somewhat misleading, or doesn't give a full picture, in this regard. The key is for you to decide which grant type(s) suit your use case and implement an OAuth endpoint proxy with endpoints that support those grant types. Client credentials is often used in doc examples and tutorials, because it's very straightforward to implement. That is, as opposed to authorization code, which is far more complex.
  • Real world -- I'd recommend you look at the oauth-advanced sample project on GitHub. It's geared for the authorization code grant type, but you can see how something more along the lines of a production OAuth endpoint proxy might be set up (https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/oauth-advanced). If you decide to implement the auth code grant type, this sample would be an excellent model for you.

As you think about setting up policies for your OAuth endpoints, refer to the OAuthV2 reference topic -- it's been revised recently and covers all of the "elements" you'll need to know about.

Please follow up with more questions as they come up.

View solution in original post

5 REPLIES 5

Not applicable

A bit of context: I'm trying to set up my API to use authentication so that only users we have provided keys to can generate an authentication token and query our API. We have one intended consumer of the API right now - a trusted business partner. In the future I would like to add users/consumers at will to this process, but only at my discretion (not via someone signing up on a page, requesting access for themselves).

Hi Michael,

I can see how setting up OAuth can be confusing, and these are excellent questions. As we've been trying to improve the docs around OAuth, this is good feedback for us. I'll try to address your questions one by one and I hope others will correct me if I lead you astray...

  • About the Target Endpoint -- The target endpoint is not really required for the default "oauth" proxy. This is because the proxy's endpoints call OAuthV2 policies that do the work of generating tokens. In an OAuthV2 policy, if the <GenerateResponse> element is set to 'true', it tells the proxy to return a response directly (which will include a token) or if false, it saves the response info in flow variables that you can access later and return (or not) as you wish. A backend target is not required for any of this.
  • About <SupportedGrantTypes> -- This element specifies which grant types the OAuthV2 policy will accept. There are some rules around supported grant types that you can read about in the OAuthV2 policy reference (http://apigee.com/docs/api-services/content/oauthv2-policy). But, basically, most of the OAuthV2 policies that generate tokens require you to pass in a "grant_type" parameter, and this element provides a level of enforcement.
  • About client credentials -- This grant type is completely legitimate for certain use cases, such as when the client app (as opposed to the user of the app) is the owner of protected resources. The IETF spec on OAuth 2 provides pretty good descriptions of each of the grant types. I think the comment in the sample policy is somewhat misleading, or doesn't give a full picture, in this regard. The key is for you to decide which grant type(s) suit your use case and implement an OAuth endpoint proxy with endpoints that support those grant types. Client credentials is often used in doc examples and tutorials, because it's very straightforward to implement. That is, as opposed to authorization code, which is far more complex.
  • Real world -- I'd recommend you look at the oauth-advanced sample project on GitHub. It's geared for the authorization code grant type, but you can see how something more along the lines of a production OAuth endpoint proxy might be set up (https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/oauth-advanced). If you decide to implement the auth code grant type, this sample would be an excellent model for you.

As you think about setting up policies for your OAuth endpoints, refer to the OAuthV2 reference topic -- it's been revised recently and covers all of the "elements" you'll need to know about.

Please follow up with more questions as they come up.

Hey ,

I have a question related to OAuth.

How can I do OAuth authentiaction with salesforce using my custom domain url.

Currently while authenticating it it is taking me back to test.salesforce.com, but I want to authenticate using different url, which I should be able to authenticate.

Hey ,

I have a question related to OAuth.

How can I do OAuth authentiaction with salesforce using my custom domain url.

Currently while authenticating it it is taking me back to test.salesforce.com, but I want to authenticate using different url, which I should be able to authenticate.

@Narendra Singh , Please don't spam other posts with your queries. We see that you have already posted duplicate questions. Please continue discussions in your post here.