How to use Refresh Token with 3 Leg Oauth v2

Not applicable

Hi,

We have implemented 3 Leg OAuth v2 (Authorization code grant type) using the Apigee example as a base: https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/oauth-advanced

The flows to get an auth code and access and refresh code are working and we have integrated with a third party application. The third party application initially redirects to our login and consent page and the auth code is returned to it via a redirect (as per the Apigee example and spec). The third party application then gets the access and refresh token using the auth code (again as per the Apigee example and spec). The third party application never sees the users consumer key or secret and the returned access token works perfectly.

The problem comes when the third party application tries to do a refresh call. When the third party application internally detects a 401 unauthorized response status it automatically attempts to do a refresh using the refresh token it received with the original access token. However it fails as it only has it's own consumer key and secret. The whole point of the 3 Legged redirects seems to be to keep it from having the actual users credentials however without those we get an error that the refresh token is invalid.

Basically our question is in 3 Legged OAuth as per the Apigee example how does the refresh token get used? In our scenario is their anyway for the third party application to refresh the token without access to the actual users credentials?

Please let me know if you need more information or anything clarified. We are new to implementing 3 Legged OAuth so apologies if any of the terminology in my question is incorrect.

Thanks.

Solved Solved
1 2 1,011
1 ACCEPTED SOLUTION

Hi Mark

in 3 Legged OAuth as per the Apigee example how does the refresh token get used? In our scenario is their anyway for the third party application to refresh the token without access to the actual users credentials?

Yes, the third-party app needs only to send in the refresh token, to refresh a token that was originally acquired with the 3-legged flow. There is no need to send the user credentials, and anyway Apigee Edge would have no way to validate user credentials directly.

Check this doc page for a thorough treatment.

https://docs.apigee.com/api-services/content/access-tokens#refreshinganaccesstoken

You also wrote:

The whole point of the 3 Legged redirects seems to be to keep it from having the actual users credentials however without those we get an error that the refresh token is invalid.

Can you show your policy configuration for the RefreshAccessToken operation?

View solution in original post

2 REPLIES 2

Hi Mark

in 3 Legged OAuth as per the Apigee example how does the refresh token get used? In our scenario is their anyway for the third party application to refresh the token without access to the actual users credentials?

Yes, the third-party app needs only to send in the refresh token, to refresh a token that was originally acquired with the 3-legged flow. There is no need to send the user credentials, and anyway Apigee Edge would have no way to validate user credentials directly.

Check this doc page for a thorough treatment.

https://docs.apigee.com/api-services/content/access-tokens#refreshinganaccesstoken

You also wrote:

The whole point of the 3 Legged redirects seems to be to keep it from having the actual users credentials however without those we get an error that the refresh token is invalid.

Can you show your policy configuration for the RefreshAccessToken operation?

Thanks Dino.