Refresh tokens without Consumer Secret

[rmishra]

Hello,

I have encountered a use case where i need to refresh tokens when the client does not have access to the Consumer Secret.

I did go through this old post https://community.apigee.com/questions/37435/refresh-access-token-without-api-secret.html

But that post and the OAuth spec reference confidential clients

My use case involves Native Apps (Public Clients) relying on Auth Code with PKCE flow to acquire access tokens. While the OAuth Spec extension(https://tools.ietf.org/html/rfc7636) talks extensively about Access Tokens , i do not see any guidance in the spec on Refreshing Tokens.

So, this would be a scenario for trying to refresh tokens without access to a client secret.

The only relevant implementation i can find is from Auth0 https://auth0.com/docs/tokens/refresh-token/current#use-a-refresh-token

While i can implement a workaround technically (load the client secret implicitly and create a basic auth header) i do see the possible vulnerability in implementing it

I would like to know how others have solved this use case

Any inputs are appreciated

Regards

[DChiesa]

i do see the possible vulnerability in implementing it

What's the possible vulnerability? I figured that the PKCE would take care of that concern. Not true?

[DChiesa]

BTW, here is a related question: https://community.apigee.com/questions/55292/oauth20-authorization-flow-without-client-secret.html

[rmishra]

@Dino The PKCE side of it kicks in during the "Auth Code Generation and Access Token Generation" process.

The refresh token process has no concept of a code challenge/code verifier.

As you well know, In the refresh token flow a new access token is simply retrieved by providing the refresh token , client id and a client secret.

In a native app scenario, we would expect them to trade the refresh token, and the client id (no client secret). In my view , since the client id is considered public and stored on the device, there is only one factor (refresh token) waiting to be compromised.

I read through your previous post and i understand how to work around the native app problem.

This is a common use case (i think) where native apps need to invoke API's . i wanted to hear how other people have approached it as i don't see anything special baked into the PKCE spec for refreshing tokens.

[#5]

Hi, Do you found an answer for your question? We have the same question, not pass the secret or similar in when refresh the token is insecure. How do you resolve it?

Thanks in advance

,,

Hi, How do you resolve the Refresh Token flow in a mobile app? I have the same question and I dont found a consistent answer.

[rmishra]

@Israe dominugezSorry for the delay.I haven't been to the community in a while.

There is no consistent answer to this.

If you look at the PKCE spec, it doesn't really address the refresh scenario. That leads one to assume that the refresh scenario must be identical to the regular Auth Code Grant scenario.Clearly, that isn't true - because you won't have access to the client secret. So, it all comes down to the implementation of your Authorization Server (in this case apigee OAuth2 proxy Bundles)

You have the following choices :

- Do not support refresh tokens for PKCE .

- Support refresh token for PKCE with additional challenges during refresh (device fingerprinting), Look at other implementations (Okta, Auth0)

- Support refresh tokens without a client secret, understand the risks for this and find ways to mitigate it. This would be spin on the previous item.

btw, there are some other specifications (token binding - https://tools.ietf.org/html/draft-ietf-tokbind-https-08) which can you look into to secure the refresh token exchange. I haven't had the time to look deeper into this.