How to send Access token in body of url encoded form?

vermagovind92
Participant III

Hi All,

I have some doubt could someone clear me out for these questions?

1. How to send Access token in body of url encoded form?

2. What are the best way to send client key and secret?

3. How to handle error in single RF policy for Proxy Endpoint, Target Endpoint and for Backend error?

4. Basic difference between 3 legged and 2 legged Oauth?//(I have seen some videos and tutorials but lil confused in this!!)

Any suggestions will be appreciated!!

Thanks and Regards

Govind Verma

@Anil Sagar @ Google,@Anil Sagar,@Siddharth Barahalikar,@Dino-at-Google,@sudheendras,

@Dino,@brandon@apigee.com,@Brendan,@Kuldeep Bhati,@deboraelkin,@Nagashree B,

@Debashish Roy,@Priyadarshi Ajitav Jena,@Mukundha Madhavan,@Abhishek Subramanya,

@arghya das

Solved Solved
0 6 1,647
2 ACCEPTED SOLUTIONS

sidd-harth
Participant V
. How to send Access token in body of url encoded form?

Question is not clear. More details are required.

OAuth tokens are random strings and are sent as Auth Header.

What are the best way to send client key and secret?

If you want to send through a client use Base64encoded string. If you want to set the credentials within Apigee Proxy level use KVM(encrypted).

How to handle error in single RF policy for Proxy Endpoint, Target Endpoint and for Backend error?

More details are required.

For which error you want to Raise a fault? Why do you want to use a single RF?

Basic difference between 3 legged and 2 legged Oauth?//(I have seen some videos and tutorials but lil confused in this!!)

Simple answer - 3 legged OAuth is more secure as an additional security step is done. In 3 legged OAuth, before sending the access token, the Auth Sever sends in a one-time use Auth-Code to the App. The App then sends backs the Auth code along with the App Credentials to get back the access_token.

View solution in original post

1. How to send Access token in body of url encoded form?

Just pass it as a form parameter. How you "send" depends on the client library you are using. In curl you could do this:

  curl $apiendpoint/v1/foo -d "token=$access_token"

It's such a simple answer I am thinking maybe I didn't understand your question.

2. What are the best way to send client key and secret?

The OAuth spec suggests using Basic Auth encoding. That means concatenate the id and secret with a colon, and then base64 encode the result.

3. How to handle error in single RF policy for Proxy Endpoint, Target Endpoint and for Backend error?

Unclear what you mean here. The RaiseFault policy does not "handle" errors. The RaiseFault policy generates an error, puts the proxy flow into fault status. You *may* want to throw the same error in multiple different conditions, perhaps from the proxy, the target or somewhere else. In that case you can just attach the policy multiple times, in different places, with the appropriate Condition element.

4. Basic difference between 3 legged and 2 legged Oauth?//(I have seen some videos and tutorials but lil confused in this!!)

Basic difference: OAuth 3-legged flow is used for third-party clients (produce by some party other than the party that exposes the API. Oauth 2-legged flow is used for trusted clients.

For more information, check out the devjam documentation (3-legged, client credentials); you will find web sequence diagrams that show the flow.

Also, I suggest you re-read the OAuth Spec, IETF RFC 6749, specifically sections 4.1 and 4.4.


PS:

You have a jumble of multiple unrelated questions. In the future please post multiple questions. It's easier to track that way, especially when there are followups as with your RF question.

View solution in original post

6 REPLIES 6

sidd-harth
Participant V
. How to send Access token in body of url encoded form?

Question is not clear. More details are required.

OAuth tokens are random strings and are sent as Auth Header.

What are the best way to send client key and secret?

If you want to send through a client use Base64encoded string. If you want to set the credentials within Apigee Proxy level use KVM(encrypted).

How to handle error in single RF policy for Proxy Endpoint, Target Endpoint and for Backend error?

More details are required.

For which error you want to Raise a fault? Why do you want to use a single RF?

Basic difference between 3 legged and 2 legged Oauth?//(I have seen some videos and tutorials but lil confused in this!!)

Simple answer - 3 legged OAuth is more secure as an additional security step is done. In 3 legged OAuth, before sending the access token, the Auth Sever sends in a one-time use Auth-Code to the App. The App then sends backs the Auth code along with the App Credentials to get back the access_token.

@Siddharth Barahalikar

Thanks for your reply... and I'm clarify my above doubts,

1. How to send Access token in body of url encoded form?

//Suppose my access token is generated and I'm usually sending OAuth token in header but If I want to send same token in body of url encoded form... Is it Possible?

3. How to handle error in single RF policy for ProxyEndpoint, TargetEndpoint and forBackend error?

//Suppose I have One javascript file attached in Proxy Endpoint and If my condition not satisfied then it's giving runtime error and I want to handle this error message to a user friendly error message and same for the Target Endpoint and I have used more than one TargetEndpoint on which one Backend is always gives 500 bad request .

And I want to handle all these errors, so It's required multiple RF-Policy or It can be done by using single RF-Policy?

Thanks,

Govind

1. How to send Access token in body of url encoded form?

Just pass it as a form parameter. How you "send" depends on the client library you are using. In curl you could do this:

  curl $apiendpoint/v1/foo -d "token=$access_token"

It's such a simple answer I am thinking maybe I didn't understand your question.

2. What are the best way to send client key and secret?

The OAuth spec suggests using Basic Auth encoding. That means concatenate the id and secret with a colon, and then base64 encode the result.

3. How to handle error in single RF policy for Proxy Endpoint, Target Endpoint and for Backend error?

Unclear what you mean here. The RaiseFault policy does not "handle" errors. The RaiseFault policy generates an error, puts the proxy flow into fault status. You *may* want to throw the same error in multiple different conditions, perhaps from the proxy, the target or somewhere else. In that case you can just attach the policy multiple times, in different places, with the appropriate Condition element.

4. Basic difference between 3 legged and 2 legged Oauth?//(I have seen some videos and tutorials but lil confused in this!!)

Basic difference: OAuth 3-legged flow is used for third-party clients (produce by some party other than the party that exposes the API. Oauth 2-legged flow is used for trusted clients.

For more information, check out the devjam documentation (3-legged, client credentials); you will find web sequence diagrams that show the flow.

Also, I suggest you re-read the OAuth Spec, IETF RFC 6749, specifically sections 4.1 and 4.4.


PS:

You have a jumble of multiple unrelated questions. In the future please post multiple questions. It's easier to track that way, especially when there are followups as with your RF question.

@Dino-at-Google

Thanks for your reply..

Hi Govind,

3. How to handle error in single RF policy for Proxy Endpoint, Target Endpoint and for Backend error?

May be you are looking for default fault rule for this situation where you want to send generic error for end user and error has not been raised in the proxy flow.

<DefaultFaultRulename="fault-rule">
<Step><Name>ReturnGenericError</Name>
</Step>
<AlwaysEnforce>false</AlwaysEnforce>
</DefaultFaultRule>
 4. Basic difference between 3 legged and 2 legged Oauth?//(I have seen some videos and tutorials but lil confused in this!!)

Example, you do login with thirdparty (login with google, facebook etc) and provide consent on any mobile app is the example of 3 legged Oauth.

@Ravindra Singh

Thanks for your reply...