Child Item

Getting invalid request for PKCEOAuthFlow.ProcessCodeFlowAsync

Hi,

I'm implementing PKCE now, but getting an invalid request exception. I can't see anything that I'm doing wrong from the doco (it says everything is optional except code and appkey). This is code that was working when I was using DropboxOAuth2Helper.ProcessCodeFlowAsync (but I want to convert to not sending the secret - using a C# dotnet desktop app).

My initial code (using a code authorised in the browser, and the same appkey) is as follows...

```

if (code is object) {
PKCEOAuthFlow pKCEFlow=new PKCEOAuthFlow();
// OAuth2Response dxResponse=await DropboxOAuth2Helper.ProcessCodeFlowAsync(code,APIKEY,APISECRET); note THIS CODE WAS WORKING
OAuth2Response dxResponse=await pKCEFlow.ProcessCodeFlowAsync(code,APIKEY);

```

Then I hit the exception...

********************************** UNHANDLED EXCEPTION! Details: Dropbox.Api.OAuth2Exception: invalid_request
at Dropbox.Api.DropboxOAuth2Helper.ProcessCodeFlowAsync(String code, String appKey, String appSecret, String redirectUri, HttpClient client, String codeVerifier)

Do I need to use a different authoriseURI if I'm using PKCE or something? I'm using the same one I was using with DropboxOAuth2Helper.ProcessCodeFlowAsync. Otherwise I don't know what it's not happy about. 😕

thanks,

Donald.

Find more posts tagged with

API

Abuse

Comments

Здравко

@donaldp wrote:
...
if (code is object) {
PKCEOAuthFlow pKCEFlow=new PKCEOAuthFlow();
...

As can be seen from your post, you are constructing pKCEFlow object anew after you have got the code. How you guarantee that PKCE code challenge, send as part of initial query (targeting the code you have received on redirect), match to the code verifier used on followup code processing (both generated and carried within PKCEOAuthFlow object)? 🤔 This workflow targets extremely difficult prediction of such pair, so security gonna be improved. If it was so easy to predict second pair' element (just construct a new object), 😁 what's the meaning of PKCE usage at all?

Hope this gives direction. 😉

donaldp

Hi,

> As can be seen from your post, you are constructing pKCEFlow object anew after you have got the code

Yes, that's right. I'm getting the code directly from the browser - I'm not doing it via the app - so this is the first step in the process in the app. There is no redirect. The user gets the code, then comes to the app with it. The doco says that you can do that, hence why the subsequent parameters are all optional. It's not working though (as is).

Здравко

@donaldp wrote:
... I'm getting the code directly from the browser - I'm not doing it via the app - so this is the first step in the process in the app. There is no redirect. The user gets the code, then comes to the app with it. The doco says that you can do that, hence why the subsequent parameters are all optional. It's not working though (as is).

Ok, that's right. Nothing against what you say, it's correct. Do you intentionally bypass my actual notes posted before? 🤷 If you don't want, don't read them.

Edit:

@donaldp wrote:
... I'm getting the code directly from the browser - I'm not doing it via the app - so this is the first step in the process in the app. ...

The first step is constructing and launching Dropbox authentication (URL construction that must include code challenge). What you are talking about is going to be the second one! Both are strictly related to each other - something you are missing, seems!

donaldp

>The first step is constructing and launching Dropbox authentication

And the doco states that step is optional, as I already said. I therefore don't know what code is needed to get this working when one isn't constructing and launching a redirect. If you're getting the code directly from a browser as the actual first step, then the next step is entering that code into the app, unless someone can tell me a different first step for bypassing using a redirect (I already asked if there's a different URL needed to be used for the PKCE flow - I'm using the same URL as non-PKCE flow, but maybe that's the issue?).

Здравко

@donaldp wrote:
...
And the doco states that step is optional, as I already said. ...

Probably we are talking for different things. How constructing URL used on launching the browser (where you are getting code) can be optional? You are getting such code every time OAuth is on go, but it's optional... 🤔 Can you clarify the meaning of word "optional" here (in this context)?

This is something mandatory for any type of Flow in use and both with and without redirection! Sometimes it's simple, sometimes little bit complicated. When SDK is in use you are relying on the SDK code to do this, should look the same. Just careful what code is used to construct it. Don't mix different code (from different flows) together.

One more thing:

@donaldp wrote:
... (I already asked if there's a different URL needed to be used for the PKCE flow - I'm using the same URL as non-PKCE flow, but maybe that's the issue?).

What actually means "the same URL"? If you mean URL received using the same code (PKCEOAuthFlow class code), that's correct. Since this URL will contain within code challenge (something supposed to be unique for every query), URL literal gonna be different. If you mean usage of a constant URL literal..., where and how will come code challenge from - something mandatory for PKCE?

donaldp

From https://developers.dropbox.com/oauth-guide - "The redirect_uri is optional with the code flow - if unspecified, the authorization code is displayed on dropbox.com for the user to copy and paste to your app"

So the URL is https://www.dropbox.com/oauth2/authorize?client_id=MY_CLIENT_ID&redirect_uri=MY_REDIRECT_URI&response_type=code, but without the redirect, since that is optional, and that link is always the same, so just have a browser shortcut for it.

It sounds like the link is different for PKCE then?

Здравко

Yes, we are talking for different things. @donaldp, It's correct:

@donaldp wrote:
From https://developers.dropbox.com/oauth-guide - "The redirect_uri is optional with the code flow - if unspecified, the authorization code is displayed on dropbox.com for the user to copy and paste to your app"
...

But the following:

@donaldp wrote:
...
So the URL is https://www.dropbox.com/oauth2/authorize?client_id=MY_CLIENT_ID&redirect_uri=MY_REDIRECT_URI&response_type=code, ...

... is definitely NOT "redirect_url"!!! It's the URL used to launch the authentication and it's mandatory for every Flow - no way to get anything without it! Again, PKCE Flow does suppose code challenge existance... no, no just does suppose - it's mandatory and will never work without.

Take a look here and look on PKCE example (scroll little down). See there what's mandatory and what - not. Better don't construct it by hand, but use corresponding method instead.

donaldp

Ok, used the wrong name - it's the authorisation URL, not the redirect URL - but it's still the same URL every time. The link you provided says the same thing -

https://www.dropbox.com/oauth2/authorize?client_id=<APP_KEY>&response_type=code

- so I still don't know why it's not working, given that's exactly the URL I've been using.

Здравко

OMG...

Documentation:

Example: Auth URL for PKCE code flow

https://www.dropbox.com/oauth2/authorize?client_id=<APP_KEY>&response_type=code&code_challenge=<CHALLENGE>&code_challenge_method=<METHOD>

Be more careful, where you are looking on!

donaldp

Ah ok. Yes I didn't see that because doco says "Example: Auth URL for code flow with offline token access type", which is what I want - offline token. Needs a qualifier added "except for PKCE".

So does the PKCE URL change each time, or I only need to generate it once?

Здравко

@donaldp wrote:
...
So does the PKCE URL change each time, or I only need to generate it once?

Technically it's possible to be a constant, but as I said before, why are you using PKCE in this case? 🤷 It becomes meaningless and I wouldn't give you such advice.

donaldp

I'm using PKCE so that I don't have to send the secret, and is what the doco says to do.

Greg-DB

The PKCE flow is the right choice for a client-side app, such as a desktop app. The PKCE flow can be used with or without a redirect URI.

The PKCE flow eliminates the need for the app secret by instead using a code challenge/verifier. That's essentially a temporary secret generated by the app. A redirect URI can be used to return the authorization code to the app, but that's unrelated to the use of a code challenge/verifier.

In order for the PKCE flow to be successful, the code challenge/verifier needs to be validated by the Dropbox server. If it's invalid, the process will fail. Specifically, the code_challenge set on the /oauth2/authorize URL used when retrieving the authorization code needs to correspond to the code_verifier sent to /oauth2/token when attempting to exchange that particular authorization code. You can use the PKCEOAuthFlow in the official Dropbox .NET SDK, which will do most of the work for you.

When using PKCEOAuthFlow in the Dropbox .NET SDK, you need to make sure you use the same instance for both the GetAuthorizeUri step as well as the ProcessCodeFlowAsync step, as shown in that example. That's because the PKCEOAuthFlow class generates the code challenge/verifier when the instance is created.

donaldp

Hi @Greg-DB ,

Thanks for your polite-as-always explanation. 🙂 That wasn't clear to me from the doco that the authorisation URL is different every time (since it's always been the same with non-PKCE), so might be worth highlighting that in the doco for others like me who are converting.

I got it working now with an access token (wanted to try that first so that I can test my code handles it properly when it expires), but I did try to save a refresh token at the same time, as that's what I'll use later, and various info was telling me I would get one with a code authorisation flow, but I didn't get a refresh token, only the access token. Is there another parameter or something I need to specify, because I thought I'd done everything I needed to get the refresh token too (for offline processing).

This is what I have so far...

```

PKCEOAuthFlow=new PKCEOAuthFlow();
AuthorisationURLText=PKCEOAuthFlow.GetAuthorizeUri(OAuthResponseType.Code,APIKEY).ToString(); (plus an option to copy this to the clipboard)

OAuth2Response dxResponse=await PKCEOAuthFlow.ProcessCodeFlowAsync(code,APIKEY);
DxAccessToken=dxResponse.AccessToken;
Trace.Write($"********************************** DxAccessToken is {DxAccessToken}\r\n");
if (dxResponse.ExpiresAt is DateTime) {
DxAccessTokenExpiry=(DateTime)dxResponse.ExpiresAt;
} else {
DxAccessTokenExpiry=DateTime.Now;
}
Trace.Write($"********************************** DxAccessTokenExpiry is {DxAccessTokenExpiry}\r\n");
DxRefreshToken=dxResponse.RefreshToken;
Trace.Write($"********************************** DxRefreshToken is {DxRefreshToken}\r\n");
Authorised=true;

```

But as I said, the refresh token came up blank.

thanks,

Donald.

Здравко

@donaldp wrote:
..., but I didn't get a refresh token, only the access token. Is there another parameter or something I need to specify, because I thought I'd done everything I needed to get the refresh token too (for offline processing).
...
AuthorisationURLText=PKCEOAuthFlow.GetAuthorizeUri(OAuthResponseType.Code,APIKEY).ToString();
...

Hi @donaldp,

Yes there is such parameter that you skipped. Refresh token is "in pair" with offline processing, but where you are specifying that? There is such a parameter 'tokenAccessType' (set to Legacy by default). Whenever some example uses refresh token the parameter is set to Offline. 😉 Just do the same.

There is a mistake in code comment and documentation that Legacy means long lived token. Sometime ago - Yes, but now it's obsolete.

Greg-DB

@donaldp Здравко is correct, in order to receive a refresh token, you need to specify "offline" access. With the .NET SDK, you would do so in your GetAuthorizeUri call, by setting tokenAccessType: TokenAccessType.Offline, like in the example here. It looks like that's missing in the GetAuthorizeUri call in the latest code you shared.