Refresh token with External client authentication

[#1]

I am using <OAuthV2> policy with <ExternalAuthorization>true</ExternalAuthorization> with only <ExternalAuthorizationCode> configured with authorization code coming from external system.

It works good for generating access_token on grant_type authorization_code. However, I am not able to use <ExternalAuthorization>true</ExternalAuthorization> for RefreshAccessToken operation. It seems ExternalAuthorization is supported only for granttypes -

• authorization_code
• password
• client_credentials

Is there are way to allow the same for refresh_token grant type as well?

Explaining my usecase a bit

Our client app is a mobile application which uses (in secured browser/webview) a external SAML SP to authenticate the user. Once Authenticated, it issues a Auth-code and redirects to an app registered URL scheme with the same. The mobile app then exchanges that access token issued by OAuthV2 policy with ExternalAuthorization = true (service callout validating the auth-code).

I don't wish to store a client secret in the mobile app, hence the above question.

[DChiesa · Accepted solution]

Does the current system rely on a client_id to be embedded in the mobile app?

Once Authenticated, it issues a Auth-code and redirects to an app registered URL scheme with the same

I guess in the phrase "it issues an auth-code" , you are referring not to the App but a SAML IDP?. And then the mobile app gets redirected. Which system delivers that redirection? and to what system is the user agent being redirected? If you have a sequence diagram, that might clarify.

Even without knowing more... if the user agent is being redirected to a URL hosted at Apigee Edge, which then exchanges the code for a token, then Apigee Edge is the token issuer. In that case, you can finesse your way to do a refresh, later, without requiring the mobile app to send the client secret.

If the client sends in the client_id and the refresh_token, and both are stored by Apigee Edge, you can use an AccessEntity policy to retrieve the client secret, then contrive an Authorization header with the appropriate base64 blob, before invoking the OAuthV2/RefreshAccessToken policy.

[#3]

Thanks for your answer.

I guess in the phrase "it issues an auth-code" , you are referring not to the App but a SAML IDP?. And then the mobile app gets redirected. Which system delivers that redirection? and to what system is the user agent being redirected? If you have a sequence diagram, that might clarify.

I meant the SAML-SP.

Here is a sequence diagram https://swimlanes.io/u/BJ1w2ejoG of how I thought this would work. The is one thing I am not fully comfortable here is need to configure redirect_uri in both apigee as well as SAML-SP.

As you suggest, I can redirect the useragent to apigee endpoint which then validates the code (shortlived token), but then I don't want to share the access token in url fragment like implicit Oauth2 scheme.

I can work around the refresh token (as you suggested) needing the client_secret by fetching the client secret and then building a base64 blob. But if you have something that readily fits a mobile app using api's directly via apigee, please suggest. Or if its in the apigee roadmap then it would be good to know and convince others for the above workaround.

[DChiesa]

But if you have something that readily fits a mobile app using api's directly via apigee, please suggest. Or if its in the apigee roadmap then it would be good to know and convince others for the above workaround.

I don't know what you think is missing. Plenty of customers use Apigee APIs directly from within their mobile apps. I'm sorry, I don't know what problem you are trying to solve.

Here's an example: https://github.com/DinoChiesa/devjam3-20170405/tree/master/Labs/Core/06-Securing-APIs-with-OAuth-3-l...