PKCE Refresh token

[kuselan84]

Token handler on PCKE flow is not verifying code_verifier and expecting client_secret.

Providing client_secret will defeat PKCE flow.

Please assist.

[jankapunkt]

Hello @kuselan84 thank you for getting in contact. What is exactly the nature of your issue?

• Did you try to implement the PKCE workflow
• or do you think we have a flaw in our implementation that conflicts with the RFC 7636

[kuselan84]

Hi @jankapunkt,

I'm trying implement PKCE flow using guide at PKCE Support.

I send auth request as follows:

POST http://localhost:3000/authorize
Content-Type: application/x-www-form-urlencoded

response_type=code&
client_id=myclient&
redirect_uri=http://localhost:3000/client/app&
state=mystate&
scope=offline_access&
code_challenge=p4eKNknklsnn5fQb9A20lfYv36WHZk_K9y8PRCPooNc&
code_challenge_method=S256

I received code to redirect uri successfully. Then I request token as follows:

POST http://localhost:3000/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
client_id=myclient&
code=8b51da4fade34a5ccf0d1dc40816812052e2b3ae&
code_verifier=e4fz4xjFKhlQUWXgsME5dp3CugzrYf1BLUwuywRu9gc

I received access token successfully. Then I request access token again using refresh token as follows:

POST http://localhost:3000/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&
client_id=myclient&
code_verifier=e4fz4xjFKhlQUWXgsME5dp3CugzrYf1BLUwuywRu9gc&
refresh_token=f5360c80cd7fd774d3a165360796a1747d3de012f6608ce6bcb3997876f7c892

It failed with this error message:

{
  "error": "invalid_client",
  "error_description": "Invalid client: cannot retrieve client credentials"
}

The request works if I send client_secret parameter. However it ignore code_verifier verification.

[kuselan84]

Perhaps it could be fixed so that neither the code_verifier nor the client_secret are required.
If the client securely manages the refresh_token, it alone could suffice for obtaining a new access_token.
eg.

POST http://localhost:3000/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&
client_id=myclient&
refresh_token=f5360c80cd7fd774d3a165360796a1747d3de012f6608ce6bcb3997876f7c892

[jankapunkt]

@kuselan84 I read up again the RFC and some resources and there is indeed no specification on the RFC about the refresh token in combination with PKCE. I also think this is why we did not 100% cover this in our implementation so far. This is very unexpected.

Assumptions

• if a client has retrieved the refresh token (together with the access token) then it must have passed the PKCE
• there is no need to pass PKCE challenge with refresh token
• however, if the client was issued a client_secret in the authorization code grant workflow, then it must issue the client_secret even with refresh grant
• The request works if I send client_secret parameter. However it ignore code_verifier verification. is therefore correct behaviour, because you will not need the code_verifier with refresh token.

Concerns

Perhaps it could be fixed so that neither the code_verifier nor the client_secret are required.
If the client securely manages the refresh_token, it alone could suffice for obtaining a new access_token.
eg.

I agree with this. However I'm still unsure how If the client securely manages the refresh_token is actually realized in a PKCE scenario.

• https://datatracker.ietf.org/doc/html/rfc6749.html#section-10.4

Is this even possible in a PKCE scenario? From how I see it, the client is considered unsafe. A stack answer is also inconclusive on this.

Summary

I'm generally positive with you as the RFC and literature is inconclusive and if in doubt we should always decide for the flexibility and let developers decide. However we will have to warn over the concerns in the documentation.

I would still not consider this as a bug, though.

[kuselan84]

Thank you for the reply, @jankapunkt.

I have opted to disable client_secret on token endpoint like this as per documentation:

router.post('/token', oauth.token({requireClientAuthentication:{refresh_token:false}}));

I'm going to implement Refresh token reuse Detection to protect refresh token.

[jankapunkt]

If there is no veto from @jorenvandeweyer @dhensby @shrihari-prakash I'm going to implement this. The impl. also needs to update the tests accordingly.

[dhensby]

disclaimer: I have not familiarised myself with the PKCE spec recently

My understanding PKCE is primarily aimed at clients that are deemed to be unable to securely store sensitive date (hence, there is no client_secret issued to them as part of their credentials). Therefore, I'd be very cautious about even issuing refresh tokens to clients that cannot store secrets securely...

[shrihari-prakash]

Hello @jankapunkt ,

In my opinion, I think it is normal that the code_verifier is ignored in refresh token exchanges. Because if we take a step back and see the purpose of PKCE itself, for instance in a native app setup when the auth code flow is done and the redirect is sent to your app, a malicious application can register itself as a handler for the redirect URI and get the authorization code which can be abused. The primary thing to note is that there are two parties involved here.

But in case of refresh tokens, there is none of the redirect stuff and it is purely handled within the application. I don't see why a code_verifier is required in this case although as @dhensby mentioned, if the client cannot store refresh tokens securely, there is no point to even sending it to client :).