Refresh access token without api secret

[#1]

Is is possible to refresh an access token using API key only. one of our clients don't want to send the API secret as part of the refresh token call? Is it possible?

http://docs.apigee.com/api-services/content/access-tokens#refreshinganaccesstoken says need both API key and secret

[DChiesa · Accepted solution]

Good question!

Yes, it is possible. But doing so would be counter to the OAuth 2.0 specification. You can find the relevant requirements in Section 6 of IETF RFC 6749. It states:

   If the client type is confidential or
   the client was issued client credentials (or assigned other
   authentication requirements), the client MUST authenticate with the
   authorization server as described in Section 3.2.1.

Section 3.2.1 specifies that the client should send its id and secret (its credentials) encoded in an HTTP Basic Authentication header.

So I think it would be a Bad Idea to allow refresh without the client credentials.

There is a way to do what you want - basically you have the client pass in the client_id, then lookup the App via AccessEntity, extract the secret, then assign a contrived Basic Authentication header using the extracted secret, before using the policy OAuthV2/RefreshAccessToken.

But you probably shouldn't do that.

Can you explain the justification for the client asking for a refresh without passing the client secret?

[#3]

thanks @Dino , The use case is , BU is saying that AWS is supporting this ..!

[#4]

I have a requirement where a client needs to refresh the access token issued for different client.

ClientA - Dev app on boarded on Okapi1 (EPIC).

ClientB - Okapi2 (AWS) on boarded as a client on Okapi1.

On Okapi1 both are on boarded as app, now clientB is nothing but it is OKpai2 which is onboarded on okapi1.

Is it possible that ClinetB can refesh the access token without usung ClientA creds?

[DChiesa]

Hi, this probably is an interesting question, but I haven't even read it! Sorry! The reason I haven't read it, is because you've posted it as a comment to an answer that is more than a year old !

Please post new questions as new questions.

[#6]

Hi @krishna.prasadm. I agree with @Dino about the risks. However, I believe there are use cases in which you can minimize these and keep down the complexity of your app. Which I believe is one of the ultimate purposes of this flow. In fact, OAuth providers like Auth0 support it with SPA (Single Page Applications). With a few tweaks such as providing the ability to revoke refresh tokens on demand, plus a few others.

Frankly, when I was implementing it the first time I was confused, so I asked the question on Auth0 Community, and @dselans shared his perspective. I hope it helps to give you some background and evaluate if it is suitable or not. https://auth0.com/forum/t/is-it-a-security-risk-to-refresh-token-wthout-a-secret/3250