我开始为你的问题写一篇评论，但后来发现有太多话要说，所以这里是我对这个问题的看法。 / p>

1. 是的，这存在一个真正的可能性，并且基于此有一些漏洞利用。建议不要将应用程序保密在您的应用程序中，甚至有一部分规格说明分布式应用程序不应该使用此令牌。现在你可能会问，但是XYZ需要它才能工作。在这种情况下，他们没有正确实施规范，并且您应该A不使用该服务（不太可能），或者B尝试使用一些混淆方法来保护令牌，以便更难找到或使用服务器作为代理。

   
   
   

   例如，Android的Facebook库中存在一些漏洞，这些漏洞将令牌泄露给Logs，您可以在这里了解更多信息。 /attack-secure.com/all-your-facebook-access-tokens-are-belong-to-usrel =nofollow noreferrer> http://attack-secure.com/all-your-facebook-access-代币属于我们
   并且在这里 https：/ /www.***.com/watch?v=twyL7Uxe6sk 。
   总而言之，请谨慎使用第三方库（实际上常识，但如果令牌劫持是您最担心的问题，请再慎重考虑）。




2. 我在一段时间以来一直在争论点2。我甚至在我的应用程序中做了一些解决方法，以便修改同意页面（例如更改缩放和设计以适应应用程序），但没有任何东西阻止我使用用户名和密码从Web视图内的字段中读取值。因此，我完全同意你的第二点，并发现它在OAuth规范中是一个很大的bug。在规范中，应用程序无法访问用户凭据只是一个梦，并且会给用户带来虚假的安全感......另外，我想人们通常会在应用程序询问他们的Facebook，Twitter，Dropbox或其他凭据时怀疑它们。我怀疑许多普通人阅读OAuth规范并且说现在我很安全，而是使用常识，并且通常不使用他们不信任的应用程序。

$ b

To use google drive api, I have to play with the authentication using OAuth2.0. And I got a few question about this.

1. Client id and client secret are used to identify what my app is. But they must be hardcoded if it is a client application. So, everyone can decompile my app and extract them from source code. Does it mean that a bad app can pretend to be a good app by using the good app's client id and secret? So user would be showing a screen that asking for granting permission to a good app even though it is actually asked by a bad app? If yes, what should I do? Or actually I should not worry about this?

2. In mobile application, we can embedded a webview to our app. And it is easy to extract the password field in the webview because the app that asking for permission is actually a "browser". So, OAuth in mobile application does not have the benefit that client application has not access to the user credential of service provider?

I started writing a comment to your question but then found out there is too much to say so here are my views on the subject in the answer.

1. Yes there is a real possibility for this and there were some exploits based on this. Suggestion is not to keep the app secret in your app, there is even part in the spec that distributed apps should not use this token. Now you might ask, but XYZ requires it in order to work. In that case they are not implementing the spec properly and you should A not use that service (not likely) or B try to secure token using some obfuscating methods to make it harder to find or use your server as a proxy.

   For example there were some bugs in Facebook library for Android where it was leaking tokens to Logs, you can find out more about it here http://attack-secure.com/all-your-facebook-access-tokens-are-belong-to-us and here https://www.***.com/watch?v=twyL7Uxe6sk. All in all be extra cautious of your usage of third party libraries (common sense actually but if token hijacking is your big concern add another extra to cautious).

2. I have been ranting about the point 2 for quite some time. I have even done some workarounds in my apps in order to modify the consent pages (for example changing zoom and design to fit the app) but there was nothing stopping me from reading values from fields inside the web view with username and password. Therefore I totally agree with your second point and find it a big "bug" in OAuth spec. Point being "App doesn't get access to users credentials" in the spec is just a dream and gives users false sense of security… Also I guess people are usually suspicions when app asks them for their Facebook, Twitter, Dropbox or other credentials. I doubt many ordinary people read OAuth spec and say "Now I am safe" but instead use common sense and generally not use apps they don't trust.