Closed Paul-Mo-Sys closed 1 month ago
You should not use the hashed version of the client secret. It is described in the following links: https://django-oauth-toolkit.readthedocs.io/en/latest/tutorial/tutorial_01.html#test-your-authorization-server, https://django-oauth-toolkit.readthedocs.io/en/latest/changelog.html#id1, and also at the https://drf-social-oauth2.readthedocs.io/en/latest/application.html documentation.
Describe the bug When using a "Client Credenitals" app configured with a hashed client secret calling the
convert-token
always fails with errorinvalid_client
I believe that now the client secret is being set in the request by looking up the application rather than being required in the the body of the request this means that when trying to authenticate the client it is set to the three part encoded digest when the plaintext secret is required.
To Reproduce Steps to reproduce the behavior: Tested in a clean Django install with frozen requirements:
settings.py
urls.py
Create a Django Oauth Toolkit application with the following settings:
All other settings can be left blank.
Call
/auth/convert-token/
with:grant_type=convert_token
client_id=test_client_id
backend=google-oauth2
token=\<googletoken\>
e.g.
curl -X POST -d "grant_type=convert_token&client_id=test_client_id&backend=google-oauth2&token=<google_token>" http://localhost:8000/auth/convert-token
This will return
401 unauthorised
with a body:Note that the backend and token are irrelevant to the failure as this happens before they are used.
Expected behavior The authentication continues and returns the converted token as would happen if the application was saved with an un-hashed secret above
Desktop (please complete the following information):
Additional context Add any other context about the problem here.