On Fri, Jun 11, 2010 at 11:46 AM, George Fletcher <gffle...@aol.com> wrote: > On 6/11/10 2:09 PM, Marius Scurtescu wrote: >> >> On Fri, Jun 11, 2010 at 10:07 AM, George Fletcher<gffle...@aol.com> >> wrote: >> >>> >>> On 6/11/10 12:34 PM, Marius Scurtescu wrote: >>> >>>> >>>> On Fri, Jun 11, 2010 at 9:25 AM, George Fletcher<gffle...@aol.com> >>>> wrote: >>>> >>>> >>>>> >>>>> On 6/11/10 12:07 PM, Marius Scurtescu wrote: >>>>> >>>>> >>>>>> >>>>>> On Fri, Jun 11, 2010 at 8:59 AM, David Recordon<record...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> That sounds like a security consideration to me! :) >>>>>>> >>>>>>> I imagine that authorization servers will verify ownership in >>>>>>> different manners depending on their tolerance of risk. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Instead of POSTing a JSON with all the details, dynamic binding could >>>>>> send only a host name. The authz server would then do discovery on >>>>>> this host and get a pointer to this JSON from host-meta. >>>>>> >>>>>> Marius >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> I think most all of this could be described in the host-meta XRD >>>>> directly >>>>> to >>>>> save yet another round trip. And I believe there are some security >>>>> advantages to using this approach, but it does require the "client" to >>>>> be >>>>> a >>>>> web-server. This might not always be the case (rich desktop app). For >>>>> native/desktop apps, it seems that posting some set of parameters >>>>> (equivalent security-wise to a browser user-agent) makes sense and >>>>> keeps >>>>> the >>>>> protocol simple. >>>>> >>>>> >>>> >>>> Yes, but in this case (desktop app) the "url" and "icon" parameters >>>> don't work and what is left is "name" and "description". I think that >>>> the suggested "client_name" parameter does exactly the same thing, >>>> much simpler. Is there any value in this case in a client_secret? >>>> >>>> Marius >>>> >>>> >>> >>> Well... given this is a POST and structured data... it would be possible >>> for >>> the desktop app to post the raw icon data (though I suppose it could also >>> POST a URL to the web server of the company the produces the app). In >>> which >>> case your previous suggestion would work (parameters discovered via the >>> URL). >>> >>> I do believe the client_secret is valuable in this case because the AS is >>> returning both the client_id and the client_secret. This then becomes a >>> way >>> for provisioning a unique client_id and client_secret to every instance >>> of >>> the app. A lot more for the AS to keep track of, but also makes it more >>> difficult for an attacker to compromise a client. The attacker could >>> impersonate the POST'd client description data (just like user-agent >>> strings >>> can be impersonated), but then the attacker just has a client_id and >>> client_secret for it's instance. >>> >>> This should force the attacker to get explicit user consent from the user >>> to >>> authorize that unique client_id. I wouldn't recommend for the AS to track >>> authorization against the POST'd client description but rather the >>> client_id. >>> >> >> An attacker can also dynamically register a very similar client >> name/description and trick the user. >> > > True... but the user will see another consent form. This might be a minor > hurdle but at least it's not totally seamless. I think that is an advantage.
Why would the user see another consent form? Were you thinking auto-approvals? For desktop apps auto-approvals don't make much sense and authz servers should probably never do that. >> The authz server is issuing a unique refresh token for each client, >> and I still don't see how an extra client_secret helps in this case. >> > > Good point. With SSL and bearer tokens the client_secret doesn't do much > good. Now if we signed the requests with the unique client_secret from the > desktop app... :) Yes, but let's see how the signature specs work out. >> For a web client the client secret helps if the refresh token is >> compromised. The web client most likely will store many refresh >> tokens, one for each user, in the database, with SQL injection all of >> these can be compromised, but the client secret (if it was not in the >> same database) makes them useless. This could be a reason why dynamic >> registration for web clients is a bad idea, the client secret will end >> up in the database, instead of a config file. >> > > The web site could store client_secrets in a different database that is not > exposed to the same SQL Injection attacks. Where the data is stored doesn't > seem like it affects it's ability to be compromised or protected. If the web > server is not well protected, getting the config file with the client_secret > might be easier than getting data out of the database. I think the security > of where the web app stores the data is orthogonal to the security of the > protocol. Maybe, not sure. If web clients are encouraged to put the secret in the database then it will end up next to the refresh token, for sure. > I suppose this also depends on which flow the desktop app is following. If > using the web-user flow (by launching the default browser, then the > client_secret (v2-06) is required. If following the device flow... then it's > not (though it seems this flow is still being defined). client_secret is required only if one was issued, "REQUIRED if the client identifier has a matching secret." So the Web Server flow should work just fine for unregistered or unsecure (registered but no secret was issued) clients. > So maybe the solution is that if the authorization server doesn't think the > client_secret is useful, it doesn't return it. Or it always returns it and > the client can throw it away as it knows it won't use it. However, it seems > like the rest of the registration flow still holds. Without client_secret I still don't see the point. Registration then boils down to self asserted name, which can also be achieved with the client_name paramter, no? Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
