How to login to dropbox account from inside UWP app?

If I understood you correctly, I think usrs don't log in thier accounts from your app. You simply grant them access to your APP (in app console) in YOUR dropbox account under [App Console].

In order to allow arbitrary end-users to connect your app to their own Dropbox accounts, you should implement the OAuth app authorization flow. Note however that this should no longer be processed in a web view. This should only be done via the user's system browser, per the documentation.

I don't believe we have an example for doing this in UWP in particular, but there is a general example with some code in the DropboxOAuth2Helper class documentation for the official Dropbox API v2 .NET SDK.

@Greg-DB wrote:
In order to allow arbitrary end-users to connect your app to their own Dropbox accounts, you should implement the OAuth app authorization flow. Note however that this should no longer be processed in a web view. This should only be done via the user's system browser, per the documentation.

I don't believe we have an example for doing this in UWP in particular, but there is a general example with some code in the DropboxOAuth2Helper class documentation for the official Dropbox API v2 .NET SDK.

I think he was asking about something else, I think he wants the user to be able to use the app in order to log into user's personal account including shared files. I don't think this is possible according to OAuth2 which prevent using one's password through token flow method.

Maybe generating a link to the user's account is more suitable. [I guess]

@evry1falls I'm not sure I understand your comment. The information in my comment does refer to using the OAuth 2 app authorization "token" flow to allow the end-user to connect the app to their own personal Dropbox account, including shared files, without giving their password to the app. Implementing the OAuth 2 app authorization flow to allow end-users to authorize the app is the intended design.

If I understand correctly though, the original question was about how to migrate this flow from a webview in Xamarin to a webview in UWP, but I pointed out that it should actually be processed in the system browser, not a webview.

I'm sorry if I seemed arguemental.

Im sure you know what you are talking about.

@Greg-DB wrote:
If I understand correctly though, the original question was about how to migrate this flow from a webview in Xamarin to a webview in UWP, but I pointed out that it should actually be processed in the system browser, not a webview.

I also changed the original code for my desktop project to display the Auth page in webbrowser control that I use, not the default webbrowser of the machine, it is working fine, I see no reason why you suggested otherwise. Could you explain it more?

@evry1falls Per the /oauth2/authorize documentation, the Dropbox OAuth app authorization flow should be processed in the system browser, not a web view. There's more information linked there, but in short, this is both to comply with Google's policy (since Dropbox offers Google Sign In as an authentication option), as well as for compatibility with the Dropbox site in general. While it may currently work in the control you're using, we've found web views to be more prone to incompatibilities, and since they're not officially supported by the Dropbox site, we can't promise fixes if/when such issues arise.

@Greg-DB wrote:
@evry1falls Per the /oauth2/authorize documentation, the Dropbox OAuth app authorization flow should be processed in the system browser, not a web view. There's more information linked there, but in short, this is both to comply with Google's policy (since Dropbox offers Google Sign In as an authentication option), as well as for compatibility with the Dropbox site in general. While it may currently work in the control you're using, we've found web views to be more prone to incompatibilities, and since they're not officially supported by the Dropbox site, we can't promise fixes if/when such issues arise.

Thank you.

May I ask you to send that part of Google's policy that requires DropBox to stop supporting the Web Authentication Broker?

@Vasilinka You can find Google's post here: https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

Thank you so much for your answer!

As far as I understand, please correct me if I'm wrong, here Google says that it is discontinuing support for authentication using Web View. - " we will no longer allow OAuth requests to Google in embedded browsers known as “web-views”.

Next, they recommend "using the device browser for OAuth requests instead of an embedded web-view".

But how it connected with Web Authentication Broker?

As I understand that is absolutely different mechanisms.

Web-view is an embeddable browser and "apps are able to inspect and modify content in a web-view".

Web Authentication Broker is a system API that Windows uses instead of a web-view to prevent user passwords theft by men-in-the-middle.

I see that Google trusts Web Authentication Broker because that's what they use to connect to Google Drive or Google Mail to applications for Windows.

@Vasilinka I can't speak to Google's own definitions or usage, but for the purposes of Dropbox's OAuth app authorization flow, WebAuthenticationBroker is considered a kind of webview and is not supported.

Now I understand. Thank you!

That is mean that it is not a Google requirement but an independent Dropbox decision. I see no reason to think that System API is a kind of Web-view and, I will be glad if you tell me exactly why you think so.

Anyway, today we have such a situation: Our application has tens of thousands of users connecting their Dropbox account.
They can, of course, use an installed browser for authorization. Many people dislike this because they think it is a more dangerous way to enter data than as the browser becomes an intermediary in this process. To those who write to us, we answer that this is not our bug, but your decision. However, this is not obvious to most.

Users see that when they login to GoogleDrive, OneDrive, Yandex Disk, etc all of these cloud services use Web Authentication Broker and only while connecting to Dropbox tries to open the browser in a new window. As a result, they regularly write to us about "the bug" 😒.

May I send them a link to this forum for they understood what really going on?

@Vasilinka Thanks for the additional feedback. I can't offer much more insight on the specifics of what went in to determining policies, but you can find the documentation for this here. And yes, this thread is publicly available here.

Thank you for the answer!

@Greg-DB wrote:
... I can't offer much more insight on the specifics of what went in to determining policies, but you can find the documentation for this here.

I have seen this documentation before and there is not a single mention of the fact that Web Authentication Broker is prohibited to use (and this obviously could not be, because Google themselves support it) or that it is the same as Web View.

Please share with me the contact of a person in Dropbox who can explain: Why do you think Web Authentication Broker is a Web View? I consider it necessary to escalate this issue since the interests of a fairly large number of users suffer. Only we have tens of thousands of them, and there are many applications similar to ours.

@Vasilinka I cannot disclose Dropbox employee contact information. I've sent your feedback and comments along to the team, and I'll follow up here if/when I have anything else to share.

Hi, Greg

@Greg-DB wrote:
I've sent your feedback and comments along to the team.

Did you get any response from the team?