Re: [OAUTH-WG] User-Agent flow and refresh tokens

  Am 18.09.2010 01:28, schrieb Kris Selden:
>> Secrets on native apps are good!  The key is (no pun intended) that the secret not ship with the app.  Each client should register for its own client_id and secret when it is installed on the client machine.
> Maybe I'm missing something but...
>
> If it has no credentials, why does sending it credentials after it has been installed, prove the client app is trusted?  Isn't an installed app without credentials, an untrusted app?  How do you know when you register the client that it is the app you think it is?
>
> What can the client you want to register do that a client you don't want to register can't after install?
>
> How would say an iPhone client that I download register?  Push notifications?  What if the end user hasn't enabled them? (I know a lot of people who turn them off) Also, if they've been hacked on a jailbroken phone (http://www.pushfix.info) are they really proving that the client is the client you think it is?
>
> "The specification is very clear (as the article quotes) – don’t use client secrets in installed applications! The reason why the specification doesn’t say much more is because there is no solution. It does not exist for a distributed application unless you issue a different secret to each installation."
> http://hueniverse.com/2010/09/all-this-twitter-oauth-security-nonsense/
>
> Once the secret is installed isn't it still vulnerable after installation? Or is it because you can revoke the one abused secret (after detecting that it has been abused) without invalidating all the installed clients.
>
> It seems like what would be ideal is if these mobile app marketplaces could install a unique client secret when an app is purchased. Otherwise I would think an untrusted app could just mimic a trusted app during registration.

that's a very interesting idea but it requires a strong trust 
relationship between app marketplace and authorization server.

In my opinion, client secrets dynamically issued by the OAuth 
authorization server might at most be a solution against session 
fixation attacks (cf. 
http://www.ietf.org/mail-archive/web/oauth/current/msg04358.html).

regards,
Torsten.

> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth