Child Item

Unclear about PKCE and .NET SDK

Hi,

Firstly, I'm getting 404's on all your documentation at the moment, so I'm unable to look it up. e.g. the link https://dropbox.github.io/dropbox-sdk-dotnet/html/M_Dropbox_Api_Files_Routes_FilesUserRoutes_UploadSessionFinishBatchCheckAsync_1.htm is giving me 404.

So, having got all the time-sensitive stuff dealt with, I now have some time to set about updating my Dropbox library. 🙂 This includes updating from having used long-lived tokens previously. I've updated the nuget from 6.13 to 6.32 to give you an idea of how much work I've gotta do.

I can see in my OAuth2Response that I (having used the code flow recently) have the refresh token available there as well as the short-lived token, and after a bit of reading it seems I can just use the refresh token in place of the short-lived token and the SDK Helpers automagically take care of refreshing the short-lived token. Ok, this looks like it's going to be easier than I thought - just send the refresh token instead of the short-lived token. 🙂

But then I read some more, and now I'm confused. Further on in the guide it talks about using PKCE if you're unsure about the security of your app (this is with a desktop .NET app using code flow), but there is no mention about the SDK Helpers like there was in the part about refresh tokens. So if I'm using the SDK Helper DropboxOAuth2Helper will it automagically take care of the secret's security for me, like it does with the refresh tokens, or is there still code I need to write? I've never done anything with PKCE before, so I'm a bit lost - I'm hoping the Helper takes care of this part if I just put in the secret as before? Or there's a Helper I can use which does it?

thanks,

Donald.

Find more posts tagged with

API

Abuse

Accepted answers

donaldp

Hi again @Greg-DB ,

I've been reading through the doco, and I've found what's confusing me...

In the examples you've given, a RedirectURI is being used, but I'm not using that - I'm not launching the browser from the app, I'm just going directly to the authorise link from a shortcut in the browser and then copying the code into the app. So I'm not doing the steps from lines 183-198, I'm picking up the process from line 199 - ProcessCodeFlowAsync, and I've been doing this "ProcessCodeFlowAsync(Code,APIkey,AppSecret)".

But the info for that says...

"

Processes the second half of the OAuth 2.0 code flow. Uses the codeVerifier created in this class to execute the second half.

Declaration

public Task<OAuth2Response> ProcessCodeFlowAsync(string code, string appKey, string redirectUri = null, HttpClient client = null)

So, since the RedirectURI is optional, and I've opted out, that looks to me like I can just call ProcessCodeFlowAsync(code,appkey) and that's it? Don't need to use the secret at all now?

Ah! I think I have it now (in fleshing this out a bit). I've used DropboxOAuth2Helper.ProcessCodeFlowAsync(Code,APIkey,AppSecret) to date, but now I would use PKCEOAuthFlow.ProcessCodeFlow(Code,APIKey) and the rest is done automagically? The same method name in 2 different classes had me thinking it was the exact same method, and thus the confusion. I think I just need to convert to using the latter instance now?

thanks,

Donald.

All comments

Greg-DB

The .NET SDK documentation is currently available here. Click the "API Documentation" link at the top to access specific classes/methods.

The PKCE flow is the right thing to use for client-side apps, such as desktop apps. The SDK will still do most of the work for you. You can find an example of using the PKCE flow with the .NET SDK here. For instance, here's where where you start the flow and have the SDK build the authorization URL (without the app secret; it handles the PKCE code verifier/secret automatically internally for you), and here's the line where it processes the result to return the access token and refresh token. From there, you can make a client (with the refresh token and app key, but not app secret) and the SDK will handle the refresh process for you automatically.

donaldp

Hi @Greg-DB ,

Thanks for the correct link. I'll read through that shortly, but first the documentation link that you've given in your reply here...

>The .NET SDK documentation is currently available here. Click the "API Documentation" link

is a DIFFERENT link to the "Documentation" link which is on the first page itself, and that returns a 404. Here's some screenshots showing them pointing to different places...

- this works

-this gives a 404

Thanks,

Donald.

Greg-DB

Thanks for the note. We'll get that fixed up in the next build of that GitHub page.

donaldp

Hi again @Greg-DB ,

I've been reading through the doco, and I've found what's confusing me...

But the info for that says...

"

Processes the second half of the OAuth 2.0 code flow. Uses the codeVerifier created in this class to execute the second half.

Declaration

public Task<OAuth2Response> ProcessCodeFlowAsync(string code, string appKey, string redirectUri = null, HttpClient client = null)

So, since the RedirectURI is optional, and I've opted out, that looks to me like I can just call ProcessCodeFlowAsync(code,appkey) and that's it? Don't need to use the secret at all now?

thanks,

Donald.

Greg-DB

That's correct, whether using PKCE or not, use of a redirect URI optional. Using PKCE just eliminates the use of the app secret in favor of a code challenge/verifier (which the SDK PKCE flow handles for you).

donaldp

Thank you @Greg-DB ! Glad we worked that out in the end. Yeah, wasn't clear to me that it was 2 different methods of the same name (since I was skipping all those previous steps in my process and just picking up at ProcessCodeFlowAsync. The latter instance is the helper I was looking for). No disrespect to you, but I'll mark my previous comment as the answer, because that's the key information that confused people like me need to find if they land here. 🙂 But thanks for being my rubber duck today. 😉 (and crucially also, providing me with the correct links to the doco)