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

What is dynamic client registration?

I think it will be common to naively to use the password grant in a client app (like on a phone) when the company making the app is the same as the company who controls the auth server.

The question is whether there is really anyway to know if that client app is indeed your own app and not something mimicking it.  How does a dynamic client registration prevent an untrusted client from performing the same registration steps as your trusted client if your trusted client can't protect any secrets in the first place?  In other words what would authenticate a client during the registration?

Seems to me, if you allow password grant type even on your own client (which I suspect is going to be commonly desired), you are allowing any client to pretend to be yours and use this grant type.

It is then up to the end user to trust the client.  In the other flows, your server at least has a chance to give the user feedback on what the server thinks the client they are registering is.

If you are implying dynamic registering of the client (unspecified) as involving the end user to provide trust, isn't that already part of other flows?

I still get the sense that client secrets probably don't belong on iPhone apps and I shouldn't be using the password grant type unless I'm ok with any client using it.

Though I would love to be able to use that flow on our own iPhone app (because there is some pressure for this and a lack of understanding why we can't trust it is our own app which I suspect will be common as well).

On Sep 19, 2010, at 7:37 AM, Torsten Lodderstedt wrote:

> 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
> 